How to connect signal "WpsCred"?

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

wpa_ctrl shared library

Hi Jouni,

wpa_ctrl could be used in a few things that interest me, such as python
bindings for it and in debian-installer. It would be excellent if wpa_ctrl
could be provided in a standalone distribution that can be packaged to provide
the shared lib and other program language bindings and stuff.

I've already hijacked and maintained python bindings for a little while and
could contribute them, however I do not know much about the best practises
of providing a shared library thus have nothing to offer up front to help
make this happen.

What do you think?

Thanks, Kel.

P2P IDLE state and connect / ProvisionDiscovery

Hi Jouni,

I noted that the following sequencing of command looks to fail in p2p:

            Peer1                 |               Peer2
-------------------------------------------------------------------
      p2p_find(timeout=10)        |        p2p_find(timeout=10)
           SEARCH STATE           |            SEARCH STATE
           DEVICE_FOUND           |            DEVICE_FOUND
       Wait for timeout           |          wait for timeout
           IDLE STATE             |            IDLE STATE
                                  |
p2p_provision_discovery(display) |         Nothing happens
         Nothing happens          |

Note that if you replace timeout by p2p_stop_find, this behavior remains 
the same. Note also that if you replace p2p_provision_discovery by 
p2p_connect, I still have noting that happens.

However, if I do the same sequencing without the timeout/p2p_stop_find, 
everything is working fine:
              PC1                 |                 PC2
-------------------------------------------------------------------
      p2p_find(timeout=10)        |        p2p_find(timeout=10)
           SEARCH STATE           |            SEARCH STATE
                                  |
p2p_provision_discovery(display) |            DISPLAY PIN
             ...                  |                ...

Looking at the code, I understand that being in IDLE state should not be 
a problem. However it looks to don't work.

Can you tell me what should be the right behavior ?

Regards,

Fabien

Re: P2P IDLE state and connect / ProvisionDiscovery

On Thu, Nov 04, 2010 at 05:50:18PM +0100, Fabien Marotte wrote:
> Looking at the code, I understand that being in IDLE state should not be 
> a problem. However it looks to don't work.

If you do not enable extended listen timing, IDLE state means that the
device is not listening to any messages and as such, not replying to
provisioning discovery is expected. In other words, if you want to be
discoverable, you will either need to leave the device in find or listen
state or to enable extended listen timing (p2p_ext_listen) to make it
periodically go to listen state for a short duration.

--

-- 
Jouni Malinen                                            PGP id EFC895FA

Waiting... How to connect signal "WpsCred"?

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

maybe a bug on eloop timeout

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

hostapd on multiple VAPs

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

[PATCH] hostapd: Add comment about CONFIG_FULL_DYNAMIC_VLAN to defconfig

Add comment about CONFIG_FULL_DYNAMIC_VLAN to defconfig. By default
this feature is still disabled.

Signed-off-by: Helmut Schaa <helmut.schaa <at> googlemail.com>
---
 hostapd/defconfig |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/hostapd/defconfig b/hostapd/defconfig
index 3ecb7e3..6e15b78 100644
--- a/hostapd/defconfig
+++ b/hostapd/defconfig
 <at>  <at>  -153,6 +153,10  <at>  <at>  CONFIG_IPV6=y
 # Remove support for VLANs
 #CONFIG_NO_VLAN=y

+# Enable support fur fully dynamic VLANs. This enables hostapd to
+# automatically create bridge and VLAN interfaces if necessary.
+#CONFIG_FULL_DYNAMIC_VLAN=y
+
 # Remove support for dumping state into a file on SIGUSR1 signal
 # This can be used to reduce binary size at the cost of disabling a debugging
 # option.
--

-- 
1.7.1

Re: hostapd on multiple VAPs

_______________________________________________
HostAP mailing list
HostAP <at> lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap

netif_carrier_on/eapol processing race condition

hi,

we are working with some old-version wpa_supplicant, and facing a
subtle race condition, but it looks like it exists in the latest
hostap git as well.

upon association, our driver calls netif_carrier_on() and sends an
association event.
the problem is, netif_carrier_on() clears the __LINK_STATE_NOCARRIER
flag immediately, but schedules a later work to do its actual work
(setting the qdiscs).
thus, the association event might come before the qdiscs are ready
(IFF_LOWER_UP flag will be up, though).
moreover, some eapol packet might come in this period, when the driver
is associated, but before the qdiscs are ready. this situation will
result in dropping of the eapol response.
a similar situation can be reproduced by disabling the call to
netif_carrier_on (i.e. the carrier will always be off).

the problem is somewhat similar to the "Delay processing of EAPOL
frames when not associated" patch
(http://lists.shmoo.com/pipermail/hostap/2009-November/020592.html).

does delaying the processing of eapol frames until the carrier is up
sounds like a reasonable solution?
(i implemented such a patch, which seems to work, but it uses some
ugly workaround in order to identify the actual RTM_NEWLINK event)

thanks,
Eliad.