DHCPDISCOVER at times not encrypted
dcbw at redhat.com
Mon May 6 13:28:32 EDT 2013
On Fri, 2013-05-03 at 19:08 +0000, Garcia, Paul D wrote:
> I am running a python script that:
> 1) initializes the wpa_supplicant:
> sudo /usr/local/sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant/wireless_test.conf -d
> 2) releases and initializes DHCP:
> sudo dhclient -r wlan0
> sudo dhclient -v wlan0
Is your script waiting until the supplicant has completed the connection
to the network before running DHCP? That isn't instantaneous, and the
only way you know that everything is ready to be run with DHCP is by
listening to the supplicant, either via dbus or the socket control
> 3) Performs other activities
> 4) resets the wpa_supplicant
> 5) starts again from step 1)
> The reason for the post is this - there are times when DHCP negotiation does not work. My investigation determined that during the times of DHCP failure, the DHCPDISCOVER packet is sent in the clear. This is from an over-the-air packet capture. Normally, the DHCPDISCOVER packet is encrypted and only appears as 802.11 traffic with an encrypted payload. When the DCHPDISCOVER is sent in the clear the AP, by design, does not forward the request along to the network.
> I am trying to determine how I can further troubleshoot (debug) reasons for this frame being sent in the clear.
> Following are driver and other (hopefully) pertinent info.
> driver: ath9k
> network controller: Network controller: Atheros Communications Inc. AR9300 Wireless LAN adaptor (rev 01)
> OS: 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.35-2~bpo60+1 x86_64 GNU/Linux
> wpa_supplicant version: wpa_supplicant v2.0
> identity="x at uiowa.edu"
> anonymous_identity="x at uiowa.edu"
> any help would be greatly appreciated.
> Paul Garcia
> HostAP mailing list
> HostAP at lists.shmoo.com
More information about the HostAP