<div dir="ltr"><div>I recently saw a WasabiNet node whose adhoc interface died due to memory exhaustion, and I should point out on a node <i>not</i> running serval or commotiond.  (I.e. since this isn't Commotion-OpenWRT firmware I'm writing about, but very similar.)  The relevant dmesg I've sent to the OpenWRT-devel list, which you can read here:<br>


<br><a href="https://lists.openwrt.org/pipermail/openwrt-devel/2013-November/022398.html">https://lists.openwrt.org/pipermail/openwrt-devel/2013-November/022398.html</a><br><a href="https://lists.openwrt.org/pipermail/openwrt-devel/2013-November/022399.html">https://lists.openwrt.org/pipermail/openwrt-devel/2013-November/022399.html</a><br>

<br></div>If particular interest is that, since the node didn't spontaneously reboot or become inaccessible, I SSH'ed in and found a 240Kbyte dump file that wpa_supplicant had written to /tmp , with about the same timestamp as when memory errors began appearing in syslog.  Possibly this points to wpa_supplicant itself as source of intermittent memory leaks?  I'm using the wpad package, and I haven't yet had a chance to try out the version of wpad-mini modified to include IBSS-RSN support.  I would be curious if switching to wpad-mini has any effect on the memory errors you're seeing, Will.<br>


<div><br></div><div>Besides that, do please note that I run the coovachilli captive portal, instead of NDS, and coova is definitely a memory hog of questionable stability.  That is, coova may end up being my problem, making this unrelated to Commotion.<br>


</div><div><br></div><div>Finally, check out these recommended kernel tweaks from OpenWRT-devel for having the node just spontaneously reboot upon OOM error or kernel oops.  Naturally, these wouldn't fix the memory problem itself, but good to know for reference.<br>


</div><div><br>" for routers in production i prefer setting<br>
/proc/sys/vm/panic_on_oom = 2<br>
/proc/sys/kernel/panic = 10<br>
<br>
also if you like<br>
/proc/sys/kernel/panic_on_oops = 1 "<br><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 11, 2013 at 6:53 PM, Will Hawkins <span dir="ltr"><<a href="mailto:hawkinsw@opentechinstitute.org" target="_blank">hawkinsw@opentechinstitute.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Using go (yes, that's right!) I was able to create a test program that<br>
opened enough simultaneous HTTP connections to force a crash.<br>
<br>
Thanks to the fact that we were running a serial console that was<br>
logging Pico station console output, we were able to capture the crash<br>
information. I am attaching that here.<br>
<br>
Overall, it looks like the node simply runs out of memory. The first<br>
errors are when malloc()s in servald fail Then, when things get really<br>
bad, there are errors from the wireless driver saying that it cannot<br>
allocate buffer space.<br>
<br>
Obviously the failures from the wireless driver are bad. They are<br>
probably ultimately what causes the node to reboot.<br>
<br>
I wonder, though, about the servald malloc() failures. I'm not sure if<br>
they are pure symptom (i.e, servald just happens to be the application<br>
most commonly allocating memory space when the crash happens and so its<br>
malloc()s fail first), or if it is part of the problem (i.e, servald<br>
causes memory usage to skyrocket under heavy load and *then* these<br>
larger memory problems start to occur).<br>
<br>
In any event, we got some logs, which is a good first step!<br>
<span class="HOEnZb"><font color="#888888"><br>
Will<br>
</font></span><br>_______________________________________________<br>
Commotion-dev mailing list<br>
<a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
<a href="https://lists.chambana.net/mailman/listinfo/commotion-dev" target="_blank">https://lists.chambana.net/mailman/listinfo/commotion-dev</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br>

</div>
</div>