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

Ralf Jung post at ralfj.de
Fr Dez 31 11:20:20 CET 2021


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