[freifunk-public] update lässt Knoten im Hopglass "verschwinden" - jemand ne Idee warum?
Mia
mia at voxelcat.jp
Fr Dez 31 00:43:48 CET 2021
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