[Commotion-dev] Preventing Commotion nodes from handing out DHCP?
Josh King
jking at chambana.net
Wed May 15 15:14:03 UTC 2013
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130515/e52ef262/attachment.sig>
More information about the Commotion-dev
mailing list