[Commotion-dev] Preventing Commotion nodes from handing out DHCP?

Preston Rhea prestonrhea at opentechinstitute.org
Wed May 15 15:32:11 UTC 2013


Thanks Josh.

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.
On May 15, 2013 11:13 AM, "Josh King" <jking at chambana.net> wrote:

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


More information about the Commotion-dev mailing list