freifunk-gluon / community-packages Goto Github PK

This was first encountered during a sysupgrade, but it seems that this problem even exists outside of a sysupgrade on some routers.

We should investigate if these errors are harmful and fix them if possible

Thu Dec  7 20:26:00 2023 user.notice ffac-ssid-changer: could not set to online state: did neither find SSID 'freifunk.net/test freifunk.net/test' nor 'offline.freifunk.net/test..fe01'. Please reboot
Thu Dec  7 20:26:00 2023 daemon.err micrond[3815]: ffac-ssid-changer: could not set to online state: did neither find SSID 'freifunk.net/test
Thu Dec  7 20:26:00 2023 daemon.err micrond[3815]: freifunk.net/test' nor 'offline.freifunk.net/test..fe01'. Please reboot
Thu Dec  7 20:26:00 2023 user.notice ffac-ssid-changer: could not set to online state: did neither find SSID '' nor 'offline.freifunk.net/test..fe01'. Please reboot
Thu Dec  7 20:26:00 2023 daemon.err micrond[3815]: ffac-ssid-changer: could not set to online state: did neither find SSID '' nor 'offline.freifunk.net/test..fe01'. Please reboot
Thu Dec  7 20:26:00 2023 user.info upgrade: Saving config files...
Thu Dec  7 20:26:00 2023 user.info upgrade: Commencing upgrade. Closing all shell sessions.

With the update to gluon v2023.2.x (OpenWrt 23.05.x) the SSID does not change when the node is considered offline.

I've tested it with a new node with an initial configuration (sysupgrad -n …). With debug_log_enabled I could see that the node is considered offline and it even says that the SSID is changed to the configured prefix. The hostapd configuration is updated correctly (/var/run/hostapd-phy*.conf) but the SSID never changes.

I could reproduce this issue even with a vanilla OpenWrt:

• Change the SSID in /var/run/hostapd-phy*.conf
• Run killall -HUP hostapd

The SSID should change but it does not.

Any suggestions?

The current checkuplink script does currently only work if the Wireguard-Gateway has a functional A and AAAA DNS-Entry.
This should be the case in general, but is a weird limitation.

This results in the following shortcomings:

1. if the client-wan has ipv6, but the gateway has no AAAA entry, then it will break
2. if the wireguard-gateway is already given as an ipv4 address and not as a DNS entry, the nslookup fails

These two packages seem quite valuable and are used across communities.
So it makes sense to add them here.

This would also allow to decrease the list of different module sources in FFMUC, as all used packages are then available in the community-packages repository.

Packages are currently available here:
https://github.com/FreifunkHochstift/ffho-packages/tree/master/ffho-web-ap-timer
https://github.com/FreifunkHochstift/ffho-packages/tree/master/ffho-ap-timer

We could adapt the global gluon Contribution Guideline and add some stuff, for example:

• At the moment, the intention of a package can only be guessed by reading the description in the Makefile or if not given only guess by name and reading the code.
  We should add a central place in te Contribution guideline where to put a thorough description.

client0   ESSID: "offline_Tata-Mesh-Garten"
          Access Point: 02:2F:CC:29:5A:08
          Mode: Master  Channel: 116 (5.580 GHz)  HT Mode: HT20
          Center Channel 1: 116 2: unknown
          Tx-Power: 26 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -105 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: 168C:003C 0000:0000 [Qualcomm Atheros QCA9880]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

client1   ESSID: "test.nordwest.freifunk.net"
          Access Point: 02:2F:CC:29:5A:0C
          Mode: Master  Channel: 6 (2.437 GHz)  HT Mode: HT20
          Center Channel 1: 6 2: unknown
          Tx-Power: 20 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -95 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros QCA9560]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

mesh1     ESSID: "t-ffnw-mesh_02:00:0a:12:e0:00"
          Access Point: 02:2F:CC:29:5A:0D
          Mode: Mesh Point  Channel: 6 (2.437 GHz)  HT Mode: HT20
          Center Channel 1: 6 2: unknown
          Tx-Power: 20 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -95 dBm
          Bit Rate: unknown
          Encryption: none
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros QCA9560]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

owe0      ESSID: "owe.test.nordwest.freifunk.net"
          Access Point: 02:2F:CC:29:5A:0A
          Mode: Master  Channel: 116 (5.580 GHz)  HT Mode: HT20
          Center Channel 1: 116 2: unknown
          Tx-Power: 26 dBm  Link Quality: 50/70
          Signal: -60 dBm  Noise: -105 dBm
          Bit Rate: 104.0 MBit/s
          Encryption: WPA3 OWE (CCMP)
          Type: nl80211  HW Mode(s): 802.11ac/n
          Hardware: 168C:003C 0000:0000 [Qualcomm Atheros QCA9880]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy0

owe1      ESSID: "owe.test.nordwest.freifunk.net"
          Access Point: 02:2F:CC:29:5A:0E
          Mode: Master  Channel: 6 (2.437 GHz)  HT Mode: HT20
          Center Channel 1: 6 2: unknown
          Tx-Power: 20 dBm  Link Quality: unknown/70
          Signal: unknown  Noise: -95 dBm
          Bit Rate: unknown
          Encryption: WPA3 OWE (CCMP)
          Type: nl80211  HW Mode(s): 802.11b/g/n
          Hardware: embedded [Qualcomm Atheros QCA9560]
          TX power offset: none
          Frequency offset: none
          Supports VAPs: yes  PHY name: phy1

for debug reason I replace the log function with an echo within the sh script

root@Tata-Mesh-Garten:~# /lib/gluon/ssid-changer/ssid-changer.sh
node is considered offline
SSID offline_Tata-Mesh-Garten is correct, nothing to do

EDIT: I found one issue in line 165 should be:
CURRENT_SSID_OWE="$(grep "^ssid=$ONLINE_SSID_OWE" "$HOSTAPD" | cut -d"=" -f2)

All in all it is a very bad pice of software. It is badly structures, no function use, alot of copy pase code (that I asume weher the issue I found come from). Btw. this change fix the issue of renaming owe but the SSID settings are not appling.

It would be very good to have an Offline-SSID-Changer package available here.
It should work with BATMAN_IV, BATMAN_V and babel

existing repos from single communities are:

• https://github.com/freifunk-kiel/gluon-ssid-notifier/
• #9 (mesh protocol agnostic)
• https://github.com/eulenfunk/packages/tree/v2020.1.x/gluon-ssid-changer
• https://github.com/ffac/gluon-ssid-changer/
• https://github.com/Freifunk-Nord/gluon-ssid-changer
• https://gitlab.freifunk-stuttgart.de/firmware/gluon-ssid-changer
• https://github.com/tecff/gluon-packages/tree/main/tecff-ssid-changer (supports has_default_gw and owe)

A try to put something like this upstream failed, so I think it would be best to have this package here.

Recently gluon got a mesh-agnostic way to receive the online state and neighbours:

• freifunk-gluon/gluon#2228

So it would be cool to have a package which relies on this functionality.

error in logread no hostapd-phy*, exiting with error code 2
https://github.com/freifunk-gluon/community-packages/blob/master/ffac-ssid-changer/shsrc/ssid-changer.sh#L13

The files in /var/run on the Ubiquiti UniFi 6 LR are called
hostapd-wl0.conf
hostapd-wl1.conf
now.

Let's see how upstream (Gluon) handles this change (phy's don't have to be called phy anymore) and then adapt the change to this package :)
freifunk-gluon/gluon#3020

@maurerle can you help specifying the license for the package?

I have a ZTE MF281 with LTE.

If the connection is very busy, checkuplink often incorrectly recognizes the tunnel as dead and reconnects.

If the connection is heavily utilized, the latency of the client connections increases significantly.
Measured client ping RTT values through the tunnel of 800-1500ms on average, peak values up to 5000ms and occasional packet loss.
(LTE ping RTT from gluon without tunnel increases to approx. 350ms; no packetloss, stagnates there stably)
Checkuplink often incorrectly recognizes the tunnel as dead and reconnects. (Tunnel is not dead, just high latency!)

My Idea:

Increase the timeouts. (helps, but not enough)
+
Repeat the tests. If 3/3 fail --> dead.

(+ some high.latency.mode option for enable/disable the extended tests)

Code might look like this.
I'm testing this at the moment, looks promising.

retry_wget() {
    local url="$1"
    local max_attempts=3
    local attempt=1
    local delay=1
    local ret=0

    while [ $attempt -le $max_attempts ];
    do
        wget "$url" --timeout=10 -O/dev/null -q && return 0 || ret=$?
        logger -p warn -t checkuplink "wget attempt $attempt failed with code $ret, retrying in $delay seconds..."
        sleep $delay
        attempt=$((attempt + 1))
        delay=$((delay * 2))
    done

    return $ret
}

retry_batctl_ping() {
    local gwmac="$1"
    local max_attempts=3
    local attempt=1
    local delay=1

    while [ $attempt -le $max_attempts ];
    do
        if batctl ping -c 7 -t 10 -i 1 "$gwmac" > /dev/null 2>&1; then
            return 0
        fi
        logger -p warn -t checkuplink "batctl ping attempt $attempt failed, retrying in $delay seconds..."
        sleep $delay
        attempt=$((attempt + 1))
        delay=$((delay * 2))
    done

    return 1
}

is_connected() {
        if retry_wget "http://[$(wg|grep fe80|awk '{split($3,A,"/")};{print A[1]}')%$MESH_VPN_IFACE]/";
        then
                GWMAC=$(batctl gwl|awk '/[*]/{print $2}')
                if retry_batctl_ping "$GWMAC";
                then
                        return 0
                fi
        fi
        return 1
}

The mesh wan detection in gluon is dated and should be updated so that this package works again.

https://github.com/ffac/community-packages/blob/ed68c7060e6122537038ece7de920d199aeed9b0/ffda-usb-wan-hotplug/files/etc/hotplug.d/usb/10-usb-wan-hotplug#L5

network.mesh_wan.disabled is not correct anymore, we should look at
gluon.iface_wan.role instead?

If mesh-wan is enabled, this would blast mesh packages to the tethered device - but I don't think this would affect carrier usage?
So I am not sure why this was needed in the first place @blocktrron ?

Hello,
as we discussed at the Gluon RC3 meetup, we from Freifunk München would like to make our backend compatible with the current Gluon integration of the wireguard protocol. It was mentioned in the HedgeDoc that @lemoer could help us with this and we would greatly appreciate it. It would be great if we could discuss the migration process and next steps in our Mattermost chat (https://chat.ffmuc.net).

Thank you very much for your great work!

Many communities have the demand to switch the autoupdater-branch from one thing to another at a given firmware state:

• https://github.com/eulenfunk/packages/tree/v2020.1.x/eulenfunk-migrate-updatebranch
• https://github.com/freifunkMUC/gluon-packages/tree/main/ffmuc-autoupdater-next2stable
• https://github.com/freifunkMUC/gluon-packages/tree/main/ffmuc-autoupgrade-experimental2testing
• https://github.com/freifunkh/ffh-packages/tree/master/ffh-autoupdater-to-stable
• https://github.com/tecff/gluon-packages/tree/main/tecff-autoupdater-to-stable

Those solutions are always a single-use development.
I think it would be very good to have a package which allows having a list of pairs from which branch to which a change should happen, configurable through the site.conf.
If any community already has something like this, it would be cool to share it - otherwise I don't think it will be hard to implement from the given examples too.

Currently, having only the wan_radio enabled on a nodes phy does trigger:
logger -s -t "ffac-ssid-changer" -p 5 "could not set to online state: did neither find SSID '$ONLINE_SSID' nor '$OFFLINE_SSID'. Please reboot"

This is the case if grep "^ssid=" /var/run/hostapd-phy0.conf | cut -d"=" -f2 shows only the wan_radio configured through gluon-web-private-wifi

I think this case should therefore be ignored (as log_debug).