David Young --> current-users (2007-08-07 20:37:17 -0500):
> It sounds like you are homing in on the problem!  What if you compare
> the logs in the failure case with the successes?  Do any differences
> stand out?

I don't see anything which seems to be relevant. I've put logs for
both hostapd and wpa_supplicant in both success and failure cases
online, and unified diffs between them:

	http://salmi.ch/~jukka/nbsd/hostapd_failure.log
	http://salmi.ch/~jukka/nbsd/hostapd_success.log
	http://salmi.ch/~jukka/nbsd/hostapd.diff

	http://salmi.ch/~jukka/nbsd/wpa_supplicant_failure.log
	http://salmi.ch/~jukka/nbsd/wpa_supplicant_success.log
	http://salmi.ch/~jukka/nbsd/wpa_supplicant.diff

At first I suspected the "RTM_IFINFO: Interface 'ath0' UP" which I
only see in the failure case. That's probably dhclient which is started
here before wpa_supplicant authenticates. But even changing
/etc/rc.d/dhclient to wait until network is available didn't fix the
problem: wpa_supplicant doesn't log the "RTM_IFINFO: Interface 'ath0'
UP" anymore, but at the first rekeying hostapd times out and the client
is disconnected as usual...


> If dhclient and wpa_supplicant are not coordinated in some way, then
> dhclient may down/up the interface and kill some crypto state that
> way.  (Let me head off the inevitable complaint that dhclient-script
> gratuitously downs/ups interfaces with a hearty "patches welcome!")
> 
> Incidentally, does your ath attach at cardbus or at pci?

PCI.


Regards, Jukka

-- 
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~