[Commotion-dev] Preventing Commotion nodes from handing out DHCP?
Josh King
jking at chambana.net
Wed May 15 15:49:17 UTC 2013
Actually, that alias does not come up if the interface fails to come
up, i.e. if it fails to get a lease. But yes, Will is right about
turning off the AP after testing.
Sorry, I should have anticipated that you might need to shut off the AP
as well.
One possibility that I forgot to mention is that, depending on the
state of the plug interface previously, it might end up in the wrong
firewall zone. I don't know that that would result in what you're
seeing, but it might. In addition to the previous steps, on what I
believe is the same page where you switch the protocol, make sure that
the ethernet interface is in firewall zone "WAN."
On Wed 15 May 2013 11:34:40 AM EDT, Will Hawkins wrote:
> 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