DHCP fails after suspend/resume

Sam Leffler sam at errno.com
Thu Feb 21 22:20:02 UTC 2008


Andreas Wetzel wrote:
> hi
> 
> I am having the problem, that after suspending and resuming, DHCP fails 
> to get
> an address.
> 
> The system is a ThinkPad T30 with an Atheros based mini-PCI wifi adapter 
> and
> FreeBSD 6.3-RELEASE installed. The wireless network is configured to use 
> WPA2
> with EAP-TTLS authentication. The server side also runs FreeBSD 6.3-RELEASE
> using hostapd, freeradius and the ISC dhcp server.
> 
> Manually doing an /etc/rc.d/netif stop ath0 followed by /etc/rc.d/netif 
> start
> ath0 doesn't work either. When I reboot the ThinkPad, the machine gets 
> an IP
> address instantaneously.
> 
> Checking the logfiles on the server side, I can see, that the EAP 
> negotiation
> after the resume works just fine. Also using ethereal I can see that the 
> DHCP
> requests arrive on the server, and the server sends replies. But the client
> does not seem to receive or react to those replies. I am not in to DHCP 
> that
> deep, but could this possibly be due to the server sending unicast replies
> instead of broadcast? Is the client supposed to do a DHCPRELEASE before 
> going
> to sleep mode?
> 
> Windows 2000, which runs in a dual-boot configuration on the ThinkPad can
> suspend/resume in the same setup without any problem, so I assume it's a
> client side problem.
> 
> Any help would be appreciated.
> 

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.

	Sam


More information about the freebsd-mobile mailing list