Re: [lime] GSoC - Cable purpose autodetection

Delete this message

Reply to this message
Author: pony
Date:  
To: LibreMesh.org project mailing list
New-Topics: [lime] Some testing [was: GSoC - Cable purpose autodetection]
Subject: Re: [lime] GSoC - Cable purpose autodetection
Hi Maël, hi all,

On Monday, 24 June 2024 07:22:54 CEST Mael Panouillot via LibreMesh wrote:
>      -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?

>

What I was trying to say is that this is already implemented: https://github.com/libremesh/lime-packages/blob/4bdd010ef8d7182467bb86035e83f922b70d83d5/packages/lime-proto-batadv/files/usr/lib/lua/lime/proto/batadv.lua#L86-L96
@Ilario, did you mean these error messages, or are there others?
The mac address is only changed on the vlan sub-interface where batman-adv is running on. Afaik, nothing needs to be reconfigured.

>      -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?

>

ff02::1 is the 'all nodes' mulicast group, which I think means 'everyone with ipv6'. For example, someones PC may respond to this address, which I would consider a false positive, since we are looking for LibreMesh nodes.

>      -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)

>

All ports in the "ports"-array that have a "device"-key are CPU-ports. The board.json file is generated using target specific files in /etc/boards.d. For example, for tplink,archer-c7-v2, in /etc/board.d/02_network, we find

    ucidef_add_switch "switch0" \
        "0@eth1" "2:lan" "3:lan" "4:lan" "5:lan" "6@eth0" "1:wan"
    ;;


CPU-ports are distiguished by using '@'. We find ucidef_add_switch in /lib/functions/uci-defaults.sh: https://github.com/openwrt/openwrt/blob/d51421333661b84b2670fabd19744388edcd8d42/package/base-files/files/lib/functions/uci-defaults.sh#L244-L292 . It adds "device" key only for CPU-ports. Which conveniently tells us which linux netdev the port is connected with.

>          -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?

>

Yes, in this case, they both use the same CPU-port. On first boot, OpenWrt generates switch_vlan sections in /etc/config/network from information in /etc/board.json. As far as I remember, one switch_vlan is created from each entry in "roles" and the vlan number is counted from 1 upwards. So "role":"lan" will get vlan 1 and "role":"wan" vlan 2. In /etc/config/network, using eth0.x in "list ports" in a bridge device section or in "option device" in interface sections implicitly creates a vlan sub-interace on eth0 with vlan x.

> 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!
>

You are weclome!

Liebst Pony