[freifunk-public] erledigt: update lässt Knoten im Hopglass "verschwinden" - jemand ne Idee warum?
Ralf Jung
post at ralfj.de
Fr Dez 31 15:14:40 CET 2021
Hallo,
> mir ist eingefallen, dass bei den 940ern ab und an das update schief
> geht. Also dachte ich: stoß es nochmal an.
> Was soll ich sagen: Der Knoten wird wieder angezeigt, die Statusseite
> funktioniert wieder einwandfrei.
Prima. :D
> Damit ist das Thema für mich erstmal erledigt, es sei denn, Du vermutest
> auf backend-Seite auch noch was?
Ich vermute es gibt auf gluon-Seite noch bugs, aber viel tun kann ich da nicht...
einen Guten Rutsch allerseits!
Ralf
>
> Grüße
> Sebastian
>
>
> Am 31.12.21 um 12:13 schrieb Fam. Fontaine:
>> 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