hostapd memory leak when connecting to Linux wpa_supplicant
Tue Dec 18 10:26:48 PST 2007
Jouni Malinen wrote:
> On Mon, Dec 17, 2007 at 10:45:07AM -0800, Ken Roberts wrote:
>> hostapd v0.5.8
>> wpa_supplicant v0.5.8
>> madwifi v0.9.3.3
>> kernel 188.8.131.52 <http://184.108.40.206> (recompiled for minimal drivers)
>> I've got 2 geode machines using the madwifi drivers. They worked great
>> for about a week. Unfortunately, hostapd started eating ram and causing
>> "out of memory and no programs to kill" errors on the ap running hostapd.
> How did you measure hostapd memory use? It sounds a bit odd if the
> kernel would not kill hostpad in such a case if the memory was indeed
> leaked in hostapd.
After the first halt, I did the following:
root at host# while /bin/true; do grep ^Mem /proc/meminfo ; echo "Sleep 2
seconds"; sleep 2; done
and watched the Memfree entry drop like a stone
>> When connecting to a Linux machine running wpa_supplicant, free ram
>> started dropping like a rock until "out of memory" condition caused a
>> system freeze.
> Have you looked at debug log from either hostapd or wpa_supplicant in
> this state? Do they show constant action (e.g., new
Lots of debugging where it was toggling between associating ->
Problem change: apparently, the problem was the script was not telling
wpa_supplicant which driver to use ( -Dmadwifi) when it called
wpa_supplicant - which may have caused the memory problem.
Now, unfortunately, it's not connecting at all - which is where I was
about a month ago when dealing with the eapol_version issue (among other
So - back to the configuration setup again and see what's changed.
More information about the Hostap