DHCPDISCOVER at times not encrypted

[Garcia, Paul D]

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
    
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

wpa_supplicant.conf:

ctrl_interface=/var/run/wpa_supplicant
network={
    scan_ssid=0
    ssid="eduroam"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="x at uiowa.edu"
    anonymous_identity="x at uiowa.edu"
    password="password"
    phase2="autheap=MSCHAPV2"
    phase1="peapver=0"
}

any help would be greatly appreciated.

thanks,

Paul Garcia