I am not normally on this list, but for some reason a search turned it
up this morning.
I run a babel-based mesh network down in los gatos and perhaps I have
an insight or two to help.
0) Bridging over wifi sucks, particularly when mdns or other multicast
traffic is present. It takes very little multicast to mess up your
whole day
1) Distributing ipv4 addresses and prefixes is a pita. The new hnetd
protocol intends to try and make that more automagic, but it has a
desire to be god-like over everything and every daemon. Still, more
eyeballs on it and perhaps it could be made to work.
See: http://www.homewrt.org/doku.php?id=overview
DNS is a pita, also. - some hope for mdns-proxy...
1.5) I used to use AHCP for interconnecting mesh nodes, which worked
quite well, particularly for ipv6. It did not distribute prefixes,
however, which led to (the thus far abortive) hnetd.
2) Babel's diversity algorithm seems to be suffering from an old
system call which only works in adhoc mode, not AP mode. It also
contains some bridge disambiguation logic (but failing to get the
channel right in that case does not help). It does sort of do the
right thing, even not getting the right info, shipping "interfereing"
around... and it looks like short work to get it to get the right
channel automatically given example code in the iw utility and olsrv2
- but I lack the time, personally, to do that right now.
Relevant thread and pointers here:
http://lists.alioth.debian.org/pipermail/babel-users/2015-June/002056.html
3) openwrt, at least, has moved away from dnsmasq being the dhcp
server in favor of their own server implementation. In neither case
does dhcp handle ptp /32s, so you need another address distribution
mechanism for this anyway.
Given the headaches in doing this automagically I lean towards static
assignment for ipv4.
4) babeld-1.6.0 had a bug in source specific routing, now fixed in
babeld-1.6.1. At the moment I am exploring various facets of that to
leverage building up the prefix distribution scheme.
--
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast
We tested the extender node / home node auto-configuration and verified
that it works for extending the open network (peoplesopen.net ssid) but not
the adhoc/mesh network. The adhoc is more difficult since adhoc networks
cannot be bridged.
Max got the extender node firmware working on a Nanobridge, work on porting
the TP-Link home-node configuration over to a WD My Node and found a couple
of nothdcp bugs.
I worked on getting the adhoc extending to work. It's not quite there yet
but it seems like a combination of relayd and igmpproxy should simulate a
bridge adequately. This adds a bit of complexity but it doesn't seem like
there's any way around it. This pseudo-bridge setup is the last crucial
part of the whole notdhcp / extender node adventure. I am hopeful that we
can finish it this Thursday. A fallback solution is to just run babeld on
the extender nodes.
--
marc/juul
Chris J worked on a circuit for the garden node that will prevent it from
booting when the voltage is below a certain minimum.
I worked on extender node hook scripts and added features to makenode and
notdhcp for the extender nodes. My laptop doesn't have 5 ghz support so I
couldn't actually connect to the extender node and test, but it really
seems like everything is getting auto-configued correctly.
I expect that we'll need to tweak the meshrouting script and babel
configuration slightly to get everything playing nicely together.
Max: It'd be great to sit down and test and tweak this some day/evening
soon?
Next steps:
* Testing and tweaking current setup
* Ensure that it's also working for nanostation, nanobridge and my net
Then we could call what we have 0,2 beta, deploy a bunch of nodes and test?
btw the TP-Link for sunday nodes have arrived. For Sunday need two things:
* Hammers
* These things:
https://encrypted-tbn3.gstatic.com/shopping?q=tbn:ANd9GcRp3RcfPtQYgNMnkCkQv…
Actually it'd be good to have some black and some white cable clips. We can
do a home depot run on Sunday if nothing else.
--
marc/juul
Hello mesh adventures!
I recently moved into a house that has multiple 100 - 125ft Redwood trees
in the back yard located in the heart of Downtown Berkeley.
I'd like to do something akin to:
https://www.youtube.com/watch?v=wutvDSTfEk4
Anyone interested in helping me get a couple nodes setup?
snakewrangler:
* Tested the sudowrt rebuild script and it seemed to work
* Sketched a design for ubus forwarder and started implementing
chris:
* Started working on voltage level cutoff circuit for the ESP8266 garden
nodes
* Probably other stuff that I was too distracted to keep up with
juul:
* Got notdhcp hook script close to final state
I ran into a few issues that need resolution:
* notdhcp needs to send the VLAN ID (small change)
* notdhcp has a gaping security hole due to lacking validation (easy to
fix though)
* It is not possible to bridge an adhoc wifi interface...
What?! No really. It's true: No bridging of adhoc on Linux. I can't help
but think that this would have become a serious problem if we were still
using batman-adv
As it is, we have the option of doing a "layer 3 bridge". But how? I've
never actually done this before. Here's what I ended up with. Haven't
tested it yet though:
# stuff in mesh_wlan routing table goes out to eth0.10
ip route add default dev eth0.10 table mesh_wlan
# stuff coming in from adhoc0 goes to the mesh_wlan routing table
ip rule add iif adhoc0 lookup mesh_wlan
# stuff in mesh_eth routing table goes out to adhoc0
ip route add default dev adhoc0 table mesh_eth
# stuff coming in from eth0.10 goes to the mesh_eth routing table
ip rule add iif eth0.10 lookup mesh_eth
eth0.10 is the ethernet VLAN that carries the adhoc/babel network
adhoc0 is the wireless adhoc network
Is this crazy? It really does need to just forward everything coming in on
one interface out another interface and vice-versa. Since we can't bridge,
and we don't really need to do this below layer 3, this was the best I
could come up with. Thoughts? Suggestions? Facepalms?
Assuming some solution for an adhoc bridging alternative works out in the
next few days I should be able to finalize this by Tuesday and switch to
working on the new web UI.
--
marc/juul
Oh look: It's another very long email from juul!
I've been working on the config for the N750 + antenna-node configuration
and here are my thoughts so far.
We should _not_ let the LAN ports be one big ethernet interface for use
both as a wired version of open0 _and_ a way to connect antenna-nodes. We
never want to bridge two interfaces with attached antenna-nodes but
treating the multiple LAN ethernet interfaces as one interface is
effectively the same as bridging.
Example scenario: You have to nanobridges on your roof linking you to two
parts of the mesh. They are both plugged into LAN ports on your N750 and
since the LAN ports are treated as one interface then the two nanobridges
are able to communicate on layer 2. The nodes at the houses to which you
are connecting with your nanobridges have the same setup. Now we
effectively have the spanning tree protocol as our mesh protocol instead of
babel.
It was Alex who pointed this out when we were talking about bridging but
for some reason I hadn't connected the dots and recognized that the same is
true when telling the built-in switch to treat the interfaces as one.
This means that each physical port on the N750 that we wish to connect to
an antenna-node must be its own interface and should have a /32 netmask.
These interfaces can still have the same node IP as open0, etc, without any
problems.
I suggest we allocate two of the four ports for this purpose until we can
make something that intelligently changes the config when an antenna-node
has been connected.
We now have two remaining LAN ports that can act as a single interface. We
could then bridge this LAN interface to open0. However, we want to avoid
channel interference when sending from/to open0 but there is no reason we
should try to avoid channel interference for traffic coming from the wired
interfaces. If we bridge them we cannot treat them differently, so we
should not bridge.
It is not clear if babel channel diversity also takes into account channel
information for manually published routes such as the open0 route we
currently publish with this rule:
redistribute if open0 metric 128
I'll have to look at the source code to check. If the functionality is not
there then it should be fairly easy to add.
Aaaanyway: Since we don't want to bridge open0 and LAN, this complicates
things because we then need two subnets per node (otherwise we have the
same /26 on both LAN and open0, which is not going to work). Less than a
/26 on either interface gets iffy, so it seems like we'll need to have two
/26 subnets per node now.
One last but important thing I realized: If the antenna-nodes have their
wifi and ethernet interfaces bridged, then we will have problems. Imagine
the following setup:
(N750 A) ------ (nanobridge A) ~~~~ (nanobridge B) ----- (N750 B)
Where "-----" means ethernet and "~~~~" means wifi.
If both nanobridge A and nanobridge B are simply bridging their ethernet
and wifi interfaces, then we have the following problems:
1. If e.g. nanobridge A sends a DHCP request, then it will be received by
both N750 A and N750 B and they will have no reliable way of know if the
request was sent by "their" nanobridge or the remote nanobridge.
2. When managing e.g. nanobridge A via the N750 A web admin interface it
will be impossible for nanobridge A to know whether it should grant admin
access to N750 A or N750 B.
I can think of only two solutions to this:
1. Pre-configure all antenna-nodes with static IPs and knowledge of which
N750 node is their parent.
2. Don't bridge the ethernet and wifi interfaces on antenna-nodes and
instead run babel on them.
I like solution 2 much better since it's easier for both us and node
operators. Not sure if we'll see a performance hit if we don't bridge. We
have a few nanobridges though so we could easily test this.
What do y'all say?
PS: Obviously babel channel diversity doesn't apply to antenna nodes since
babel sees them as ethernet interfaces but since they are mostly
directional and far away from the N750 it is fine to treat them as having
no interference, which is the default for ethernet interfaces anyway.
PPS: Did you know that the default STP delay when adding an interface to a
bridge is apparently 30 seconds? Not sure if OpenWRT has a different
default or maybe uses RSTP (rapid spanning tree protocol) to deal with
this, but if not then it is something to be aware of in order to now go
insane when troubleshooting. From:
http://www.linuxfoundation.org/collaborate/workgroups/networking/bridge#Doe…
--
marc/juul
I received this from a gluon person (anonymized until they ok sharing of
their name). Let me know if you're interested and neither your german nor
google translate is good enough and I can write up a proper translation.
---- begin forwarded message
in our gluon communities we distribute IPS via our gateways, where all
nodes connect to the gateway to get internet through an anonVPN.
But the developer of gluon is working at a new **distributed dhcp**:
Prototype: https://github.com/tcatm
thoughts:
https://gist.github.com/tcatm/2dd0e6699f2a153505d0#file-ddhcpd-md
then the nodes would give ip4 addresses to other nodes as long as none
of them hasnt any connection to any gateway. as soon as node clouds
connect they will reorder the IPS to delete doubles,...
--
marc/juul
I just realized something that might be completely obvious to everyone
else, but I hadn't thought of it before:
Context:
On the ad-hoc wireless network (the mesh) the SSID doesn't matter at all
since all nodes have the same BSSID set. I had initially turned the SSID
off, but realized that there is no simple command line tool for "please
list all nodes with this BSSID within range" which makes debugging easier.
Realization:
Since the SSID doesn't matter for ad-hoc, other than for helping us
humans know which nodes are nearby, we can use the SSID to identify not
just the node but also the radio.
Example of SSIDs from dual-band home node with two extender nodes:
[infrastructure open] peoplesopen.net
[infrastructure WPA2] my-private-network
[adhoc] ppls-n2n-node42-phy0-ch11
[adhoc] ppls-n2n-node42-phy1-ch161
[adhoc] ppls-n2n-node42-ext0-ch153
[adhoc] ppls-n2n-node42-ext1-ch6
_but_ this would fill up people's wifi network lists with basically junk
entries
I seem to remember that there is a way to get some operating systems to not
list an SSID while still broadcasting? Something about prefixing the SSID
with a special character?
What's the behavior on current-gen operating systems for adhoc? I know
Windows 8.1 doesn't show adhoc networks at all and I know android 12 (at
least cyanogenmod) does show adhoc networks. Of course all linux-based
systems show adhoc networks. Not sure about Mac OS, iOS or later/earlier
windows versions.
Sorting is usually by signal strength, so we can't even put our SSIDs at
the bottom of the list easily.
What do?
--
marc/juul
Hi Mitar (and anyone else really)
I'm trying to figure out how to disable just 802.11b but not 802.11g. I
know how to enable greenfield mode, but not how to just disable 802.11b
Also, a few other questions:
If I enable short guard interval, what will that do for 802.11g? Do you
recommend using it for the public "give wifi to the people" access points
in an urban environment where there will still be some older 802.11g
clients?
Would you enable 40 mhz mode for these public access points as well? If I
understand correctly then they will still be able to use 20 mhz for 802.11g
devices and 40 mhz for 802.11n devices. Correct?
If I have a 1x1 802.11n node, like a Bullet M2, will it actually help to
enable TX-STBC or RX-STBC1 ? My understanding is that RX-STBC1 will still
give an improvement but that TX-STBC will do nothing (or maybe even reduce
performance?) if you have only one transmit antenna. Is this correct?
I'm not sure I understand what DSSS_CCK-40 does? It enables support for
this mode, but under what circumstances will it actually be used?
--
marc/juul
