Thank you Ilario, Pony and Gio for your detailed explanations.
The lime-hwd-ground-routing is a great example of how an autodetecting
package would work, and the explanation surrounding it helped me
understand what such a package would look like. At first, making the
modules to be explicitly activated in /etc/config/lime would be very
clear. (If there is enough different configurations to be detected, it
might warrant a new setting/page in the lime-app, showing a list of all
the auto-detected configurations, that you could each tick on or off?)
Regarding your response, Pony,
-For point 'ii)', you're talking about changing the MAC Address of
the device batman is running on, right? In that case, wouldn't that
break many other router features (maybe babeld's, I'm still in the
process of learning how it works). And if we change that MAC Address,
would there be a lot of different software to reconfigure for the
routing to deliver packages to the correct endpoints?
-For point 'a2)', you mention that "ping ff02::1%interface could
give false positives. I can see how ff02::2 can give false positive, but
could you give an example of a situation where ff02::1%interface could
give a false positive?
-In the board.json file,
-How do you identify which one is a CPU port? Is it the
"system" field? (I don't see an explicit CPU label in the files)
-Some routers have interfaces setup as "lan:eth0.1,
wan:eth0.2". What do those eth0.x mean? Are WAN and LAN both under the
same interface 'eth0', but routed differently once inside the interface?
Thank you again so so much for the super detailed information, it has
given me a lot of food for thought, and the different point of views
from Gio and Pony allows me to understand better how the different
software fit together!
-Maël Panouillot
On 21/06/2024 11:37, pony via LibreMesh wrote:
> 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
>
>
