Here the report:)
Wednesday the 5th of June 2024 at 13:00 UTC (15:00 CEST, 10:00 ART)
People
Bruno, Cri, Henrique, Hiure, Ilario, Nemael, Gio, Batata
Topics
GSoC New Pirania release
GSoC Cable purpose autodetection
Reports from BattleMesh
Reports from BattleMesh
Gio: I presented the peering between AP and AP, to replace ieee802.11s
mesh and adhoc, as the driver support for these is getting worse.
There are other stuff named mesh, but they are not useful.
I am modifying the AP driver as little as possible, I am just modifying
hostapd to recognize other APs like if they were clients/stations, so
that the driver can be used as it is already working for AP-sta connections.
Working for merging it in LibreMesh, but there are issues with netifd in
OpenWrt.
Gio: I am working also with LibreRouter2 prototype. Still not ready.
Hiure: first time at the battlemesh. Resort environment, expensive,
organization made some mistakes/misunderstandings, not easy to
participate from the global south. 2 hours per day in a bus for going
and coming back from the venue.
Gio: not much hacking with hardware, few routers, no physical space for
sitting and working with routers. There was the OpenWrt One router.
Venue suited for presentations.
GSoC Cable purpose autodetection
Hiure: some discussion at the BattleMesh. Discussion with Gio and Javier.
-> Use shared-state packages to discover what kind of clients is behind
the cable.
Gio: Shared-states is more about sharing discoverability info with other
notes
Also, we could expand the functions of DHCP client from OpenWrt
(command: dhcpcd -T eth0) so that it shows the info of the received IP
offer but does not apply it.
This can be used for getting info on what is connected to the ethernet port.
This feature is very likely not present in OpenWrt.
Example output:
dhcpcd-10.0.6 starting
DUID 00:01:00:01:2c:84:82:4c:9c:.....:0d:00:2f:ad
flw0: IAID f4:32:75:0d
flw0: soliciting an IPv6 router
flw0: soliciting a DHCP lease
flw0: offered 172.20.10.6 from 172.20.10.1 RE11693i-server-name
interface=flw0
pid=21082
protocol=dhcp
reason=TEST
ifcarrier=up
ifflags=69699
ifmetric=3003
ifmtu=1350
ifssid='RE11693i server name'
ifwireless=1
new_broadcast_address=172.20.10.15
new_dhcp_lease_time=85536
new_dhcp_message_type=2
new_dhcp_server_identifier=172.20.10.1
new_domain_name_servers=172.20.10.1
new_ip_address=172.20.10.6
new_network_number=172.20.10.0
new_routers=172.20.10.1
new_server_name=RE11693i-server-name
new_subnet_cidr=28
new_subnet_mask=255.255.255.240
dhcpcd exited
Another test: check if via that port other peers can be reached. This
can also be done via shared-state, to see if shared-state can find some
other devices on the other side (and these devices are going to be
LibreMesh devices, very likely).
Ilario: Run detection at runtime or only when the user runs a config?
During the meeting on the 1st of June we decided it was easier to have
the auto-config happening when the user wants it, and what Gio is
proposing sounds like something running contantly.
Gio: Yes, the idea is to have it done at runtime. This way we can also
inform user the user about what changed on their netwwork. The main way
to warn the user would be to send a notification through the lime app
Javier: We can use the trigger that we already have that checks for
interfaces going up and down.There are also some other events that have
triggers that might be useful.
Ilario: I think that if it runs in runtime, the features should be very
limited and we should be sure that they are safe. We need to write a
short short list of situtions that we want to detect and why. Otherwise,
the network changing in runtime could cause bugs that would be hard to
track.
Gio: the detection sould suggest the users that some broken router has
been connected to the network, without configuring it. Via a
notification in the lime-app.
Ilario: there could be a useful use for this autodetection which is
discerning between cable-connected client or client-connected LibreMesh
router. The system could configure the port for avoiding Batman-adv loops.
Gio: shared-state has a reference state, so lime-app can show what
changed and show a notification saying it is broken now. The goal is to
make troubleshooting easier for the user. The configuration of
batman-adv vs client connected to ethernet is useful but could be
suggested to the user from the lime-app, not necessarily applied
automatically. Troubleshooting is very important, and this could help.
Ilario: Should there be some modules that the user activates to receive
these notifications and features?
Gio: Every bit of this thing should be a module, that can be enabled and
disabled.
Ilario: Notifications should also be possible to be disabled from the
lime-app directly.
Ilario: Should Nemael develope shared-states module?
Gio: It depends, some things are useful in shared-states, but dhcpcp -T
is independant to shared-state, it is a modification to udhcpcd. Better
to stat with one module , dhscp configuration start, and implement one
feature using that.
GSoC New Pirania release
Hiure: Pirania config file contains which interface Pirania will
monitor, so it is normal that it does not check the APname interface,
but only the AP one. But it can be configured.
Moving to nftables.
Henrique: Ilario mentioned possible changes due to swconfig -> DSA
configuration of switches. I could try to install nftables on OpenWrt 19
to migrate features in place.
Gio: better to work on the latest OpenWrt code.
Pirania should not be affected by DSA.
Hiure: ipset?
Gio: ipset should be migrated also to nftables.
Hiure: ebtables?
Gio: Pirania should not touch ebtables. Anyway also ebtables can be
migrated to nftables, but check if that ebtables line makes sense first.
Henrique:
https://wiki.nftables.org/wiki-nftables/index.php/Nftables_families
should I flash a router with a LibreMesh branch and work on the router
directly?
Gio: I would work with the development version of LibreMesh and OpenWrt
Javier: you can work with qemu first, and then move to real hardware, if
this is easier for you.
There are some scripts and pending fixes in the documentation:
https://github.com/libremesh/lime-packages/pull/1065
Next meeting
24th of June, same time same Jitsi server (if it works)
