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?
Hey folks,
We were talking a while ago about having some sort of development tracker
so that we could better organize the tasks we wanted to accomplish. I was
interested in fulcrum, so I went ahead and deployed an instance of it:
http://sudomeshtrax.herokuapp.com/
I'm not sure that it's exactly what we need, but I'm currently using it to
keep track of a few things. Also - it seems to have a couple weird display
bugs, so we can try to tackle them if they end up being an issue.
It should be open to registration, although I'd ask that you actually be
working on peoplesopen.net development if you're using it.
I'm still personally a fan of trac, but I think its a much larger project
to take on than I'm interested in at the moment (especially upkeep, but we
can see).
Thanks!
Max
