DHCP fails after suspend/resume

[Andreas Wetzel]

Sam Leffler wrote:

> Sounds like the h/w lost the crypto keys if you can see the DHCP frames 
> as they should be encrypted.  Unfortunately none of my Thinkpads have 
> had working suspend/resume forever so it's hard for me to investigate. 
> If you want to investigate turn on debug msgs in the 802.11 layer and 
> the ath driver to watch what happens plumbing keys:
> 
> wlandebug crypto
> athdebug key
> 
> You'll need to build the driver with ATH_DEBUG enabled to get debug msgs.

I forgot to mention, that currently I am doing an /etc/rc.d/netif stop from
the /etc/rc.suspend script, and an /etc/rc.d/netif start from the
/etc/rc.resume script. Otherwise, after the resume, I end up having multiple
instances of dhclient running on ath0. This implies restarting wpa_supplicant
and dhclient. Am I wrong or does this set up completely new encryption keys?
The radius server log shows a successful EAP-TTLS login after the resume, and
ath0 on the ThinkPad shows that is has associated to the network.

A little hacking of the dhclient source has discovered, that when I set the
BOOTP Broadcast flag in the DHCPREQUEST packet, dhclient succeeds in getting
an address from the DHCP server. But then another problem pops up. ARP does
not seem to function. So maybe you are right about problems with the
encryption keys. What I do not quite understand is, why should I see encrypted
traffic, when running ethereal on ath0 on the server machine running hostapd?

-- 
Keep it icy man.
I don't want to end up a corpse before my time because you were daydreaming.