Hi all!
Here are my thoughts about cable purpose auto-detection. I start with opinions on point 0:
Re: ii) meshing ethernet port inside bridge
Does putting ethernet interfaces used for meshing into the br-lan bridge really cause problems? It did not cause any problems when I tested the release canditate. Batadv has a neat feature called bridge-loop-avoidance (BLA) that should prevent any loops. There used to be error messages like "br-lan: received packet on bat0 with own address as source address" caused by this feature, but these are prevented now by changing the mac address of the interfaces batadv is configured on (hardifs). For DSA enabled devices, putting ethernet ports together in a bridge is really configuring the internal switch to forward packets between them. In cases where more than two devices are connected by cable, this will give a performance boost, since frames in transit do not have to go through the CPU. Babeld and batman will then see all routers that are reachable through a cable-only-path as direct neighbors. If bridge loops are really a concern here, maybe it would be an option to put ethernet mesh interfaces into a separate bridge?
For swconfig devices, if we want both user access and meshing over ethernet, and don't want those ethernet ports to be bridged together, a new switch_vlan would need to be created to seperate access ports and mesh ports.
Re: iv) cut broadcast between clouds
For dsa enabled devices this can easily done by removing protocol lan and protocol batadv from the port that is connected to other cloud. For swconfig devices, a new switch_vlan would need to be created.
Some thoughts to and more ideas for point 1:
Re: a) neighbor detection
Re: a2) Using ping6:
`ping ff02::1%interface` could give false positives. Also ff02::2 could give false positives, since everything that considers itself a router would respond to it. Maybe LibreMesh could use it's own ipv6 multicast address, like ff12::bee, and use that to discover other LibreMesh nodes?
a4.1) Swconfig devices:
Maybe we could use the output of `swconfig dev switch0 get arl_table`? This prints a list of mac addresses and which ports they are connected to. One could compare them against the link local addresses from ping6 responses. I think there are switches which do not support getting the arp table, but most switches do.
a4.2) Another idea: Use an asymmetric vlan mapping that allows to send frames through a specific port. I imagine something like this:
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '1 2 3 0t'
config switch_vlan
option device 'switch0'
option vlan '11'
option ports '1 0t'
config switch_vlan
option device 'switch0'
option vlan '12'
option ports '2 0t'
config switch_vlan
option device 'switch0'
option vlan '13'
option ports '3 0t'
config switch_port
option device 'switch0'
option port '1'
option pvid '1'
config switch_port
option device 'switch0'
option port '2'
option pvid '1'
config switch_port
option device 'switch0'
option port '3'
option pvid '1'
Then send ping through port x like so:
ping ff12::bee%eth0.1x
But the replies will come from eth0.1. That could be a problem. I'm also not sure if such a configuration works on all switches.
Re: b3) Modify OpenWrt DHCP-client:
uhdpcd does not need to be modified. It can already do this:
udhcpc -n -q -f -s /bin/true -t 1 -i lan3
This will succeed when there is a dhcp-server running behind lan3. See also:
https://udhcp.busybox.net/README.udhcpc
Re: c) Detect whether neighboring LibreMesh router is in the same or another cloud:
Maybe yet another ipv6 multicast address could be used for this? One that is unique to each mesh cloud?
By the way, /etc/board.json contains very useful information about switch ports, including which ones are CPU ports (somtimes there is more than one), whether it is labeled "wan" or "lan" on the outside and which number it is labeled with (not always). This should be all the information needed for creating switch_vlans. I attached some board.json files as examples.
Liebst
Pony
