<p dir="ltr">No, how many leases can be given out.</p>
<div class="gmail_quote">On May 8, 2013 2:29 PM, "Georgia Bullen" <<a href="mailto:georgia@opentechinstitute.org">georgia@opentechinstitute.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Preston - you're talking about how long the lease is for right? 1 hour vs longer? not how many leases are given out?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 8, 2013 at 2:05 PM, Preston Rhea <span dir="ltr"><<a href="mailto:prestonrhea@opentechinstitute.org" target="_blank">prestonrhea@opentechinstitute.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just, I remember a bug with the splash page lease limits that we<br>
reported for like eight months, and never got resolved until the team<br>
had to make it work for AMC ;)<br>
<br>
You don't know until you know you know!<br>
<div><div><br>
On Wed, May 8, 2013 at 1:55 PM, Dan Staples<br>
<<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>> wrote:<br>
> We should connect as many devices as we can to test it out. Since we<br>
> aren't using bandwidth limiting, it theoretically shouldn't provide<br>
> much of a burden on the router to have a lot of clients.<br>
><br>
> On Wed 08 May 2013 12:48:51 PM EDT, Preston Rhea wrote:<br>
>> For field deployments we'll need to make sure nodogsplash can handle<br>
>> much more than 3 simultaneous leases. Let's test this on Friday. How<br>
>> many leases can we get on a node at once?<br>
>><br>
>> On Wed, May 8, 2013 at 11:34 AM, Dan Staples<br>
>> <<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>> wrote:<br>
>>> Glad to hear you've had success with nodogsplash. I'm actually not<br>
>>> using nodogsplash's bandwidth throttling, since it seems that it<br>
>>> doesn't work anymore on Attitude Adjustment. I'll do some more testing<br>
>>> today to see if there are any stability issues.<br>
>>><br>
>>> On Wed 08 May 2013 11:13:58 AM EDT, Ben West wrote:<br>
>>>> Great work Dan!<br>
>>>><br>
>>>> W/r/t to memory usage, do note that most any bandwidth throttling<br>
>>>> implementation, whether nodogsplash or the qos-scripts package, is<br>
>>>> ultimately using buckets to maintain the speed control on clients'<br>
>>>> sessions. These buckets exist in memory, with faster bandwidth caps<br>
>>>> effectively being larger buckets that empty faster.<br>
>>>><br>
>>>> So the effectiveness of the bandwidth throttling depends on the amount<br>
>>>> available memory, with insufficient memory causing observed clients'<br>
>>>> bandwidth to degrade.<br>
>>>><br>
>>>> Still, I've generally had good success operating nodogsplash and<br>
>>>> coovachilli on nodes with 32MB RAM, and on average 2-3 simultaneous<br>
>>>> clients each with a 3Mbit/s cap.<br>
>>>><br>
>>>> On Tue, May 7, 2013 at 8:09 PM, Dan Staples<br>
>>>> <<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a><br>
>>>> <mailto:<a href="mailto:danstaples@opentechinstitute.org" target="_blank">danstaples@opentechinstitute.org</a>>> wrote:<br>
>>>><br>
>>>> 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,<br>
>>>> 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<br>
>>>> further<br>
>>>> testing.<br>
>>>><br>
>>>> I've tested a brand new DR1 Picostation image with<br>
>>>> 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<br>
>>>> 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<br>
>>>> 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<br>
>>>> when no<br>
>>>> internet access is available (since nodogsplash can't<br>
>>>> 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<br>
>>>> 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>
>>>><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" target="_blank">Commotion-dev@lists.chambana.net</a><br>
>>>> <mailto:<a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">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>
>>>><br>
>>>><br>
>>>><br>
>>>> --<br>
>>>> Ben West<br>
>>>> <a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br>
>>>> <a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a> <mailto:<a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a>><br>
>>>> <a href="tel:314-246-9434" value="+13142469434" target="_blank">314-246-9434</a><br>
>>><br>
>>> --<br>
>>> Dan Staples<br>
>>><br>
>>> Open Technology Institute<br>
>>> <a href="https://commotionwireless.net" target="_blank">https://commotionwireless.net</a><br>
>>> _______________________________________________<br>
>>> Commotion-dev mailing list<br>
>>> <a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">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>
>><br>
>><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>
<br>
</div></div><div>--<br>
Preston Rhea<br>
Program Associate, Open Technology Institute<br>
New America Foundation<br>
<a href="tel:%2B1-202-570-9770" value="+12025709770" target="_blank">+1-202-570-9770</a><br>
Twitter: @prestonrhea<br>
</div><div><div>_______________________________________________<br>
Commotion-dev mailing list<br>
<a href="mailto:Commotion-dev@lists.chambana.net" target="_blank">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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Georgia Bullen<div>Field Operations Technologist, <a href="http://oti.newamerica.net/" target="_blank">Open Technology Institute</a></div><div>New America Foundation</div>
</div>
</blockquote></div>