[Commotion-dev] Preventing Commotion nodes from handing out DHCP?
Will Hawkins
hawkinsw at opentechinstitute.org
Wed May 15 15:34:40 UTC 2013
Since the 192.168.1.20 address is "always" available, you will probably
be okay. In other words, you can always ssh into the node through that
interface and then determine the node's true IP address that way. Of
course, firewall issues might prevent that.
It's also possible to keep the AP on until you have successfully
configured and tested the node. Then, when things are stable, simply
turn off the AP.
Will
On 05/15/2013 11:32 AM, Preston Rhea wrote:
> 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
> <mailto: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>
> > <mailto: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>
> > <mailto: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>
> <mailto: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>
> <tel:%2B1-202-570-9770>
> > > > > Twitter: @prestonrhea
> > > > >
> > > > > _______________________________________________
> > > > > Commotion-dev mailing list
> > > > > Commotion-dev at lists.chambana.net
> <mailto:Commotion-dev at lists.chambana.net>
> > <mailto: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>
> > <mailto: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>
> > <mailto: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
>
More information about the Commotion-dev
mailing list