Great work Dan!<br><br>W/r/t to memory usage, do note that most any bandwidth throttling implementation, whether nodogsplash or the qos-scripts package, is ultimately using buckets to maintain the speed control on clients' sessions.  These buckets exist in memory, with faster bandwidth caps effectively being larger buckets that empty faster.<br>
<br>So the effectiveness of the bandwidth throttling depends on the amount available memory, with insufficient memory causing observed clients' bandwidth to degrade.<br><br>Still, I've generally had good success operating nodogsplash and coovachilli on nodes with 32MB RAM, and on average 2-3 simultaneous clients each with a 3Mbit/s cap.<br>
<br><div class="gmail_quote">On Tue, May 7, 2013 at 8:09 PM, Dan Staples <span dir="ltr"><<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Some background: the LuCI-splash captive portal software is buggy, and<br>
has been causing instability for the DR1 testing release of<br>
Commotion-OpenWRT. So I've set about replacing it with Nodogsplash<br>
(<a href="http://kokoro.ucsd.edu/nodogsplash/" target="_blank">http://kokoro.ucsd.edu/nodogsplash/</a> [thanks for the suggestion, Ben!]),<br>
and adding a LuCI configuration page for it and a custom Commotion<br>
splash page. It's now ready for an initial component release and further<br>
testing.<br>
<br>
I've tested a brand new DR1 Picostation image with Commotion-splash, and<br>
it works great. If anyone wants a demo (in person or virtual), I can<br>
show you tomorrow or whenever. There was one issue that I saw today, in<br>
which nodogsplash reports using enormous amounts of memory ('VSZ') in<br>
top, in fact sometimes more than 100% of the reported available memory.<br>
Yet, the node still appears to have around the same amount of free<br>
memory as other DR1 nodes not running nodogsplash, and there have been<br>
no stability issues. So it could be just a fluke. If it doesn't cause<br>
problems, I'm not going to worry...<br>
<br>
I transferred ownership of the commotion-splash repo to OTI, and<br>
submitted pull requests for commotion-openwrt, luci-commotion, and<br>
commotion-feed, if any other OTI folks can review those.<br>
<br>
What's left is to come up with a solution for captive-portalling when no<br>
internet access is available (since nodogsplash can't man-in-the-middles<br>
HTTP requests when clients can't first resolve DNS queries). Josh King<br>
and I talked today about the possibility of running a second instance of<br>
dnsmasq to man-in-the-middle DNS requests for preauthenticated users.<br>
Hopefully that will work.<br>
<br>
Anyway, good riddance to buggy luci-splash!<br>
<span class="HOEnZb"><font color="#888888"><br>
Dan<br>
<br>
--<br>
Dan Staples<br>
<br>
Open Technology Institute<br>
<a href="https://commotionwireless.net" target="_blank">https://commotionwireless.net</a><br>
<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>
</font></span></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>