[freifunk-public] update lässt Knoten im Hopglass "verschwinden" - jemand ne Idee warum?

Fam. Fontaine fontaines at gmx.de
Fr Dez 31 12:13:35 CET 2021 

Nachtrag:

Das im Ticket geschilderte Problem mit den neighbors kann ich bestätigen.

root at ffsaar-Papierstbchen-Perl:~# gluon-neighbour-info -d ::1 -p 1001 -t
60 -r nodeinfo
root at ffsaar-Papierstbchen-Perl:~# echo $?
1

Es gibt dort keine Nachbarn, allderings kommt der Befehl auf einem
funktionierenden Knoten sofort mit output zurück.
Im Papierstübchen läuft er in den timeout.

Es wird ja nicht am Umlaut "ü" liegen?
root at ffsaar-Papierstbchen-Perl:~# cat /etc/config/system

config system
     option ttylogin '0'
     option log_size '64'
     option urandom_seed '0'
     option timezone 'CET-1CEST,M3.5.0,M10.5.0/3'
     option pretty_hostname 'ffsaar-Papierstübchen-Perl'
     option hostname 'ffsaar-Papierstbchen-Perl'



Am 31.12.21 um 12:01 schrieb Fam. Fontaine:
> Hallo Ralf,
>
> Das Verhalten der hopglas Anzeige beim Reit-und-Fahr-Verein (RuFV) war
> ähnlich, wie wenn ich einen Filter auf die Version gesetzt hätte. Dann
> wäre es klar, dass sie beim update "verschwinden". Nur hatte ich den
> nicht gesetzt.
> Nach einer Weile (ca. 30 Minuten) waren plötzlich wieder alle sichtbar
> und ich habe mit dem update weitergemacht.
> Dabei ist mir aufgefallen, dass alle Settings bleiben, bis auf die
> Kanal Einstellungen. Im 2,4Ghz Band werden die auf "1" zurückgesetzt.
> Aber das war bei den letzten Updates auch schon so, meine ich.
>
>
> Der Knoten, der gar nicht auf der Karte auftaucht ist jedenfalls auch
> über seine Statusseite nicht erreichbar.
> Mia hat den Fehler aus dem html-Code dieser Seite:
>
> http://[2a03:2260:3009:2200:b2be:76ff:fe80:8358]/cgi-bin/status
>
> <!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
>     <head>
>         <meta charset="utf-8" />
>         <meta name="viewport" content="width=device-width,
> user-scalable=no" />
>
>         <title><!DOCTYPE html>
> <html xmlns="http://www.w3.org/1999/xhtml" lang="" xml:lang="">
>     <head>
>         <meta charset="utf-8" />
>         <meta name="viewport" content="width=device-width,
> user-scalable=no" />
>
>         <title>Fehler</title>
>
>         <link rel="stylesheet" href="/static/status-page.css"
> type="text/css" />
>     </head>
>     <body>
>         <header>
>             <h1>Fehler</h1>
>         </header>
>         <div class="container">
>             <div class="frame">
>                 <h2 name="content">500 Interner Serverfehler</h2>
> <p>Entschuldigung, auf dem Server ist ein unerwarteter Fehler
> aufgetreten.</p>
> <pre class="error500">Failed to execute dispatcher target for entry
> '/'.
> The called action terminated with an exception:
> /usr/lib/lua/gluon/web/template.lua:43: Failed to execute template
> 'status-page'.
> A runtime error occurred: [string
> "/lib/gluon/status-page/view/status-page.htm..."]:90: attempt
> to index global 'nodeinfo' (a nil value)</pre>
>
>             </div>
>         </div>
>     </body>
> </html>
>
>
> Einloggen kann ich mich per ssh aber, und im log finde ich nichts zu
> "respondd"
> SFmba:~ fontaines$ ssh -l root 2a03:2260:3009:2200:b2be:76ff:fe80:8358
>
>
> BusyBox v1.30.1 () built-in shell (ash)
>
>   _____  _____
> _/ ____\/ ____\___________  _____ _______
> \   __\\   __\/  ___/\__  \ \__  \\_  ___\
>  |  |   |  |  \___ \  / __ \_/ __ \|  |
>  |__|   |__| /_____/ (_____/(_____//__|
>  -----------------------------------------------------
>  OpenWrt 19.07-SNAPSHOT, r11354+25-ffd4452f8b
>  gluon-ffsaar 1.11.0 / gluon v2021.1.1
>  -----------------------------------------------------
>  Gluon commandline administration reference:
>  https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration
>  -----------------------------------------------------
> root at ffsaar-Papierstbchen-Perl:~# logread |grep respondd
> root at ffsaar-Papierstbchen-Perl:~#
>
> Auch wenn ich dann den Fehler der Website provoziere und die letzten
> lograd-Zeilen schaue, dann sehe ich da nichts ungewöhnliches:
>
> root at ffsaar-Papierstbchen-Perl:~# logread |tail -10
> Fri Dec 31 11:46:35 2021 authpriv.info dropbear[19443]: Child
> connection from 2003:da:72c:6900:d4fb:16f6:7e11:decb:44870
> Fri Dec 31 11:46:37 2021 authpriv.notice dropbear[19443]: Pubkey auth
> succeeded for 'root' with key sha1!!
> 23:60:c0:6c:f0:a9:0f:06:4a:f8:55:3c:5c:52:ad:b5:27:d0:b5:f5 from
> 2003:da:72c:6900:d4fb:16f6:7e11:decb:44870
> Fri Dec 31 11:46:37 2021 authpriv.info dropbear[19443]: Exit (root):
> Disconnect received
> Fri Dec 31 11:48:00 2021 cron.info crond[969]: USER root pid 19535 cmd
> /bin/awake-test.sh >/dev/null 2>&1
> Fri Dec 31 11:52:05 2021 authpriv.info dropbear[19759]: Child
> connection from 2a03:2260:3009:2200:f42e:478a:fc14:5bbf:55448
> Fri Dec 31 11:52:06 2021 authpriv.notice dropbear[19759]: Pubkey auth
> succeeded for 'root' with key sha1!!
> f8:20:63:48:f1:04:40:f5:5e:9f:32:2e:33:a5:d2:4d:12:16:14:3b from
> 2a03:2260:3009:2200:f42e:478a:fc14:5bbf:55448
> Fri Dec 31 11:53:35 2021 authpriv.info dropbear[19835]: Child
> connection from 2003:da:72c:6900:d4fb:16f6:7e11:decb:45310
> Fri Dec 31 11:53:37 2021 authpriv.notice dropbear[19835]: Pubkey auth
> succeeded for 'root' with key sha1!!
> 23:60:c0:6c:f0:a9:0f:06:4a:f8:55:3c:5c:52:ad:b5:27:d0:b5:f5 from
> 2003:da:72c:6900:d4fb:16f6:7e11:decb:45310
> Fri Dec 31 11:53:37 2021 authpriv.info dropbear[19835]: Exit (root):
> Disconnect received
> Fri Dec 31 11:54:00 2021 cron.info crond[969]: USER root pid 19886 cmd
> /bin/awake-test.sh >/dev/null 2>&1
> root at ffsaar-Papierstbchen-Perl:~#
>
> Grüße
> Sebastian
>
>
> Am 31.12.21 um 11:20 schrieb Ralf Jung:
>> Hallo allerseits,
>>
>> Im gluon-bugtracker habe ich dieses Problem gefunden:
>> https://github.com/freifunk-gluon/gluon/issues/2256
>> Das scheint mit einem Crash im respondd zusammenzuhängen (das passt
>> zu dem was Mia schreibt):
>> https://github.com/freifunk-gluon/gluon/issues/2260
>> Siehst du im log irgendwas von respondd crashes? (Mia, wo sieht man
>> diese Crashes? Stehen die im "logread"?)
>> Angeblich wurden die allerdings gefixed in gluon 2021.1.1.
>>
>> Ich kann ffsaar-RuFV-klHalle und die anderen auch wieder auf der
>> Karte sehen -- hast du irgendwas gemacht, Sebastian? Offenbar sind
>> die Knoten in dem Mesh vor 20min alle neu gestartet.
>>
>> Viele Grüße,
>> Ralf
>>
>> On 31.12.21 00:43, Mia via freifunk-public wrote:
>>> Hallo,
>>>
>>> wenn man per HTTP auf die Status-Seite zugreifen will, kommt folgendes:
>>>
>>>  > Failed to execute dispatcher target for entry '/'.
>>>  > The called action terminated with an exception:
>>>  > /usr/lib/lua/gluon/web/template.lua:43: Failed to execute template
>>>  > 'status-page'.
>>>  > A runtime error occurred: [string "/lib/gluon/status-page/view
>>>  > /status-page.htm..."]:90: attempt to index global
>>>  > 'nodeinfo' (a nil value)
>>>
>>> Das gleiche Problem hatte ich beim Upgrade vom raspberry pi3 auf die
>>> neuste Firmware, da stürzt nämlich gluon-respondd ständig ab.
>>> Ich hatte das allerdings nicht weiter beachtet, weil der RPi3 nicht
>>> offiziell von Gluon unterstützt wird, auch wenn das nur am
>>> Wifi-Radio liegen sollte und nicht an irgendwelchen
>>> Inkompatibilitäten mit respondd.
>>> Scheinbar sind wohl auch andere Geräte davon betroffen. Ohne
>>> respondd landen die Nodes auch nicht im hopglass.
>>> Eine Lösung habe ich dafür nicht, da müsste man wohl respondd debuggen.
>>>
>>>
>>> Schöne Grüße,
>>>
>>> Mia
>>>
>>>
>>> On 30/12/2021 22:27, Fam. Fontaine via freifunk-public wrote:
>>>> Hi Ralf,
>>>>
>>>> habe gerade manuell ein update von folgenden Knoten gemacht:
>>>> ffsaar-RuFV-klHalle, ffsaar-RuFV-Einsteller1,
>>>> ffsaar-RuFV-Einsteller2, ffsaar-RuFV-Einsteller3
>>>>
>>>> alt:
>>>> OpenWrt 19.07-SNAPSHOT, r11328+12-81266d9001
>>>>   gluon-ffsaar 1.10.1 / gluon v2020.2.3
>>>>
>>>> neu:
>>>> OpenWrt 19.07-SNAPSHOT, r11354+25-ffd4452f8b
>>>>   gluon-ffsaar 1.11.0 / gluon v2021.1.1
>>>>
>>>> Im Resultat, sind sie von der Karte "verschwunden"
>>>>
>>>>
>>>> Die entsprechende Konfig ist aber unverändert, sprich, sie sind
>>>> auch per ssh erreichbar:
>>>> root at ffsaar-RuFV-klHalle:~# cat /etc/config/gluon-node-info
>>>>
>>>> config location
>>>>      option share_location '1'
>>>>      option latitude '49.530890825'
>>>>      option longitude '6.414288282'
>>>>
>>>> config owner
>>>>      option contact 'mail at sfinp.de'
>>>>
>>>> config system
>>>>
>>>> root at ffsaar-RuFV-klHalle:~#
>>>>
>>>> Versuchshalber habe ich dann noch ein update an folgendem Knoten
>>>> angestoßen:
>>>> ffsaar-RuFV-grHalle
>>>>
>>>> Und folgerichtig "verschwindet" der auch von der Karte:
>>>>
>>>>
>>>> Wie erklärt sich das denn?
>>>>
>>>> Grüße
>>>> Sebastian
>>>>
>>>> Am 30.12.21 um 21:36 schrieb Fam. Fontaine:
>>>>> Hi,
>>>>>
>>>>> habe da ein Phänomen, das ist nicht verstehe. Im besten Fall fehlt
>>>>> mir ein kleiner Hinweis.
>>>>> Ich habe hier einen Knoten, der seit über einem Jahr läuft und
>>>>> jetzt nicht mehr auf der Karte auftaucht.
>>>>> Allerdings kann ich mich per SSH verbinden und eigentlich sieht
>>>>> für mich alles gut aus.
>>>>> Er hat die jüngste Firmware, aber irgendwas stimmt trotzdem nicht,
>>>>> sonst wäre er ja im Hopglas sichtbar.
>>>>>
>>>>> Hier ein wenig output, logs, etc.
>>>>>
>>>>> SFmba:Freifunk fontaines$ ssh -l root ffsaar-Papierstbchen-Perl
>>>>>
>>>>>
>>>>> BusyBox v1.30.1 () built-in shell (ash)
>>>>>
>>>>>   _____  _____
>>>>> _/ ____\/ ____\___________  _____ _______
>>>>> \   __\\   __\/  ___/\__  \ \__  \\_  ___\
>>>>>  |  |   |  |  \___ \  / __ \_/ __ \|  |
>>>>>  |__|   |__| /_____/ (_____/(_____//__|
>>>>>  -----------------------------------------------------
>>>>>  OpenWrt 19.07-SNAPSHOT, r11354+25-ffd4452f8b
>>>>>  gluon-ffsaar 1.11.0 / gluon v2021.1.1
>>>>>  -----------------------------------------------------
>>>>>  Gluon commandline administration reference:
>>>>> https://github.com/freifunk-gluon/gluon/wiki/Commandline-administration
>>>>>
>>>>>  -----------------------------------------------------
>>>>> root at ffsaar-Papierstbchen-Perl:~# uptime
>>>>>  21:12:11 up 26 days, 11:26,  load average: 0.00, 0.00, 0.00
>>>>> root at ffsaar-Papierstbchen-Perl:~# crontab -l
>>>>> */6 * * * * /bin/awake-test.sh >/dev/null 2>&1
>>>>> root at ffsaar-Papierstbchen-Perl:~# cat /etc/config/gluon-node-info
>>>>>
>>>>> config location
>>>>>     option share_location '1'
>>>>>     option latitude '49.473453'
>>>>>     option longitude '6.386101'
>>>>>
>>>>> config owner
>>>>>     option contact 'mail at sfinp.de'
>>>>>
>>>>> config system
>>>>>
>>>>> root at ffsaar-Papierstbchen-Perl:~# uci set
>>>>> gluon-node-info. at location[0]='location
>>>>> '; uci set gluon-node-info. at location[0].share_location='1';uci set
>>>>> gluon-node-in
>>>>> fo. at location[0].latitude='49.473464603';uci set
>>>>> gluon-node-info. at location[0].lon
>>>>> gitude='6.386103630';uci commit gluon-node-info
>>>>> root at ffsaar-Papierstbchen-Perl:~#
>>>>>
>>>>> root at ffsaar-Papierstbchen-Perl:~# /bin/nodeinfo_lokal.sh
>>>>> runtime: Thu Dec 30 21:33:00 CET 2021
>>>>> ### hostname :  ffsaar-Papierstbchen-Perl
>>>>> ### IP :            inet6 addr:
>>>>> 2a03:2260:3009:2200:b2be:76ff:fe80:8358/64 Scope:Global
>>>>> default via 192.168.2.1 dev br-wan  src 192.168.2.100
>>>>> 10.24.240.0/20 dev local-node scope link  src 10.24.240.255
>>>>> 192.168.2.0/24 dev br-wan scope link  src 192.168.2.100
>>>>> ### from ssh : 2003:da:704:1a00:195a:b831:cf14:7b34 53000
>>>>> 2a03:2260:3009:2200:b2be:76ff:fe80:8358 22
>>>>> ### uptime :   21:33:00 up 18 min,  load average: 0.03, 0.08, 0.08
>>>>> ### firmware :  1.11.0
>>>>> ### hardware :  TP-Link TL-WR940N v6
>>>>> ### Radio-Networks acitve:wlan0     ESSID: unknown
>>>>>           Access Point: B0:BE:76:80:83:58
>>>>>           Mode: Client  Channel: unknown (unknown)
>>>>>           Tx-Power: 20 dBm  Link Quality: unknown/70
>>>>>           Signal: unknown  Noise: unknown
>>>>>           Bit Rate: unknown
>>>>>           Encryption: unknown
>>>>>           Type: nl80211  HW Mode(s): 802.11bgn
>>>>>           Hardware: unknown [Generic MAC80211]
>>>>>           TX power offset: unknown
>>>>>           Frequency offset: unknown
>>>>>           Supports VAPs: yes  PHY name: phy0
>>>>>
>>>>> ### connected to this node  :  0
>>>>> ### number of total clients :    75
>>>>> ### Mesh: MoL: MoW: Fastd:
>>>>> ### BatIFs:
>>>>> primary0: active
>>>>> mesh-vpn: active
>>>>> batctl gw :      client (selection class: 20)
>>>>> ### BatGateways
>>>>> [B.A.T.M.A.N. adv openwrt-2019.2-12, MainIF/MAC:
>>>>> primary0/4a:c4:ec:81:5b:e3 (bat0/b0:be:76:80:83:58 BATMAN_IV)]
>>>>>   Router            ( TQ) Next Hop          [outgoingIf] Bandwidth
>>>>>   ca:fe:ba:be:02:03 (225) ca:fe:ba:be:02:02 [  mesh-vpn]:
>>>>> 400.0/400.0 MBit
>>>>>   ca:fe:ba:be:02:01 (225) ca:fe:ba:be:02:02 [  mesh-vpn]:
>>>>> 400.0/400.0 MBit
>>>>> * ca:fe:ba:be:02:02 (255) ca:fe:ba:be:02:02 [  mesh-vpn]:
>>>>> 200.0/200.0 MBit
>>>>>   ca:fe:ba:be:02:04 (225) ca:fe:ba:be:02:02 [  mesh-vpn]:
>>>>> 1000.0/1000.0 MBit
>>>>> ### Location: Geo?:'1' lon:'6.386103630' lat:'49.473464603'
>>>>> Contact:'mail at sfinp.de'
>>>>> Mesh neighbours:
>>>>> ### WAN network status:
>>>>> {
>>>>>     "up": true,
>>>>>     "pending": false,
>>>>>     "available": true,
>>>>>     "autostart": true,
>>>>>     "dynamic": false,
>>>>>     "uptime": 1075,
>>>>>     "l3_device": "br-wan",
>>>>>     "proto": "dhcp",
>>>>>     "device": "br-wan",
>>>>>     "updated": [
>>>>>         "addresses",
>>>>>         "routes",
>>>>>         "data"
>>>>>     ],
>>>>>     "metric": 0,
>>>>>     "dns_metric": 0,
>>>>>     "delegation": true,
>>>>>     "ipv4-address": [
>>>>>         {
>>>>>             "address": "192.168.2.100",
>>>>>             "mask": 24
>>>>>         }
>>>>>     ],
>>>>>     "ipv6-address": [
>>>>>
>>>>>     ],
>>>>>     "ipv6-prefix": [
>>>>>
>>>>>     ],
>>>>>     "ipv6-prefix-assignment": [
>>>>>
>>>>>     ],
>>>>>     "route": [
>>>>>         {
>>>>>             "target": "0.0.0.0",
>>>>>             "mask": 0,
>>>>>             "nexthop": "192.168.2.1",
>>>>>             "source": "192.168.2.100/32"
>>>>>         }
>>>>>     ],
>>>>>     "dns-server": [
>>>>>
>>>>>     ],
>>>>>     "dns-search": [
>>>>>
>>>>>     ],
>>>>>     "neighbors": [
>>>>>
>>>>>     ],
>>>>>     "inactive": {
>>>>>         "ipv4-address": [
>>>>>
>>>>>         ],
>>>>>         "ipv6-address": [
>>>>>
>>>>>         ],
>>>>>         "route": [
>>>>>
>>>>>         ],
>>>>>         "dns-server": [
>>>>>             "192.168.2.1",
>>>>>             "192.168.2.1"
>>>>>         ],
>>>>>         "dns-search": [
>>>>>             "Speedport_W723_V_Typ_A_1_01_022"
>>>>>         ],
>>>>>         "neighbors": [
>>>>>
>>>>>         ]
>>>>>     },
>>>>>     "data": {
>>>>>         "leasetime": 1814400
>>>>>     }
>>>>> }
>>>>> {
>>>>>     "up": true,
>>>>>     "pending": false,
>>>>>     "available": true,
>>>>>     "autostart": true,
>>>>>     "dynamic": false,
>>>>>     "uptime": 1072,
>>>>>     "l3_device": "br-wan",
>>>>>     "proto": "dhcpv6",
>>>>>     "device": "br-wan",
>>>>>     "ip6table": 1,
>>>>>     "metric": 0,
>>>>>     "dns_metric": 0,
>>>>>     "delegation": true,
>>>>>     "ipv4-address": [
>>>>>
>>>>>     ],
>>>>>     "ipv6-address": [
>>>>>         {
>>>>>             "address": "2003:da:717:9f01:b2be:76ff:fe80:8359",
>>>>>             "mask": 64,
>>>>>             "preferred": 1770,
>>>>>             "valid": 14370
>>>>>         }
>>>>>     ],
>>>>>     "ipv6-prefix": [
>>>>>
>>>>>     ],
>>>>>     "ipv6-prefix-assignment": [
>>>>>
>>>>>     ],
>>>>>     "route": [
>>>>>         {
>>>>>             "target": "2003:da:717:9f01::",
>>>>>             "mask": 64,
>>>>>             "nexthop": "::",
>>>>>             "metric": 256,
>>>>>             "valid": 14370,
>>>>>             "source": "::/0"
>>>>>         },
>>>>>         {
>>>>>             "target": "::",
>>>>>             "mask": 0,
>>>>>             "nexthop": "fe80::1",
>>>>>             "metric": 384,
>>>>>             "valid": 150,
>>>>>             "source": "::/0"
>>>>>         }
>>>>>     ],
>>>>>     "dns-server": [
>>>>>
>>>>>     ],
>>>>>     "dns-search": [
>>>>>
>>>>>     ],
>>>>>     "neighbors": [
>>>>>
>>>>>     ],
>>>>>     "inactive": {
>>>>>         "ipv4-address": [
>>>>>
>>>>>         ],
>>>>>         "ipv6-address": [
>>>>>
>>>>>         ],
>>>>>         "route": [
>>>>>
>>>>>         ],
>>>>>         "dns-server": [
>>>>>             "fe80::1"
>>>>>         ],
>>>>>         "dns-search": [
>>>>>
>>>>>         ],
>>>>>         "neighbors": [
>>>>>
>>>>>         ]
>>>>>     },
>>>>>     "data": {
>>>>>         "passthru": "00170010fe800000000000000000000000000001"
>>>>>     }
>>>>> }
>>>>> ### WAN DNS:
>>>>> nameserver fe80::1%br-wan
>>>>> nameserver 192.168.2.1
>>>>> nameserver 192.168.2.1
>>>>> ### nslookup-test: /usr/bin/gluon-wan /usr/bin/nslookup www.heise.de
>>>>> Server:        127.0.0.1
>>>>> Address:    127.0.0.1#53
>>>>>
>>>>> Name: www.heise.de
>>>>> Address 1: 193.99.144.85
>>>>> Address 2: 2a02:2e0:3fe:1001:7777:772e:2:85
>>>>> error-code: 0
>>>>> ### ping-test: /usr/bin/gluon-wan /bin/ping -c 4 1.1.1.1
>>>>> PING 1.1.1.1 (1.1.1.1): 56 data bytes
>>>>> 64 bytes from 1.1.1.1: seq=0 ttl=55 time=31.558 ms
>>>>> 64 bytes from 1.1.1.1: seq=2 ttl=55 time=32.297 ms
>>>>> 64 bytes from 1.1.1.1: seq=3 ttl=55 time=31.796 ms
>>>>>
>>>>> --- 1.1.1.1 ping statistics ---
>>>>> 4 packets transmitted, 3 packets received, 25% packet loss
>>>>> round-trip min/avg/max = 31.558/31.883/32.297 ms
>>>>> error-code: 0
>>>>> root at ffsaar-Papierstbchen-Perl:~# reboot
>>>>> ...
>>>>> root at ffsaar-Papierstbchen-Perl:~# uptime
>>>>>  21:34:55 up 20 min,  load average: 0.10, 0.12, 0.09
>>>>> root at ffsaar-Papierstbchen-Perl:~#
>>>>>
>>>>
>>>>
>

Mehr Informationen über die Mailingliste freifunk-public