Here I copy and pasre bits from our chats, referring to various issues or desires identified during the event. Some maybe are false positives, others maybe have already been solved. We should double check them and convert the interesting ones in real tickets.
analyze the poor performances of the mesh link (maybe due to VHT80 channel width? The routers see each other at -80 dBm that is too low for this very good line of sight)
get two outdoor routers (PlasmaCloud PA1200) and flash them as the mesh link, check the speed and check if with different channels, channel width or other things it gets better
understand how BATMAN_V is getting the master interface (now it does not find it. It runs on a VLAN, but needs info from the original interface) and fix something so that it works in LibreMesh
implement Opportunistic Wireless Encryption easy setup in LibreMesh. Also, encrypt the mesh link
set up monitoring with prometheus (in case doing it with OpenWISP is too difficult)
double check the documentation from Aparcar on the usage of the ImageBuilder
update unit testing script to work with OpenWrt 22.03
understand what should we/odhcpd developers do for stopping using dnsmasq-dhcpv6 and start using odhcpd for DHCP on IPv6 as in OpenWrt. Someone (Aparcar? Marek?) said that in LibreMesh we are not using odhcpd because it cannot read the leases list from and external source (e.g. a file). Maybe Daniel Golle can implement that.
txt.file mentioned that there are two settings in OpenWrt that would be useful:
1) for telling the clients to use a specific country code (e.g. if the router country code is set to ES, also the clients should use the same)
2) for telling the clients which channels are in use in the current network (I hope it can increase the speed of the roaming switching)
I think I found the option for adding the country code in the beacons: country_ie https://openwrt.org/docs/guide-user/network/wifi/basic#common_options
Marek mentioned that using the cheap Ubiquiti PoE could be a bad idea
He says that the PlasmaCloud does not ask always for 48 V (it can, during load peaks), but it uses a standard PoE protocol for asking for a specific voltage. But the cheap PoE from Ubiquiti does not have that protocol and always provide 48 V. No idea if it is worth to replace the PoEs
found a temporary solution: disable auto-negotiation of the ethernet cable speed. The auto-negotiation was set it to 1 Gbps full duplex (that is what should work, as both devices and PoE are gigabit), but when we set it manually (disabling the auto-negotiation) to 1 Gbps full duplex it said "no-carrier". So we set it to 100 Mbps full duplex with no auto-negotiation everything works well.
ethtool -s eth1 autoneg off speed 100 duplex full
rebooting the router or restarting the /etc/init.d/network, resulted again in the 1000M ethernet speed. So the script is not working as expected. Or, is not working, as expected. Does anyone know how to debug /etc/hotplug.d scripts?
just as a dirty fix, I added the ethtool rule to /etc/rc.local, so it should be executed at boot. Hopefully not too soon
Make sure that from the "events' network" clients cannot ping/reach hosts in "classic network" except the fiber router
Coordinate with Konejo for fixing the support of lime-app for OpenWrt 22.03
understand why eth1 (wan) in PlasmaCloud PA1200 router used as gateway gets added in br-lan, and this should not happen. Checking network.lua in lime-system. If we don't have time for fixing this, hardcode a fix.
understand why static IP configuration didn't work as expected. For the gateway LibreMesh node, at some point the dhcp client was not getting anything, so we tried with a static IP but did not do anything. What we added to /etc/config/lime-node is:
config net usingLANasWAN
option linux_name 'eth1'
list protocols 'wan'
list protocols 'static'
option static_ipv4 '172.31.17.254/24'
option static_gateway_ipv4 '172.31.17.1'
During Wireless BattleMesh v15 in Calafou, we had intense testing of LibreMesh compiled on top of OpenWrt 22.03. Details on the network and setup here: https://github.com/libremesh/network-profiles/tree/master/calafou
Here I copy and pasre bits from our chats, referring to various issues or desires identified during the event. Some maybe are false positives, others maybe have already been solved. We should double check them and convert the interesting ones in real tickets.
test OpenWISP with LibreMesh (install both OpenWISP packages https://github.com/openwisp/openwrt-openwisp-monitoring/tree/0.1.0#install-pre-compiled-packages and https://openwisp.io/docs/user/configure-device.html#install-openwisp-config , figure out how to set up an OpenWISP server and set it up, maybe virtualized with Docker Compose)
analyze the poor performances of the mesh link (maybe due to VHT80 channel width? The routers see each other at -80 dBm that is too low for this very good line of sight)
get two outdoor routers (PlasmaCloud PA1200) and flash them as the mesh link, check the speed and check if with different channels, channel width or other things it gets better
understand how BATMAN_V is getting the master interface (now it does not find it. It runs on a VLAN, but needs info from the original interface) and fix something so that it works in LibreMesh
implement Opportunistic Wireless Encryption easy setup in LibreMesh. Also, encrypt the mesh link
fix the super annoying Makefile of hostapd (wpad-*) in OpenWrt (see https://github.com/openwrt/openwrt/issues/8312 )
set up monitoring with prometheus (in case doing it with OpenWISP is too difficult)
double check the documentation from Aparcar on the usage of the ImageBuilder
update unit testing script to work with OpenWrt 22.03
understand what should we/odhcpd developers do for stopping using dnsmasq-dhcpv6 and start using odhcpd for DHCP on IPv6 as in OpenWrt. Someone (Aparcar? Marek?) said that in LibreMesh we are not using odhcpd because it cannot read the leases list from and external source (e.g. a file). Maybe Daniel Golle can implement that.
reboot the router once every week only if the internet connectivity is not present https://github.com/libremesh/lime-packages/issues/1023
txt.file mentioned that there are two settings in OpenWrt that would be useful: 1) for telling the clients to use a specific country code (e.g. if the router country code is set to ES, also the clients should use the same) 2) for telling the clients which channels are in use in the current network (I hope it can increase the speed of the roaming switching) I think I found the option for adding the country code in the beacons: country_ie https://openwrt.org/docs/guide-user/network/wifi/basic#common_options
otherwise "hostapd_options" + https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
countryis for the accesspoint itself.country_ieis the bits in the WiFi beaconslinks with debugging info: dmesg: http://sprunge.us/qCQt8c logread: http://sprunge.us/nSVzzn lime-report: http://sprunge.us/SjXOCg
Marek mentioned that using the cheap Ubiquiti PoE could be a bad idea He says that the PlasmaCloud does not ask always for 48 V (it can, during load peaks), but it uses a standard PoE protocol for asking for a specific voltage. But the cheap PoE from Ubiquiti does not have that protocol and always provide 48 V. No idea if it is worth to replace the PoEs
found a temporary solution: disable auto-negotiation of the ethernet cable speed. The auto-negotiation was set it to 1 Gbps full duplex (that is what should work, as both devices and PoE are gigabit), but when we set it manually (disabling the auto-negotiation) to 1 Gbps full duplex it said "no-carrier". So we set it to 100 Mbps full duplex with no auto-negotiation everything works well. ethtool -s eth1 autoneg off speed 100 duplex full
as a tentative for having a stable "do not use gigabit on ethernet cable towards the fiber router" setting, I added this to the LibreMesh gateway node and in its network-profile https://github.com/libremesh/network-profiles/commit/26b79ec119c35c317bd572d62118fb7e89841a32
rebooting the router or restarting the /etc/init.d/network, resulted again in the 1000M ethernet speed. So the script is not working as expected. Or, is not working, as expected. Does anyone know how to debug /etc/hotplug.d scripts?
just as a dirty fix, I added the ethtool rule to /etc/rc.local, so it should be executed at boot. Hopefully not too soon
Make sure that from the "events' network" clients cannot ping/reach hosts in "classic network" except the fiber router
Coordinate with Konejo for fixing the support of lime-app for OpenWrt 22.03
understand why eth1 (wan) in PlasmaCloud PA1200 router used as gateway gets added in br-lan, and this should not happen. Checking network.lua in lime-system. If we don't have time for fixing this, hardcode a fix.
understand why static IP configuration didn't work as expected. For the gateway LibreMesh node, at some point the dhcp client was not getting anything, so we tried with a static IP but did not do anything. What we added to /etc/config/lime-node is:
config net usingLANasWAN option linux_name 'eth1'
list protocols 'wan' list protocols 'static' option static_ipv4 '172.31.17.254/24' option static_gateway_ipv4 '172.31.17.1'