[Commotion-discuss] RPi Gateway
Josh King
jking at opentechinstitute.org
Thu Mar 26 11:09:29 EDT 2015
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 --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.chambana.net/pipermail/commotion-discuss/attachments/20150326/f6ce6294/attachment.sig>
More information about the Commotion-discuss
mailing list