[Commotion-discuss] RPi Gateway
Josh Harle
josh.harle at gmail.com
Sun Mar 29 13:14:46 EDT 2015
Thanks again Josh; a fantastic explanation. I'll try tomorrow with the
192.x.x.x address and see how it fares!
One last question about setting up my mesh across a small town for an
upcoming festival. I've got about 20 mesh nodes, and 10 APs to go across
the town, and hopefully will have reasonable connectivity from one side to
the other (This is the layout so far
https://www.google.com/maps/d/edit?mid=zQWZjENFsI9g.kXh0LhMsEN6U)
I'm wondering what sort of performance I should expect from an 8-10 hop
link, if the server is on one end of town? If the ETX is good (~1). Not
seeing how such a chain of nodes behaves, I can easily imagine it either
being fantastic, or abysmal.
I'm contemplating getting 4 nanobeams to linkup one side to the other via a
high point in the middle of the town, and give it a bit more redundancy.
Kind Regards,
Josh Harle
BSc (Hons) BA BFA PhD
____________________
http://joshharle.com
http://tacticalspace.org
ph: +61 (0)491 155 985
On 26 March 2015 at 23:09, Josh King <jking at opentechinstitute.org> wrote:
> Hi Josh,
>
> This question kind of gets to where the mesh routing comes in. So, here
> I'm assuming that your pi is connected via ethernet to a Commotion node,
> and that the node is not setup specifically to mesh over ethernet with
> the pi.
>
> The first thing to be aware of is that just setting the pi to a
> 100.64.0.0/10 (the default subnet for Commotion mesh IPv4 addresses)
> address will not make it connectible if it's attached to the client
> network of a node (i.e., connected to the node in such a way that it
> would normally receive a DHCP lease from the node, such as via
> connecting to the AP). Here I'm using 'client network' and 'client
> interface' to indicate a network interface via which non-mesh devices
> would connect to the node. That's because the client interfaces of the
> node have a 10.0.0.0/8 subnet and hand out addresses in a uniquely
> generated 10.x.x.0/24 range. Since a 100.64.0.0/10 address is not in
> that range, they would not be connectible.
>
> So what if you statically set a 100.64.0.0/10 address and you _were_
> connected via a mesh interface? For instance, if the pi had a wireless
> interface and you set it up to associate with the adhoc network? Well,
> this would sort of work, but you would only be connectible for one hop
> for what I assume is the same reason that your 10.1.2.1 address is only
> connectible over one hop; the mesh routing is not aware of your device.
>
> Basically what the mesh routing does (in this case we're using the OLSRd
> daemon, but we can at least conceptualize other mesh routing software as
> being broadly similar) is that each node says "I'm here! I've got an
> address of 100.64.x.x!" This information is passed to each of their
> immediate neighbors, and then to each of their neighbors, and so on. As
> this information is passed along and added to, we're able to build a
> picture of the network (not all mesh networks build a picture of the
> whole network, but for the purposes of this example we'll pretend they
> do). This picture is inserted into the device's routing table, so that
> when node A wants to send a message to node D, it's able to look up how
> to route to node D and say "Oh, in order to get to node D I have to send
> a message to node C. How to I get to node C? Oh, I have to send a
> message to node B..." and so on (this is an oversimplification because
> really the routing table doesn't need to know every hop in the network,
> but it's a useful illustration).
>
> So if you were connected via a mesh interface and statically set an
> address in the 100.64.0.0/10 range, nodes that are link-local to you
> would be able to ping you just because you're within the same address
> range. But further away than that, unless you're also running OLSRd,
> other nodes won't know how to get to you because your device is not
> telling them where it is.
>
> Now, for your 10.1.2.1 pi, connected on the client network. In addition
> to telling the network where it is, a node can tell the network "hey,
> I'm ALSO connected to these non-mesh client networks. So if you want to
> talk to a host in network 10.x.x.0/24, talk to me!" For OLSRd, these are
> called Host Network Announcements, or HNAs. So it sounds like the node
> you're connected to probably is sending out HNAs saying it's connected
> to something like 10.232.91.0/24, which is the network it's handing out
> DHCP leases in. Your pi, though, is configured with an address that
> isn't in that subnet, so the rest of the network doesn't know how to
> reach you. The node it's connected to is only advertising that it's
> connected to 10.232.91.0/24. It's pingable from the node it's connected
> to, because it's link local and the node's client interface is
> configured with a /8 subnet, but it's not consistent with what the node
> is telling to the rest of the network.
>
> You would most likely be able to make your pi connectible by either:
> * having it get a DHCP lease from your node, so that its address will be
> in the correct subnet (10.232.91.0/24 or whatever it is for that
> specific node)
> * statically set an IP address in the correct subnet
>
> It also occurs to me the use case where the pi is the gateway, and so
> it's upstream of the node and handing out an IP address _to_ the node.
> In this case, the problem may be much simpler. You are specifying a
> 10.0.0.0/8 address, but the nodes all have 10.0.0.0/8 addresses already.
> If you tried to ping 10.1.2.1 from a node other than the one to which
> the pi is connected, it would try pinging on its own local interface,
> not sending it to the gateway. If that's the case, then you could
> probably get around the IP conflict by simply setting the pi to have
> addresses in a different private subnet, like 192.168.0.0/16.
>
> Sorry for the long explanation, but I hope it's helpful.
>
> On 03/25/2015 01:12 AM, Josh Harle wrote:
> > Hi Josh,
> >
> > That was gold, thank you. Solves the mystery for me of the differing
> > behaviour between my DNS server and an internet gateway.
> >
> > I have a followup question which I think is probably pretty obvious, but
> > it's been a long time since I've had my head more convincingly around IP
> > routing:
> >
> > * my dns server RPi is currently static IP of 10.1.2.1, which is
> > visible from its directly connected node, but can't be
> > pinged/connected to from elsewhere.
> >
> > * My mesh nodes have mesh addresses that are
> > 100.116.232.166, 100.116.232.91, 100.116.233.5, and the like. Local
> > clients on these nodes are given IP addresses along the lines
> > of 10.232.91.x by the node with mesh IP 100.116.232.91.
> >
> > Would simply giving my RPi a static mesh address along the lines of
> > 100.116.232.50 allow it to be seen from everywhere?
> >
> > Again, apologies for the level of fog-headedness of this question. I
> > wear many hats, and that one fell of.
> >
> >
> >
> >
> > Kind Regards,
> >
> > Josh Harle
> > BSc (Hons) BA BFA PhD
> > ____________________
> > http://joshharle.com
> > http://tacticalspace.org <http://tacticalspace.org/>
> > ph: +61 (0)491 155 985
> >
> > On 24 March 2015 at 23:15, Josh King <jking at opentechinstitute.org
> > <mailto:jking at opentechinstitute.org>> wrote:
> >
> > Hi Josh,
> >
> > The nodes don't actually propagate DNS information on their own.
> Rather
> > than using the DNS server that is passed by the DHCP lease, it uses
> one
> > which is statically configured for that network profile, unless it is
> > overridden (which is what is being done in part 2 of the
> instructions).
> > Without that being overridden, by default the nodes use
> 208.67.222.222
> > (an OpenDNS public server) as their upstream DNS server for things
> not
> > on their local domain (.mesh.local).
> >
> > The captive portal included on the node runs on each individual node
> and
> > so uses the node's own local DNS server (which in turn uses the IP
> > address above for upstream queries). Part of configuring the nodes to
> > use a different, centralized captive portal or access management
> > solution would presumably could involve configuring them to use one
> or
> > more DNS servers provided by the centralized captive portal/access
> > management server, much as those are being configured above.
> >
> > DNS servers can also be configured through the 'advanced' GUI
> interface,
> > and in a large deployment one could create custom images that
> pre-load
> > that information. So there are methods one could use to streamline
> the
> > process somewhat.
> >
> > Does that help answer your question?
> >
> > On 03/24/2015 12:45 AM, Josh Harle wrote:
> > > Hi Josh,
> > >
> > > That's a nice sanity check for me, but I'm wondering why you need
> to do
> > > the stage "Changing DNS server information on each node" at all?
> > >
> > > Why when you use one or multiple internet gateways is it happy to
> > > propagate DNS through it, (without individually configuring nodes)
> but
> > > not if we set up our own DNS server? Also, presumably this is what
> > > happens if we use a captive-portal/access management tools?
> > >
> > >
> > >
> > > Kind Regards,
> > >
> > > Josh Harle
> > > BSc (Hons) BA BFA PhD
> > > ____________________
> > > http://joshharle.com
> > > http://tacticalspace.org <http://tacticalspace.org/>
> > > ph: +61 (0)491 155 985 <tel:%2B61%20%280%29491%20155%20985>
> > >
> > > On 24 March 2015 at 02:15, Josh King <jking at opentechinstitute.org
> <mailto:jking at opentechinstitute.org>
> > > <mailto:jking at opentechinstitute.org
> > <mailto:jking at opentechinstitute.org>>> wrote:
> > >
> > > Hey Josh,
> > >
> > > Funny you should ask, we just published documentation covering
> > this use
> > > case!
> > >
> > >
> >
> https://commotionwireless.net/docs/guides-howtos/local-applications/hostnames.html
> > >
> > > Option #2 is what you want. It's not as thoroughly tested as
> > we'd like,
> > > so we'd appreciate your feedback (or any issues filed against
> > > https://github.com/opentechinstitute/commotion-docs, the repo
> > for the
> > > website). The upshot is that you have to point the nodes to
> > use that as
> > > their DNS server rather than whatever their upstream DNS is.
> > >
> > > That said, I'm not certain why it would be dropping the
> > gateway; that
> > > could be a number of issues that we could delve into which are
> > separate
> > > from the DNS question.
> > >
> > > The round-robin bit isn't much trickier. In the section of the
> doc
> > > entitled "Changing DNS server information on each node," you
> > can add
> > > multiple "list 'dns' '<ip address>'" lines, one for each
> > server you've
> > > set up. The node should just rotate through all available DNS
> > servers
> > > one at a time. There are some options to tweak its behavior as
> > well, in
> > > case it doesn't query them as expected.
> > >
> > > I hope this is helpful!
> > >
> > > On 03/23/2015 01:16 PM, Josh Harle wrote:
> > > > Hi All,
> > > >
> > > > I have another question, which I'm sure people can give me
> > insight on.
> > > >
> > > > In my mesh network, plugging into a router works fine, and
> > we get the
> > > > internet.
> > > >
> > > > I'd like to use an Raspberry Pi running dnsmasq to resolve
> > all DNS
> > > > queries to itself, and serve up some content. Just like a
> > captive
> > > > portal really, but with the mesh in between.
> > > >
> > > > When I first connect it, the mesh node connected to it picks
> > it up
> > > as a
> > > > gateway. The DNS isn't being served through it though, and
> > I can only
> > > > connect to it via its IP address. After a while the node no
> > longer
> > > > shows itself as connected to a gateway.
> > > >
> > > > What's the difference between it and a normal gateway? What
> > do I have
> > > > to do to get DNS served up through it across the network?
> > > >
> > > > For bonus points, how much trouble would it be to put more
> than
> > > one RPi
> > > > into the network at different points to spread the load and
> > reduce
> > > > latency across a geographically spread network?
> > > >
> > > > Thanks for being awesome, in advance!
> > > >
> > > >
> > > >
> > > > Kind Regards,
> > > >
> > > > Josh Harle
> > > > BSc (Hons) BA BFA PhD
> > > > ____________________
> > > > http://joshharle.com
> > > > http://tacticalspace.org <http://tacticalspace.org/>
> > > > ph: +61 (0)491 155 985 <tel:%2B61%20%280%29491%20155%20985>
> > <tel:%2B61%20%280%29491%20155%20985>
> > > >
> > > >
> > > > _______________________________________________
> > > > Commotion-discuss mailing list
> > > > Commotion-discuss at lists.chambana.net
> > <mailto:Commotion-discuss at lists.chambana.net>
> > > <mailto:Commotion-discuss at lists.chambana.net
> > <mailto:Commotion-discuss at lists.chambana.net>>
> > > >
> https://lists.chambana.net/mailman/listinfo/commotion-discuss
> > > >
> > >
> > > --
> > > Josh King
> > > Lead Technologist
> > > The Open Technology Institute
> > > http://opentechinstitute.org
> > > PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE
> 4999
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Commotion-discuss mailing list
> > > Commotion-discuss at lists.chambana.net
> > <mailto:Commotion-discuss at lists.chambana.net>
> > > https://lists.chambana.net/mailman/listinfo/commotion-discuss
> > >
> >
> > --
> > Josh King
> > Lead Technologist
> > The Open Technology Institute
> > http://opentechinstitute.org
> > PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999
> >
> >
> >
> >
> > _______________________________________________
> > Commotion-discuss mailing list
> > Commotion-discuss at lists.chambana.net
> > https://lists.chambana.net/mailman/listinfo/commotion-discuss
> >
>
> --
> Josh King
> Lead Technologist
> The Open Technology Institute
> http://opentechinstitute.org
> PGP Fingerprint: 8269 ED6F EA3B 7D78 F074 1E99 2FDA 4DA1 69AE 4999
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-discuss/attachments/20150330/bef2010d/attachment-0001.html>
More information about the Commotion-discuss
mailing list