Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Notes taken during BattleMesh v15 #1059

Open
ilario opened this issue Oct 11, 2023 · 0 comments
Open

Notes taken during BattleMesh v15 #1059

ilario opened this issue Oct 11, 2023 · 0 comments

Comments

@ilario
Copy link
Member

ilario commented Oct 11, 2023

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 FS#3441 - Menuconfig misbehaviour: wpad-mesh-wolfssl disappears depending on wpad-basic state openwrt/openwrt#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 Include auto-defer mechanism in deferable-reboot #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
country is for the accesspoint itself. country_ie is the bits in the WiFi beacons

links 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 libremesh/network-profiles@26b79ec

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'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant