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

[Ben West]

Wow, that steeple looks pretty tall on Google Maps.  Cool!  Besides the
Commotion wiki<https://code.commotionwireless.net/projects/commotion-manual/wiki/Step_by_Step_Guide>
pages<https://code.commotionwireless.net/projects/commotion-manual/wiki/Grounding_and_Lightning_Protection>
that<https://code.commotionwireless.net/projects/commotion-manual/wiki/Rooftop_Mounting_Guide>
already<https://code.commotionwireless.net/projects/commotion-manual/wiki/Installation_Safety_Checklist>cover
this, will you be using
*shielded* cat5 cable with cat5 surge arrestors?  I'm guessing that steeple
is the tallest structure for at least a few blocks, so it will be getting
visits from lightening.  The steeple should have rods up top and thick
ground cable to divert direct strikes, but you'll still want shielded cable
to prevent induced surge from fusing the ethernet chips.  I did just
recently retrieve a Nanostation M5 from a 3rd floor roof whose primary LAN
port burned out, presumably since I installed it using unshielded cable a
couple years ago.

Also, removing dnsmasq does indeed remove exactly that which would issue
DHCP leases.  However, do you know that the 10.x.x.x, 101.x.x.x, 102.x.x.x,
etc subnets which the Commotion nodes must route will be the same for all
use cases?  That is, the NAT thru the nodes generally assumes traffic
entering each interface to have a source IP within one of the subnets
configured, independent of who is giving out DHCP leases.

P.S. BKFiber looks pretty cool as a local WISP.  Is anyone on this list in
good rapport with them?  Discussions on other OTI lists about meshy
business models piques my curiosity w/r/t/ what BKFiber is up to.

On Tue, May 14, 2013 at 6:32 PM, Preston Rhea <
prestonrhea at opentechinstitute.org> wrote:

> @Dan: that may work, but it's not really what we're looking for. Isn't
> there a way to do this with a config change, instead of removing a
> package?
>
> @Paul: (1) is correct, (2) is not right in this particular case since
> they will be sharing a common power distribution from the ToughSwitch.
> Only at this site (for now) are we worried about this, so (3) actually
> if the distribution node at this site goes down, ideally you would be
> able to hop through these Commotion nodes to _another_ gateway that
> has a Commotion co-location in the neighborhood.
>
> Name of the game is to not conflict with the BKFiber kit, and prevent
> routing loops from occurring.
>
> On Tue, May 14, 2013 at 5:43 PM, Dan Staples
> <danstaples at opentechinstitute.org> wrote:
> > Hi Preston,
> >
> > To prevent these nodes from ever giving out DHCP leases, forever and for
> > all time, it should be enough to remove DNSMasq ("opkg remove dnsmasq"),
> > since that is the program that hands out DHCP leases. But then it can
> > still request/receive DHCP leases. Best of luck tomorrow!
> >
> > Dan
> >
> > 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
> >> Twitter: @prestonrhea
> >>
> >> _______________________________________________
> >> Commotion-dev mailing list
> >> Commotion-dev at lists.chambana.net
> >> https://lists.chambana.net/mailman/listinfo/commotion-dev
> >>
> >
> > --
> > Dan Staples
> >
> > Open Technology Institute
> > https://commotionwireless.net
> >
> > _______________________________________________
> > Commotion-dev mailing list
> > Commotion-dev at lists.chambana.net
> > https://lists.chambana.net/mailman/listinfo/commotion-dev
> >
>
>
>
> --
> Preston Rhea
> Program Associate, Open Technology Institute
> New America Foundation
> +1-202-570-9770
> Twitter: @prestonrhea
>
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> https://lists.chambana.net/mailman/listinfo/commotion-dev
>
>


-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20130514/beeb4c31/attachment-0001.html>