<p dir="ltr">Thanks Josh.</p>
<p dir="ltr">I'm realizing that this configuration - DHCP client mode, and AP turned off - may be a catch-22 since it will be only possible to access these nodes over the mesh.</p>
<div class="gmail_quote">On May 15, 2013 11:13 AM, "Josh King" <<a href="mailto:jking@chambana.net">jking@chambana.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Preston,<br>
<br>
If you are connecting to the router over ethernet, then if it fails to<br>
get a lease on the DHCP interface then the interface will not come up,<br>
which includes the 192.168.1.20 alias. You'll need to put it on a<br>
network where it can get a DHCP lease, give it a lease from your laptop,<br>
or connect to it over wireless.<br>
<br>
On Wed 15 May 2013 11:10:31 AM EDT, Preston Rhea wrote:<br>
> I went with Josh's recommendation, but once I clicked save and apply,<br>
> the system hung on "waiting for router to update." I tried reopening<br>
> the window and got no connection. I power cycled the router and it<br>
> won't even let me ping the router.<br>
><br>
> By implementing dhcp client only, did I make it impossible to interact<br>
> with the device via Ethernet? Or did I just brick the router?<br>
><br>
> On May 15, 2013 1:03 AM, "Will Hawkins"<br>
> <<a href="mailto:hawkinsw@opentechinstitute.org">hawkinsw@opentechinstitute.org</a><br>
> <mailto:<a href="mailto:hawkinsw@opentechinstitute.org">hawkinsw@opentechinstitute.org</a>>> wrote:<br>
><br>
> Possible update, see below:<br>
><br>
> On Wednesday, May 15, 2013 00:36 EDT, "Will Hawkins"<br>
> <<a href="mailto:hawkinsw@opentechinstitute.org">hawkinsw@opentechinstitute.org</a><br>
> <mailto:<a href="mailto:hawkinsw@opentechinstitute.org">hawkinsw@opentechinstitute.org</a>>> wrote:<br>
><br>
> > You all beat me to it!<br>
> ><br>
> > I think that Josh made an excellent, easy suggestion. In fact,<br>
> it is so good and obvious that my planned response now looks silly.<br>
> ><br>
> > Since Josh's suggestion will do the trick, feel free to stop<br>
> reading. But, if you're interested here's how I was going to respond:<br>
> ><br>
> > I pulled up the function that sets the interface information for<br>
> a Commotion Plug type interface. That's in<br>
> /lib/network/commotion.sh. You can view the file through the web<br>
> here:<br>
> <a href="https://github.com/opentechinstitute/commotion-openwrt/blob/master/commotionfeed/commotionbase/files/lib/network/commotion.sh" target="_blank">https://github.com/opentechinstitute/commotion-openwrt/blob/master/commotionfeed/commotionbase/files/lib/network/commotion.sh</a><br>
> ><br>
> > Check down to line 519. We need to change the parameters to<br>
> udhcpc (stored in the variable $dhcpopts). The existing options<br>
> (-q -n) tell udhcpc to attempt to obtain a dhcp lease and a) exit<br>
> immediately after a lease is obtained and b) exit and return<br>
> failure if a lease cannot be obtained. In your case, the desired<br>
> behavior is be for udhcpc to continuously ask for a lease until it<br>
> gets one and then continue to refresh that lease periodically. To<br>
> do that we just let udhcpc do its default behavior by removing<br>
> those options entirely. Line 519 becomes<br>
> > local dhcpopts=""<br>
> ><br>
><br>
> I just realized that udhcpc might not ever go into the background<br>
> without using the -b option. The -b option means "Background if<br>
> lease is not immediately obtained". This is definitely what we<br>
> want, but I can't say for sure whether the option is necessary or<br>
> not. If udhcpc never goes into the background, the node will sit<br>
> there waiting to complete its boot process until it gets a lease.<br>
> A problem indeed.<br>
><br>
> And, just to be clear,<br>
><br>
> a) Josh is the expert,<br>
> b) My suggestions are untested,<br>
> c) I'm trying to be helpful, and<br>
> d) Josh is the expert. :-)<br>
><br>
> Will<br>
><br>
> > That's not enough, though. We need to also tell remainder of the<br>
> function to execute the code for case 0 (which means that udhcpc<br>
> successfully got a lease) no matter what. The "easiest" way to do<br>
> that would be to change line 530 to look like:<br>
> > case "0" in<br>
> ><br>
> > With these changes, the behavior would be<br>
> ><br>
> > 1) plug interface comes up,<br>
> > 2) udhcpc asks for an IP address and<br>
> > 3) the plug interface never acts as a dhcp server.<br>
> ><br>
> > In essence, this is exactly what Josh's suggestion accomplishes.<br>
> I will defer to Josh on the implications for his suggestion w.r.t.<br>
> to olsrd. There may be some special "stuff" that has to happen for<br>
> networks on the plug interfaces to get into hna for olsrd.<br>
> ><br>
> > I hope that this was helpful and not rambling. Please keep us<br>
> posted tomorrow if you need help. We'll be around on IRC, etc.<br>
> ><br>
> > Will<br>
> ><br>
> ><br>
> > On Tuesday, May 14, 2013 21:37 EDT, Josh King<br>
> <<a href="mailto:jking@chambana.net">jking@chambana.net</a> <mailto:<a href="mailto:jking@chambana.net">jking@chambana.net</a>>> wrote:<br>
> ><br>
> > > Hi Preston,<br>
> > ><br>
> > > I do not have a node in front of me at the moment so I can't<br>
> tell for<br>
> > > certain (I am referencing my home router, which is running a<br>
> different<br>
> > > version of OpenWRT), but you should be able to set this fairly<br>
> easily<br>
> > > through the LuCI admin interface. In the admin interface, just<br>
> go to<br>
> > > Network->Interfaces->Plug. There should be a dropdown menu for<br>
> > > "Protocol." Switch it to "DHCP Client," and click "Switch<br>
> Protocol."<br>
> > > This will remove the ethernet interface from Commotion's<br>
> configuration,<br>
> > > and instead it will just be a normal DHCP interface. Is the node<br>
> > > intended to advertise that interface as a gateway?<br>
> > ><br>
> > > On 05/14/2013 04:52 PM, Preston Rhea wrote:<br>
> > > > Hello dev team,<br>
> > > ><br>
> > > > Tomorrow, we are going up the Visitation Rectory steeple in<br>
> Red Hook<br>
> > > > to install a co-ordinated distribution layer and Commotion layer<br>
> > > > co-location site. BKFiber will install some stock 5GHz and<br>
> 900MHz<br>
> > > > equipment at the top of the steeple, we'll put two Commotion<br>
> > > > NanoStations in the middle of the steeple, and all will be<br>
> connected<br>
> > > > by a Ubiquiti ToughSwitch.<br>
> > > ><br>
> > > > The issue: we want the Commotion nodes to not interfere with<br>
> DHCP<br>
> > > > leases. Those should all be left up to the BKfiber<br>
> infrastructure - we<br>
> > > > need to ensure that the Commotion nodes can only receive,<br>
> never give<br>
> > > > out, DHCP leases. This is in line with our multi-layer<br>
> approach, with<br>
> > > > a Commotion community-managed layer hanging off of a<br>
> > > > professionally-managed distribution layer. So even if the<br>
> power goes<br>
> > > > out, this should always be the case when the power comes<br>
> back on.<br>
> > > ><br>
> > > > The question: What exactly should I do to make this happen<br>
> on the<br>
> > > > Commotion nodes? If you can email a precise solution, it<br>
> will A: help<br>
> > > > me since I will be in the steeple all day, and B: help us<br>
> turn it into<br>
> > > > nice documentation for the future.<br>
> > > ><br>
> > > > Thanks!<br>
> > > ><br>
> > > > Preston<br>
> > > ><br>
> > > ><br>
> > > > --<br>
> > > > Preston Rhea<br>
> > > > Program Associate, Open Technology Institute<br>
> > > > New America Foundation<br>
> > > > <a href="tel:%2B1-202-570-9770" value="+12025709770">+1-202-570-9770</a> <tel:%2B1-202-570-9770><br>
> > > > Twitter: @prestonrhea<br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > Commotion-dev mailing list<br>
> > > > <a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
> <mailto:<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>
> > ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Commotion-dev mailing list<br>
> > <a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
> <mailto:<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>
><br>
><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Commotion-dev mailing list<br>
> <a href="mailto:Commotion-dev@lists.chambana.net">Commotion-dev@lists.chambana.net</a><br>
> <mailto:<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>
><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>
<br>
</blockquote></div>