hostapd memory leak when connecting to Linux wpa_supplicant

[Ken Roberts]

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 2.6.21.5 <http://2.6.21.5> (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
> associations/authentications)?
>   
Lots of debugging where it was toggling between associating -> 
disconnecting.

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 
things).

So - back to the configuration setup again and see what's changed.