Moin,
auch, um mal in die Pötte zu kommen: 0.7.9~129 ist seit heute Mittag im »experimental«-Branch des Autoupdaters, bitte testet intensiv.
Bitte guckt im Kreis GT …
… und auch in der Müritz-Region …
… genauer auf Eure »experimental«-Knoten (s. o.). Plan wäre, möglichst am Wochenende die FW nach »testing« zu pushen, um nächste Woche sie »stable« nennen zu können.
MfG,
-kai
Hmm. An der Müritz scheint es Probleme zu geben, kein Autoupdate? @m.bitterlich, kannst Du mal gucken?
Habe gerade den letzten Knoten der unter meinen Fingern ist von 0.7.4~210 auf 0.7.9~129 gebracht. Die MAC auf dem WAN Interface ist gleich geblieben. (EE:09:6B:6C:62:76).
Habe leider keinen mehr den ich mit Bridge WAN auf LAN Ports konfiguriert habe, den ich Updaten könnte.
Wenn mir noch etwas auffällt melde ich mich.
root@17192-Haus-des-Gastes:~# autoupdater
wget: bad address 'firmware.ipv4.4830.org'
There seems to have gone something wrong downloading the manifest from http://firmware.ipv4.4830.org/experimental/sysupgrade
wget: bad address 'firmware.ipv6.4830.org'
There seems to have gone something wrong downloading the manifest from http://firmware.ipv6.4830.org/experimental/sysupgrade
No usable mirror found.
Auch nach diesem Update musste ich die Bridge wiederherstellen.
uci set network.wan.ifname='eth0 eth1’
uci commit network
/etc/init.d/network restart
Achso. Das Update habe ich manuell durchgeführt.
Hi,
ist etwas am Code vor dem Wechsel von RAW nach Experimental verändert worden?
Die zwei Geräte, die ich händisch mit der Experimental-Firmware versort habe, booten regelmäßig neu. Die RAW-Firmware war bisher problemlos.
http://map.4830.org/mueritz/#!v:m;n:14cc20cd4e86
http://map.4830.org/mueritz/#!v:m;n:f4f26d3fd208
Nope. Es wurden nur die Dateien von rawhide nach experimental kopiert.
Ok … da hatte ich ein ‘Eigentor’.
in /etc/crontab/root war aktiviert:
#*/6 * * * * if [ $(ifconfig | grep ^mesh0 | wc -l) -eq 0 ]; then sleep 30; if [ $(ifconfig | grep ^mesh0 | wc -l) -eq 0 ]; then reboot; fi; fi
Aber da es kein mesh0 gibt, hingen die Knoten in einer Bootschleife fest.
root@17194-Tressow-4e86:~# ifconfig (… gekürzt …)
bat0 Link encap:Ethernet HWaddr 14:CC:20:CD:4E:86
br-client Link encap:Ethernet HWaddr 14:CC:20:CD:4E:86
br-mesh_lan Link encap:Ethernet HWaddr E6:24:A9:C6:60:04
br-wan Link encap:Ethernet HWaddr 16:CD:20:CD:4E:86
client0 Link encap:Ethernet HWaddr 16:CD:20:CD:4E:86
eth0 Link encap:Ethernet HWaddr 14:CC:20:CD:4E:87
eth1 Link encap:Ethernet HWaddr 14:CC:20:CD:4E:86
ibss0 Link encap:Ethernet HWaddr E6:24:A9:C6:60:02
lo Link encap:Local Loopback
local-node Link encap:Ethernet HWaddr DE:CA:FB:AD:FF:FE
mesh-vpn Link encap:Ethernet HWaddr E6:24:A9:C6:60:07
primary0 Link encap:Ethernet HWaddr E6:24:A9:C6:60:03
Ein Knoten mit Mesh-VPN hat die gleichen Meldungen …
http://map.4830.org/mueritz/#!v:m;n:f4f26d949c9f
root@17192-Cafe-International:~# autoupdater
wget: bad address 'firmware.ipv4.4830.org'
There seems to have gone something wrong downloading the manifest from http://firmware.ipv4.4830.org/experimental/sysupgrade
wget: bad address 'firmware.ipv6.4830.org'
There seems to have gone something wrong downloading the manifest from http://firmware.ipv6.4830.org/experimental/sysupgrade
No usable mirror found.Mit den Versionen ‚0.7.9~xxx‘ sind keine Verbindungen auf der Karte und im Fußbereich der linken Seite mehr zu sehen …
Hmm. Klingt nach karputtem (v6) DNS. Habe die Announcements mal ausgemistet (2 v6-NS taten’s nimmer) und OpenDNS als Fallback eingetragen. Mal gucken, ob’s jetzt besser läuft.
Grüße aus Hamburg …
Das wird auch so bleiben, bis wer entsprechenden Code schreibt, daß das per Config-Mode konfiguriert werden kann. Netzwerk-Konfiguration wird bei jedem FW-Upgrade neu geschrieben.
Yepp, das war’s …
logread gibt noch eine Meldung:
Wed Jul 19 04:00:13 2017 user.notice root: /lib/gluon/ffgt-geolocate/senddata.sh: IPv5 not implemented.
Die Zeitserver sind auch nicht mehr erreichbar. 
Danke.
root@gw10:~# traceroute -6 -s 2001:bf7:1310:10::10 ntp.4830.org.
traceroute to ntp.4830.org. (fd42:ffee:ff12:aff::201), 30 hops max, 80 byte packets
1 0000000000000010.gut.clients.4830.org (2001:bf7:1310:10::10) 2998.992 ms !H 2998.938 ms !H 2998.896 ms !H
root@gw05:~# traceroute -6 -s 2001:bf7:170::5 ntp.4830.org.
traceroute to ntp.4830.org. (fd42:ffee:ff12:aff::201), 30 hops max, 80 byte packets
1 2003:49:a051::8888 (2003:49:a051::8888) 21.795 ms 21.786 ms 21.803 ms
2 2a03:2260::1 (2a03:2260::1) 30.150 ms !N 30.147 ms !N 30.168 ms !N
root@gw05:~# traceroute -6 -s 2001:bf7:170::5 ntp.services.ffgt.net
traceroute to ntp.services.ffgt.net (fd42:ffee:ff12:aff::201), 30 hops max, 80 byte packets
1 2003:49:a051::8888 (2003:49:a051::8888) 22.034 ms 22.041 ms 22.034 ms
2 2a03:2260::1 (2a03:2260::1) 30.459 ms !N 30.457 ms !N 30.450 ms !N
Waren für GT wie Müritz unerreichbar.
Ersteinmal gw10 und bgp-gut01 auserkoren.
root@gw05:~# traceroute -6 -s 2001:bf7:170::5 ntp.4830.org.
traceroute to ntp.4830.org. (2a06:e881:1700:1:400:c0ff:fefb:e277), 30 hops max, 80 byte packets
1 bgp-fks01.4830.org (2a06:e881:1703:0:400:5ff:fe09:43b8) 1.625 ms 1.622 ms 1.614 ms
2 bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277) 13.539 ms 13.528 ms 13.548 ms
TTL war 3600 Sekunden, binnen den nächsten Stunden sollte sich auch das lösen.
Das heißt, weder die IPv4- noch IPv6-Adresse konnten erreicht werden. DNS- oder Routing-Foo 
Routing, bzw. »moar legacy«:
root@gw05:~# traceroute -6 -s 2001:bf7:170::5 setup.ipv6.4830.org
traceroute to setup.ipv6.4830.org (2a01:198:200:b6d::2), 30 hops max, 80 byte packets
1 bgp-fks01.4830.org (2a06:e881:1703:0:400:5ff:fe09:43b8) 1.604 ms 1.583 ms 1.671 ms
2 bgp-ber01.4830.org (2a06:e881:1706:1::1) 21.027 ms 21.028 ms 21.020 ms
3 strato.a36.community-ix.de (2001:7f8:a5::6724:1) 21.071 ms 21.659 ms 21.656 ms
4 ae2.0.morla.as6724.net (2a01:238:0:30ad::2) 35.459 ms 35.464 ms 35.517 ms
5 speedpartner.dus.ecix.net (2001:7f8:8::85b1:0:1) 38.586 ms 38.601 ms 38.628 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
Alte SiXXs-Adresse Should be fixed as well/fix itself after TTL:
root@gw05:~# traceroute -6 -s 2001:bf7:170::5 setup.ipv6.4830.org
traceroute to setup.ipv6.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e216), 30 hops max, 80 byte packets
1 bgp-fks01.4830.org (2a06:e881:1703:0:400:5ff:fe09:43b8) 1.478 ms 1.460 ms 1.468 ms
2 bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277) 13.407 ms 13.405 ms 14.102 ms
3 web01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e216) 14.128 ms 14.122 ms 14.143 ms
Auch hier Danke, immerhin werden die Altlasten weniger 
Hmm. Hatte erst erwogen, es läge an höheren Anforderungen an die Verbindungsqualität (Mindestgeschwindigkeit bei Meshverbindungen), aber daran liegt’s schein’s nicht:
Warum das bei Dir leinek Link in der (gleichen) Karte gibt …
… bei mir aber doch …
… erschließt sich mir, gebe ich gerne zu, nicht
Kann das ‘stable’ noch ein wenig warten - bis Ende der Woche?
Ich muss erst mein ‘Eigentor’ mit mesh0 auf den betreffenden Knoten deaktivieren. Das war damals eine Möglichkeit, instabile 841er zu reaktivieren …
Ja, ich brauche eh’ einen neuen Build, denn für den Netgear WNDR3700 wurde keine 0.7.9 gebaut, wie bei der Kontrolle der experimental- und testing-Phase ergab …
Gibt dann die Möglichkeit, das gleich als 0.8.0 zu bauen 
Ich poste das auch nachher noch im Blog (=> FB, Twitter, Forum): bitte mal auf Eure Knoten achten, ob sie sich anders verhalten, insbesondere auf Reboots und WiFi-Stabilität schauen.
