Some random thoughts...
The cable purpose autodetection could work in two very different ways:
1) Like the lime-hwd-openwrt-wan package, that creates a configuration section.
https://github.com/libremesh/lime-packages/tree/master/packages/lime-hwd-openwrt-wan
And this section contains an option for disabling the auto-configuration "autogenerated false". In this case, the cable purpose autodetection would run only when lime-config is executed. So the workflow would be: connect everything you want to connect, launch lime-config, reboot the router. If the physical connections change, lime-config should be run again, manually.
2) the cable purpose autodetection could run constantly looking for any change in real time and applying changes in the configuration accordingly. This would be more similar to babeld-auto-gw-mode.
https://github.com/libremesh/lime-packages/tree/master/packages/babeld-auto-gw-mode
But also in this case, a way for disabling the autodetection should be provided.
@people: Which of these 2 ways we want to pursue? Is there any other better way?
Ciao!
Ilario
On May 27, 2024 10:49:47 AM GMT+02:00, Ilario via LibreMesh <libremesh@???> wrote:
>Welcome Nemael!!
>Another link that I was about to forget:
>http://libremesh.org/docs/en_quick_starting_guide.html
>
>Regarding the project:
>I would ask the communities to describe which scenarios they think are more useful to automatically identify.
>
>Here goes my personal opinion (a person not active in any community! So I have not much experience of what is actually useful):
>
> - Connected to the internet
>
>I think that people use the WAN port for that, so this detection should happen only on the WAN port (that gets detected by lime-hwd-openwrt-wan (a package inside the lime-packages repository https://github.com/libremesh/lime-packages ) and configured by the proto wan which is inside lime-system). Or, if this is the only use of the WAN port, the autodetection can also be spared.
>
> - Connected to a dummy wifi device for a point-to-point link
>
>This refers to the situation where a router with the original firmware is employed for wifi links, connected by cable to a router running LibreMesh that manages the routing, right?
>@communities, do you do this?
>I remember that years ago this was common in Ninux with the name of "routing a terra" and in Guifinet with the name of "nodi híbrido". In LibreMesh there is an old package for manually configuring such things: lime-hwd-ground-routing
>but it is possible that it does not support routers supported by the DSA kernel driver for the switch... Possible, but I did not try. Actually I cannot recall anyone mentioning this feature since years.
>If it is very uncommon, I think we don't need to autodetect this.
>In case we want the autodetection, we have to decide whether to search for such scenario on LAN or on WAN ports.
>
> - Connected to another router of the same mesh network to expand coverage
>
>Yess, this I think is useful. We needed it when setting up the network for BattleMesh v15 where we set up a few routers over a large space, mostly for giving connectivity to indoor areas, and we connected some of these routers by long ethernet cables connected to the LAN ports. The full story is here:
>https://github.com/libremesh/network-profiles/blob/master/calafou/README.md
>and the mention to the manual configuration of the port is here:
>https://github.com/libremesh/network-profiles/blob/master/calafou/README.md#lime-community-configuration-3
>as you can see, we configured some ports for being "mesh only", so to be out of the br-lan bridge.
>This has been documented here:
>https://github.com/libremesh/lime-packages/pull/1085
>In theory, Batman-adv detects loops and there should be no problem. Yet, there is a creepy warning message in the logs when you connect two LibreMesh routers by cable.
>We did not disable the routing on the other ports, as we did not consider it to be a problem...
>
>Some ugly ugly thing that could happen (if I understood correctly) if a router with manual config removing Batman from br-lan connected to another with default config would be this one:
>https://github.com/libremesh/lime-packages/issues/1032
>I suppose it could happen if the autoconfig thing happened on a router but not yet on the other connected one.
>@pony, is this correct?
>Some old but maybe relevant discussions are here:
>https://github.com/libremesh/lime-packages/issues/56
>and here:
>https://github.com/libremesh/lime-packages/pull/726
>
>
>
>Then I would say that another common situation to detect is:
> - A cabled client is connected (e.g. a normal PC is connected via cable, or a switch is connected allowing the cabled connection to various laptops or other devices). This would happen always on the LAN ports.
>
>
>
>Another situation that some people use, no idea how common it is:
> - WAN-WAN cabled connection between two LibreMesh routers
>
>This is described here:
>https://github.com/libremesh/lime-packages/issues/976
>
>@nicopace could you describe the usecase?
>I think that people started using this but developers did not design this feature on purpose... Or at least the developers never disclosed this publicly.
>Anyway, the question is how to connect two different clouds (routers with different access point ESSID name, which, with the default configuration, receive a different VLAN for batman-adv: https://github.com/libremesh/lime-packages/blob/e22991716fb68bd7d20c643f0a562b821ed1f618/packages/lime-docs/files/www/docs/lime-example.txt#L40 ) via cable.
>
>Sorry for the bombardment of links, reading all of this would already be a GSoC by its own XD
>
>Ciao!
>Ilario
>
>
>On May 26, 2024 1:26:52 AM GMT+02:00, Mael Panouillot via LibreMesh <libremesh@???> wrote:
>>Thank you Ilario for the detailed references guide!
>>
>>Hello everybody, I'm Nemael, I've been a Software Developer for a few years. I have a Bachelor's Degree in Computer Science from the ULB, and I am currently living in Canada, in Toronto.
>>
>>As Ilario said, for this year's Google Summer of Code I'll be working on the router's Cable Purpose Auto-Detection system, the point of the project is to allow a router to notice in what kind of device and network configuration an ethernet port's plugged in, and configure it accordingly. The three main situations I'll look at are when an ethernet port is:
>>
>> - Connected to the internet
>>
>> - Connected to a dummy wifi device for a point-to-point link
>>
>> - Connected to another router of the same mesh network to expand coverage
>>
>>As of now, a router cannot notice by itself that an ethernet port is in either of these situations, and an expert must intervene on the router itself to implement special configurations. The goal is to allow the router to notice these situations at runtime, and run special configuration setups.
>>
>>Gio, Ilario mentioned that you would have more details on this project, I would love to speak with you directly. If you have time for that, I'm available on Matrix, or this e-mail :)
>>
>>So yeah, I'm happy to meet you all on this mailing list, and looking forward to speaking with you and working with the LibreMesh software!
>>
>>-Nemael
>>
>>On 24/05/2024 20:24, Ilario wrote:
>>> Dear all,
>>> This year we got 2 (!!!) projects funded for Google Summer of Code (GSoC)!
>>> You can see the full list of projects accepted for Freifunk organization (Freifunk allows us to participate with them) here:
>>>
>>> https://summerofcode.withgoogle.com/programs/2024/organizations/freifunk
>>>
>>> The official coding period starts on the 27th of May.
>>>
>>> I will list here the students and the mentors, but please introduce yourselves!
>>> The "students" are:
>>>
>>> Henrique for creating a Pirania release compatible with the next LibreMesh release (Pirania is a special kind of captive portal, Hiure can you add details on this project?).
>>>
>>> Nemael for implementing a detection mechanism for the configuration of ethernet ports: the router should realize that an ethernet port has been plugged to some other kind of device, and configure the ethernet port accordingly (Gio can you add details on this project?).
>>>
>>> The official mentors are:
>>> Hiure, Bruno, and myself.
>>> BUT we really need the help of the community in order to do a decent mentoring work.
>>>
>>> I start shooting some random info, please people add stuff.
>>>
>>> First thing I would suggest, is to fork the lime-packages repository to your git account (Github if you use it, or anything else), specifically I would suggest working on top of the 2024.1 branch, which is the one for the next release (and has been tested at least by Pony and Hiure).
>>>
>>> Then I would recommend the "students" to start playing with this pull request, which is from a past GSoC:
>>>
>>> https://github.com/libremesh/lime-packages/pull/938
>>>
>>> here you can find instructions about how to run LibreMesh in a virtualized environment.
>>> As you can see, the pull request has not been merged yet, as there are some unresolved comments. Feel free to contribute your patches there, if you like.
>>>
>>> Then I would suggest compiling the 2024.1-rc1 release candidate code in two (theee?) ways:
>>>
>>> with the ImageBuilder (with or without Docker, up to you) following these instructions:
>>>
>>> https://github.com/libremesh/lime-packages/blob/master/README.md#using-the-imagebuilder-1
>>>
>>> and with the BuildRoot following these instructions adapting them for OpenWrt 23.05.3 and LibreMesh 2024.1-rc1 tag or 2024.1 branch:
>>>
>>> http://libremesh.org/development.html#compiling_libremesh_from_source_code
>>>
>>> The firmware images that you create these ways, you can run also in the virtual environment as described in the pull request above. Especially the BuildRoot allows you to compile your code and try it. But you can also edit the code on a running router (most of LibreMesh packages are written in interpreted languages, like Lua or Bash, so you can simply SSH into the router and modify the files. If you mess up too much, the reset button can reset all the changes taking the router back to the code present in the flashed firmware image), try both ways :)
>>>
>>> At some point, you will surely need two-three physical routers.
>>> I am not updated on which are currently the affordable and supported ones.
>>> Anyone, suggestions?
>>> Also, you can ask in the GSoC Freifunk chat for students...
>>> Some models, mostly old, are mentioned here:
>>>
>>> http://libremesh.org/docs/hardware/
>>>
>>> If you go for the Xiaomi Mi router 4a Gigabit Edition, beware that the latest ones are shipped with a firmware that cannot be replaced.
>>> If I remember correctly, Cudy WR1300 was a good option but 5GHz radio had some problems with OpenWrt 23, not sure.
>>> Make sure to check the report from Pony, where there is also a list of routers:
>>>
>>> https://lists.autistici.org/message/20240224.195742.4837407c.en.html
>>>
>>> I would dare to say that we should work on DSA-supported routers. DSA is a "recent" thing for managing the hardware switch inside the routers, it is a kernel thing that replaces swconfig that was made by OpenWrt people, from what I understood. You can see if your router is using DSA running this command:
>>>
>>> https://github.com/libremesh/lime-packages/blob/cc6af1119bd72d9eea91845046d5aafc1d6b716d/packages/lime-system/files/usr/lib/lua/lime/utils.lua#L598
>>>
>>> In order to know that before buying the router, you can check if the target (the classification that OpenWrt does of rouers according to their CPU, please correct me if something is wrong) is mentiones as ported to DSA in the release notes of OpenWrt 21, 22 or 23:
>>>
>>> https://openwrt.org/releases/21.02/notes-21.02.0#initial_dsa_support
>>>
>>> https://openwrt.org/releases/22.03/notes-22.03.0#more_targets_converted_to_dsa
>>>
>>> https://openwrt.org/releases/23.05/notes-23.05.0#highlights_of_device_support
>>>
>>> BUT, plenty of communities still use ath9k routers (target ath79) that have not yet been supported by DSA in OpenWrt... So maybe we could also try to support those...?
>>>
>>> Ciao!
>>> Ilario
>>--
>>LibreMesh mailing list
>>LibreMesh@???
>>https://www.autistici.org/mailman/listinfo/libremesh
