[Commotion-dev] Commotion-splash ready to roll

[Ben West]

Great work Dan!

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.

So the effectiveness of the bandwidth throttling depends on the amount
available memory, with insufficient memory causing observed clients'
bandwidth to degrade.

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.

On Tue, May 7, 2013 at 8:09 PM, Dan Staples <
danstaples at opentechinstitute.org> wrote:

> Some background: the LuCI-splash captive portal software is buggy, and
> has been causing instability for the DR1 testing release of
> Commotion-OpenWRT. So I've set about replacing it with Nodogsplash
> (http://kokoro.ucsd.edu/nodogsplash/ [thanks for the suggestion, Ben!]),
> and adding a LuCI configuration page for it and a custom Commotion
> splash page. It's now ready for an initial component release and further
> testing.
>
> I've tested a brand new DR1 Picostation image with Commotion-splash, and
> it works great. If anyone wants a demo (in person or virtual), I can
> show you tomorrow or whenever. There was one issue that I saw today, in
> which nodogsplash reports using enormous amounts of memory ('VSZ') in
> top, in fact sometimes more than 100% of the reported available memory.
> Yet, the node still appears to have around the same amount of free
> memory as other DR1 nodes not running nodogsplash, and there have been
> no stability issues. So it could be just a fluke. If it doesn't cause
> problems, I'm not going to worry...
>
> I transferred ownership of the commotion-splash repo to OTI, and
> submitted pull requests for commotion-openwrt, luci-commotion, and
> commotion-feed, if any other OTI folks can review those.
>
> What's left is to come up with a solution for captive-portalling when no
> internet access is available (since nodogsplash can't man-in-the-middles
> HTTP requests when clients can't first resolve DNS queries). Josh King
> and I talked today about the possibility of running a second instance of
> dnsmasq to man-in-the-middle DNS requests for preauthenticated users.
> Hopefully that will work.
>
> Anyway, good riddance to buggy luci-splash!
>
> Dan
>
> --
> Dan Staples
>
> Open Technology Institute
> https://commotionwireless.net
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>



-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130508/0cb3ff94/attachment.html>