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
