[SPAM] Re: Fw: DHCP Fails to Pass Through HostAP AP

Primary Key Development dev at primarykey.ca
Wed Apr 29 03:10:13 EDT 2009


Hi Jouni,

Thanks for the reply.  Here are answers:

 > Have you verified whether the client is able to receive broadcast frames
 > when configured with a static IP address?

Yes, when configured statically network broadcasting works: the client is
able to discover and authenticate against an MS Active Directory domain.

 > I would expect this combination to work and I have noticed issues in my
 > tests. Though, most of the time I do not use bridging, but when I do,
 > Windows XP clients has been able to receive an IP address using DHCP.

How do you setup an access point without ethernet bridging?

 > I would suggest running a test with simpler configuration, e.g.:
 >
 > wpa=1
 > wpa_pairwise=TKIP
 >
 > and then another one with:
 >
 > wpa=2
 > wpa_pairwise=CCMP

I tried both configurations but neither succeeded.

 > DHCP should work fine without any additional configuration. The only
 > thing that I can think of as a reason would be some kind of problems in
 > delivering broadcast frames to the clients. I'm assuming that the DHCP
 > server is sending out the responses using broadcast frames in this case.

The following tests revealed some interesting results:

* When connecting to an ISC DHCP server through hostapd (DHCP server
residing on the same machine as hostapd), the XP clients work out of the
box.  Vista clients require a registry workaround to function (setting
'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}\DhcpConnEnableBcastFlagToggle' 

to '1)

* When connecting to an MS DHCP server (XP and Vista, registry 
workaround or not) through hostapd DHCP continues to fail: the client's 
requests pass through the AP, but fail and the client assumes the 
auto-configuration IP address.  Following is a tcpdump of this scenario 
(192.168.8.20 is the IP address of the MS Windows DHCP server):

...
02:25:24.722406 IP 192.168.8.20.bootps > 255.255.255.255.bootpc: 
BOOTP/DHCP,
Reply, length 311
02:25:37.413180 IP 192.168.8.20.netbios-dgm > 192.168.8.255.netbios-dgm: 
NBT
UDP PACKET(138)
02:25:53.552388 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:25:53.552381 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:25:54.315056 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:25:54.315049 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:25:55.078701 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:25:55.078695 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:26:02.681809 IP6 fe80::7539:17f5:ed25:2a38.65460 > ff02::1:3.hostmon:
UDP, length 24
02:26:02.681875 IP 169.254.42.56.65387 > 224.0.0.252.hostmon: UDP, length 24
02:26:02.681804 IP6 fe80::7539:17f5:ed25:2a38.65460 > ff02::1:3.hostmon:
UDP, length 24
02:26:02.681874 IP 169.254.42.56.65387 > 224.0.0.252.hostmon: UDP, length 24
02:26:02.785702 IP6 fe80::7539:17f5:ed25:2a38.65460 > ff02::1:3.hostmon:
UDP, length 24
02:26:02.785772 IP 169.254.42.56.65387 > 224.0.0.252.hostmon: UDP, length 24
02:26:02.785696 IP6 fe80::7539:17f5:ed25:2a38.65460 > ff02::1:3.hostmon:
UDP, length 24
02:26:02.785771 IP 169.254.42.56.65387 > 224.0.0.252.hostmon: UDP, length 24
02:26:02.988551 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:26:02.988545 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
02:26:03.752447 IP 169.254.42.56.netbios-ns > 169.254.255.255.netbios-ns:
NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
...

It looks like the MS DHCP server traffic can't pass return through the
access point.  DHCP requests to the MS DHCP server via a physical 
ethernet connection on the same network succeed.

Any thoughts?

Thanks
-JASON

----- Original Message -----
From: "Jouni Malinen" <j at w1.fi>
To: "Jason Daly" <jason2 at primarykey.ca>
Sent: Sunday, April 26, 2009 2:12 PM
Subject: Re: Fw: DHCP Fails to Pass Through HostAP AP


 > On Mon, Apr 27, 2009 at 04:18:54AM -0400, Jason Daly wrote:
 >
 >> Sorry to email you directly, but my emails continue to be marked by the
 >> HostAP mailing list as SPAM.  Do you know why?  Also, do you have 
insight
 >> on my inquiry below?:
 >
 > I have no idea what is marking the message as spam, but anyway, I do not
 > see the message you forwarded, so something is filtering it from me..
 > The message itself shows up on the mailing list archive, so I would
 > expect that it was delivered and just filtered in my local setup.
 >
 >> When connecting Windows (XP/Vista) wireless clients to a hostapd AP, 
DHCP
 >> offers do not succeed.  When setting the network interface settings on
 >> the
 >> client to use a static configuration connectivity succeeds and client
 >> networking through the AP functions well.
 >
 > Have you verified whether the client is able to receive broadcast frames
 > when configured with a static IP address?
 >
 >> DHCP is working and the bridge functions: I have confirmed this by
 >> successfully
 >> obtaining a DHCP lease via the notebook's LAN port.
 >
 > Have you tried using any other client (e.g., a Linux laptop) through
 > this AP using DHCP?
 >
 >> - hostapd 0.6.9
 >> - FC10(2.6.29.1-15.fc10.i686)
 >> - ath9k
 >
 > I would expect this combination to work and I have noticed issues in my
 > tests. Though, most of the time I do not use bridging, but when I do,
 > Windows XP clients has been able to receive an IP address using DHCP.
 >
 >> Following are the contents of my hostapd.conf file:
 >
 >> wpa=3
 >> wpa_key_mgmt=WPA-PSK
 >> wpa_pairwise=TKIP CCMP
 >
 > I would suggest running a test with simpler configuration, e.g.:
 >
 > wpa=1
 > wpa_pairwise=TKIP
 >
 > and then another one with:
 >
 > wpa=2
 > wpa_pairwise=CCMP
 >
 > In theory, this should not change anything as far as DHCP going through
 > the bridge is concerned, but at least it verifies whether the issue
 > shows up with CCMP as the group cipher or not.
 >
 >> Is there a setting in hostapd that must be added to allow DHCP to pass
 >> through
 >> the bridge.  UDP works fine through the bridge, as the client can 
see the
 >> Windows domain and can broadcast for clients on the domain (when
 >> connected
 >> via
 >> a static IP or via a physical LAN cable).
 >
 > DHCP should work fine without any additional configuration. The only
 > thing that I can think of as a reason would be some kind of problems in
 > delivering broadcast frames to the clients. I'm assuming that the DHCP
 > server is sending out the responses using broadcast frames in this case.
 >
 > --
 > Jouni Malinen                                            PGP id EFC895FA
 >




More information about the HostAP mailing list