[freifunk-public] erledigt: update lässt Knoten im Hopglass "verschwinden" - jemand ne Idee warum?
Fam. Fontaine
fontaines at gmx.de
Fr Dez 31 14:49:21 CET 2021
Hallo Ralf,
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.
Hier der output, zunächst der Versuch per scp (erfolglos):
root at ffsaar-Papierstbchen-Perl:~# cat /tmp/sysinfo/model
TP-Link TL-WR940N v6
root at ffsaar-Papierstbchen-Perl:~# exit
Connection to 2a03:2260:3009:2200:b2be:76ff:fe80:8358 closed.
SFmba:~ fontaines$ scp
Downloads/gluon-ffsaar-1.11.0-tp-link-tl-wr940n-v6.bin
root at ffsaar-Papierstbchen-Perl:/bin/
gluon-ffsaar-1.11.0-tp-link-tl-wr940n-v6.bin 95% 3664KB 334.1KB/s
00:00 ETAscp: /bin//gluon-ffsaar-1.11.0-tp-link-tl-wr940n-v6.bin: No
space left on device
gluon-ffsaar-1.11.0-tp-link-tl-wr940n-v6.bin 100% 3840KB 332.6KB/s 00:11
SFmba:~ fontaines$
dann auf der Kiste selber (erfolgreich):
root at ffsaar-Papierstbchen-Perl:~# autoupdater -f
Retrieving manifest from
http://mgmt.saar.freifunk.net/firmware/stable/sysupgrade/stable.manifest ...
No new firmware available.
root at ffsaar-Papierstbchen-Perl:~# autoupdater -f --force-version
Retrieving manifest from
http://mgmt.saar.freifunk.net/firmware/stable/sysupgrade/stable.manifest ...
Stopping cron...
Stopping urngd...
Stopping micrond...
Stopping sysntpd...
Stopping gluon-radvd...
Stopping uhttpd...
Stopping sse-multiplexd...
Stopping gluon-respondd...
vm.drop_caches = 3
Downloading image: 3328 / 3328 KiB
'radio0' is disabled
Stopping network...
'radio0' is disabled
Damit ist das Thema für mich erstmal erledigt, es sei denn, Du vermutest
auf backend-Seite auch noch was?
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