Hi!
Just wanting to share some new stuff we have been using in wlan
slovenija network.
So for managing our servers, we started using Salt and Docker. You can
find our Salt configurations here:
https://github.com/wlanslovenija/servers-salt-stateshttps://github.com/tozd/salt
We are putting all stuff into Docker images. Like nodewatcher, routing, etc.
https://github.com/wlanslovenija/docker-router-olsrd
And interesting thing we started doing is putting OpenWrt firmware
generators for each platform into its own Docker image:
https://github.com/wlanslovenija/firmware-core
In this way it is easy to share already compiled firmware generators.
People do not have to compile them themselves. You can then simply SSH
into it and compile images for that platform. (We use nodewatcher to
connect to them and compile based on the set of packages our users want
and with configuration baked in into the image itself.)
For gateways and VPN servers, we are simply using (or planing to use)
OpenWrt images generated by nodewatcher. :-) For x86 platform and it
works. In this way it is easy to reuse the existing stack. The servers
above are mostly for website, nodewatcher itself, etc.
We have also quite few OpenWrt packages:
https://github.com/wlanslovenija/firmware-packages-opkg
So for OpenWrt we are trying to put everything into packages. For
servers into Docker images.
For configuring the network stack for Docker we are using:
https://github.com/wlanslovenija/netcfg
Some random apps we created:
https://github.com/wlanslovenija/wireless-infohttps://github.com/wlanslovenija/netmeasured
I am sharing all this stuff so that others see if there is anything
interesting so that we do not duplicate too much things. Or that we
might use the same patterns/tools to be easier to reuse. Like Salt,
Docker. The most interesting for me is that if we would agree upon a
simple format for generator images, it would be a great way to share
firmware builders one can simply plug into their own systems. We all use
OpenWrt based stuff, this is then just to make module around it so that
I can ship to somebody a firmware they are not used to, but they can
still generate it with tools they are used to.
Mitar
--
http://mitar.tnode.com/https://twitter.com/mitar_m
Hey would someone approve this? I can reset the mesh-dev lists password if
no one has it around.
Thanks!
---------- Forwarded message ----------
From: <mesh-dev-owner(a)lists.sudoroom.org>
Date: Sat, Feb 21, 2015 at 4:21 AM
Subject: mesh-dev post from jernej(a)kos.mx requires approval
To: mesh-dev-owner(a)lists.sudoroom.org
As list administrator, your authorization is requested for the
following mailing list posting:
List: mesh-dev(a)lists.sudoroom.org
From: jernej(a)kos.mx
Subject: Re: [mesh-dev] Web admin of roof to roof nodes [another ramble]
Reason: Post by non-member to a members-only list
At your convenience, visit:
https://lists.sudoroom.org/admindb/mesh-dev
to approve or deny the request.
---------- Forwarded message ----------
From: Jernej Kos <jernej(a)kos.mx>
To: Mitar <mitar(a)tnode.com>, Marc Juul <juul(a)labitat.dk>,
mesh-dev(a)lists.sudoroom.org
Cc:
Date: Sat, 21 Feb 2015 13:21:05 +0100
Subject: Re: [mesh-dev] Web admin of roof to roof nodes [another ramble]
Hello!
On 21. 02. 2015 09:36, Mitar wrote:
> the most reliably in that way. I do not know details, though, what all
> issues we had that we had to move to this setup. CCing Kostko who might
> be able to provide more information here.
Indeed, this was a problem with olsrd implementation of OLSR which used
neighbour IPs as part of link identification and we had some strange
routing issues because of using same IPs on multiple interfaces.
We now use one IP for each interface which participates in routing and
we use the first such IP as the Router ID.
Note that babel uses IPv6 link-local addresses for neighbours, so it
uses different IPs anyway and this will probably not be such a problem
in this case. But I would still refrain from using the same IP on
multiple interfaces.
Jernej
---------- Forwarded message ----------
From: mesh-dev-request(a)lists.sudoroom.org
To:
Cc:
Date: Sat, 21 Feb 2015 04:21:20 -0800
Subject: confirm 4bacb63cb6f3b747fd43348ca7faa4410c84a424
If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message. Do this if the message is
spam. If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list. The Approved: header can also appear in the first line
of the body of the reply.
We haven't talked about what to do for web admin of the roof to roof nodes.
The roof to roof 5 ghz nodes should probably just have babel on both wifi
and ethernet interface and the same IP assigned to both interfaces. That's
basically it for now right?
I believe we've been thinking that anywhere that has a roof to roof node,
and isn't just a relay point, must also have a 2.4 ghz node with the normal
sudowrt firmware and that the rooftop 5 ghz node plugs into the 2.4 ghz
node via ethernet.
In the longer run we should figure out how to tell a 2.4 ghz node that it
"owns" one or more 5 ghz rooftop nodes, and query those nodes for
connectivity information (link status, signal strength, packet loss, link
latency) such that it can be reported to the node owner via the 2.4 ghz
node web admin interface.
If we put a web admin interface on the 5 ghz rooftop nodes at all, then I
imagine that it would be very singular in purpose: It would show a
live-updating feed of only other 5 ghz peoplesopen.net-node2node nodes +
their signal strength and let the user select which node to connect to (of
course using self-signed SSL and a node-unique password).
We want to make it easy for people to deploy a 5 ghz node, so accessing
this web interface during node install should be as easy as possible.
If we're really clever, we could make a tiny fake dhcp server for these
nodes that sends out periodic DHCPDISCOVER packets and listens for ANY
other DHCP server traffic on the ethernet interface. If it sees traffic
from another DHCP server, then it does nothing until the physical ethernet
connection has been severed and reconnected. If it sees a DHCPDISCOVER and
no response, then on the e.g. third DHCPDISCOVER it gives the client a
lease. This can always be a lease for the same IP, since its only purpose
is to give a single lease to a laptop that's been hooked directly into the
node. The dnsmasq running on the node will resolve e.g. node.sudomesh.org
to the node's IP, such that accessing this "node install helper" web app
will be as easy as plugging a laptop into the node and opening
node.sudomesh.org in a browser.
Planning for potentially doing this means only this: We give each 5 ghz
roof to roof node two IP addresses instead of one (which reminds me that I
need to add some stuff to meshnode-database to make it possible for
makenode to request single/multiple IPs instead of complete subnets).
btw I think we should consider not using my.node and similar domains since
chrome and safari don't understand those domains unless prefaced with
http(s):// (though safari at least understands .local).
It could just be pplsopen.net (and peoplesopen.net and all the other
domains), but maybe we can buy something short using one of those
newfangled top-level domains? We should own the domain so we don't block
someone elses domain from resolving.
--
marc/juul
# IPv4
We have two ways of proceeding here. We could assign a single unique IPv4
address to each node and use NAT to make the connected clients share this
IP, or we could assign a unique IPv4 subnet to each node.
I think we should go with a unique subnet. The main reason we should avoid
NAT is that NAT would make it impossible for us to implement any form of
layer 3 roaming in the future (which we currently have not even really
discussed, but it would be pretty great if it could be made to work).
I suggest we use the 100.64.0.0/10 subnet (reserved for ISP-level NAT) and
assign each node a /26 subnet. I pushed some small changes to makenode and
meshnode-database last night to make this possible.
The reason for a /26 subnet is two-fold:
* It presents a hard limit of 61 clients associated with an access point at
any given time, which is probably a good thing (this does not prevent us
from assigning larger subnets to some nodes if it becomes a problem).
* It allows us to deploy more than 60,000 nodes without the complications
to our firewall/routing rules of having multiple separate IPv4 subnets in
use.
Finally, while it's somewhat easier for humans to deal with /24 subnets, it
really isn't that bad to deal with /26 subnets. E.g: for the four /26
subnets in 10.0.0.0/24:
* Network addresses: 10.0.0.0, 10.0.0.64, 10.0.0.128, 10.0.0.192
* Gateway addresses: 10.0.0.1, 10.0.0.65, 10.0.0.129, 10.0.0.193
* Broadcast addresses: 10.0.0.63, 10.0.0.127, 10.0.0.191, 10.0.0.255
See? They're all friendly familiar numbers off by one.
# IPv6
For IPv4 we cannot hope to get an Internet routable subnet large enough for
the mesh, but for IPv6 we should be able to get ARIN to assign us a /32. We
should think of internet-routable IPv6 addresses as the way we will
interconnect with other community networks, and in general we should
severely frown upon inter/intra-mesh IPv4 traffic (perhaps going so far as
not reflecting mDNS/DNS-SD for A records). We should begin working on the
ARIN application.
Once we get the /32 from ARIN, we will need to assign each node a /64 (IPv6
seriously frowns upon subnets smaller than /64 since it breaks many IPv6
features). Unfortunately the assignment of subnets to nodes cannot be done
in some simple automated/decentralized manner, so we'll likely have to use
makenode + the meshnode-database for these assignments as well. I can see
you're disappointed, but you're still comforted by the fact that at least
the clients connected to nodes can self-assign IP addresses within the /64,
so we don't have to worry about that. Well I don't feel good about telling
you this, but most operating systems unfortunately use the EUI-64
MAC-address-based method of self-assigning IP addresses, which would mean
that every client of the mesh is trackable to their physical MAC address,
and thus their device, as they move about the mesh. This is even worse than
the situation with batman-adv, since the incriminating IPv6 source
addresses will happily leave the mesh and traverse the greater internet.
Now you might think "but isn't there an alternate self-assignment paradigm
that uses randomized addresses". Yes. Yes there is, but unfortunately the
stubborn assholes at IETF decided to shoot down proposals to deprecate this
insane IP-assignment system:
https://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses…
and even more stubborn people in charge of OS X, Linux, Android, etc. have
in their infinite wisdom decided to stick to the standard and keep the
MAC-based assignment the default. This of course means that most users have
never bothered to deviate from this setting. In this theatre of insanity,
the only operating systems which decided to switch the default to
randomized addresses is Windows Vista and newer!!!
So... I believe we must use DHCPv6 in order to protect users from their
owen devices.
However, since it's likely to take some time for us to get the IPv6 /32, I
don't think we can avoid using something else in the mean-time, so we could
save time in the short term by just letting all of the nodes and clients
self-assign in the same /64 and throw caution to the wind (for testing
purposes).
I have begun writing an IPv6 version of the subnet calculation library we
use in makenode, such that we can use if for IPv6 subnet assignment in the
near future:
https://github.com/sudomesh/subnet
It is close to complete.
# Roaming
Based on this thread where Mitar is talking to Juliusz:
http://lists.alioth.debian.org/pipermail/babel-users/2012-April/000953.html
It sounds like it would be doable to implement layer 3 roaming using babel
route redistribution. I'm not suggesting we do this now, but it'd be
interesting to work on this later.
--
marc/juul
Hi guys,
Freifunk and Ninux are applying for the GSoC 2015.
You might want to propose projects ideas if you feel like it.
Freifunk ideas page: http://wiki.freifunk.net/Ideas
Ninux ideas page: http://wiki.ninux.org/GSoCIdeas2015
Hopefully I'll see youagain in October2015! :-)
Federico
Hey just checking in to see what time folks are thinking about being at the
omni to do some node mounting. I'm maybe hoping to be elsewhere between
~3:30-4:30, but otherwise I'm fairly free.
Also - I'm not really sure how long this will take. I can do a bunch of the
flashing and configuring, but it seems like a good deal of the work would
be placement and mounting.
What are other people thinking?
