Update bzgl. Firmware 1.0

[wusel (Kai 'wusel' Siering)]

[Echo (René Hézser)]

Fazit: Läuft

1. per wget nach /tmp die FW heruntergeladen
2. sysupgrade -v image
3. gewartet
4. spezielle config für die Lan ports wieder eingespielt
5. nichts weiter gemacht
6. Speedtest liefert 54ms, >10MBit Down und >1 MBit Up. Damit bin ich sehr zufrieden (Router auf dem Dachboden und ich im Wohnzimmer)

Der Router hat von meiner Fritzbox eine neue interne IP bekommen. Das ist etwas merkwürdig. Hat sich evtl. die mac geändert? Umgesteckt habe ich im Router nichts.

[wusel (Kai 'wusel' Siering)]

Der Router hat von meiner Fritzbox eine neue interne IP bekommen. Das ist etwas merkwürdig. Hat sich evtl. die mac geändert? Umgesteckt habe ich im Router nichts.

Yepp, das kann leider sein — die MAC-Adresse änderte sich über die Gluon-Generationen leider immer mal wieder: Gluon muß aus der einen HW-MAC bis zu 5 verschiedene erzeugen und dabei aufpassen, daß keine Dubletten erzeugt werden. 0.7.9 hatte ein Feature, die erzeugte MAC zu speichern, damit sie bei zukünftigen Updates stabil bleibt — aber halt erst ab Erzeugung.

Vgl. https://gluon.readthedocs.io/en/v2017.1.x/releases/v2017.1.html

The MAC address of the WAN interface is modified even when Mesh-on-WAN is disabled (#496)

This may lead to issues in environments where a fixed MAC address is expected (like VMware when promicious mode is disallowed).

[Echo (René Hézser)]

In meinem Fall habe ich mich nur kurz gewundert. Ich erwähnte es nur, da wir das Thema mal hier im Forum hatten.
Sollte ggf. in die Release Notes aufgenommen werden.

[Cord]

Mein Knoten hat seit mindestens gestern kein WLAN-Signal mehr ausgesendet. Ich konnte nicht erkennen warum.

Ich habe das Teil heute auf “experimental” gestellt und den autoupdate angeworfen, jetzt geht es wieder. http://map.4830.org/#!v:m;n:e894f66304a2

[wusel (Kai 'wusel' Siering)]

Könnte die typische 841er-Krankheit sein, siehe auch [RT.4830 #1020] (der fragliche Knoten verzeichnet seit Tagen keine WiFi-Clients). Ich habe derlei auch mit 'nem 841 in der 4ma gehabt, “wifi stop; sleep 2; wfi start” und der Spuk war meist vorbei

[Cord]

alles probiert. inklusive Stromlos machen. nope. erst nach dem Update wieder. (Vorher habe ich das Verhalten aber auch nie beobachtet.

BTW: die beiden ntp-Server die konfiguriert werden scheinen nicht zu funktionieren.

Name: ntp.4830.org
Address 1: 2a06:e881:1700:1:400:c0ff:fefb:e21a
Address 2: 2a06:e881:1700:1:400:c0ff:fefb:e277
Name: ntp.services.ffgt.net
Address 1: fd42:ffee:ff12:aff::201
Address 2: fd42:ffee:ff12:aff::202

Alle nicht für ntp-Requests empfänglich. meine lokale Fritzbox und mein Server gehen.

[wusel (Kai 'wusel' Siering)]

Yepp, auch bemerkt. IP zeigt auf gw10, was down ist. Plan: auf s1 und/oder s2 hochziehen und DNS umpointern. Externer NTP-Server mit v6 wäre schön; die pool.*-Dinger haben leider selten v6

[Cord]

weyoun3.cord.de und weyoun4.cord.de sind im pool.ntp.org und haben IPv6. könnte man also nehmen.

aber https://www.pool.ntp.org/zone/de sagt das mehr als die Hälfte der Server auch IPV6 haben.

[wusel (Kai 'wusel' Siering)]

aber https://www.pool.ntp.org/zone/de sagt das mehr als die Hälfte der Server auch IPV6 haben.

Ich hatte in der Vergangenheit das Problem, daß gelegentlich kein AAAA-RR zurückkam, oder war’s, daß A & AAAA zurückkamen und die Knoten ja nur per v6 anfragen können? Dunno …

weyoun3.cord.de und weyoun4.cord.de sind im pool.ntp.org und haben IPv6. könnte man also nehmen.

Merci! Jene, plus ntp2.ptb.de, bilden nun erstmal ntp.4830.org …

ntp             60      AAAA    2001:638:610:be01::104
                60      AAAA    2a00:5080:1:20::1
                60      AAAA    2a03:4000:6:b079::c03d

[Cord]

Ich hatte in der Vergangenheit das Problem, daß gelegentlich kein AAAA-RR zurückkam, oder war’s, daß A & AAAA zurückkamen und die Knoten ja nur per v6 anfragen können? Dunno

offenbar sind nur in 2.de.pool.ntp.org IPv6-Server drin.

[wusel (Kai 'wusel' Siering)]

Das war’s, kein AAAA:

wusel@ysabell:~$ dig aaaa pool.ntp.org

; <<>> DiG 9.9.5-11ubuntu1.3-Ubuntu <<>> aaaa pool.ntp.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25876
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;pool.ntp.org.                  IN      AAAA

;; AUTHORITY SECTION:
pool.ntp.org.           481     IN      SOA     c.ntpns.org. hostmaster.pool.ntp.org. 1545944764 5400 5400 1209600 3600

;; Query time: 72 msec
;; SERVER: 192.168.188.254#53(192.168.188.254)
;; WHEN: Thu Dec 27 22:09:34 CET 2018
;; MSG SIZE  rcvd: 96

[wusel (Kai 'wusel' Siering)]

Sollte ggf. in die Release Notes aufgenommen werden.

Naja, wer manuell downgraded, sitzt i. d. R. auch nah am Gerät und kann die ggf. notwendige MAC-Freischaltung orchestrieren. (Lies: 1. ausgewählte MAC darf nach aktuellem Gluon-Standard sein.) Nur bei automatischen Updates darf eigentlich kein MAC-Wechsel vorkommen. (Lies: für MAC-sensitive Setups sollte die FFGT-FW, sofern das Flag gesetzt wurde, die initiale MAC mitschleppen.)

Aber ein Link auf die Releasenotes »von Upstream« macht Sinn in den eigenen, ja.

[Cord]

Naja, wer manuell downgraded, sitzt i. d. R. auch nah am Gerät und kann die ggf. notwendige MAC-Freischaltung orchestrieren. (Lies: 1. ausgewählte MAC darf nach aktuellem Gluon-Standard sein.) Nur bei automatischen Updates darf eigentlich kein MAC-Wechsel vorkommen. (Lies: für MAC-sensitive Setups sollte die FFGT-FW, sofern das Flag gesetzt wurde, die initiale MAC mitschleppen.)

Bei mir hat sich die MAC auch von
EA:95:F6:63:04:A2
auf
EA:AB:93:93:7C:48
geändert. Ich habe einfach ein Upgrade durchgeführt.

[wusel (Kai 'wusel' Siering)]

Oh. hier auch.

Das bezog sich auf die MAC?

Bei mir hat sich die MAC auch von
EA:95:F6:63:04:A2
auf
EA:AB:93:93:7C:48
geändert. Ich habe einfach ein Upgrade durchgeführt.

Hmm, kann ich nicht nachvollziehen?

  OS: Chaos Calmer, r49389                FW: 0.7.9~133                       
  HW: TP-Link TL-WR841N/ND v9                                             
root@33332-4830-776a:~# ip link show br-wan
8: br-wan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether a6:d9:bb:13:e1:e8 brd ff:ff:ff:ff:ff:ff

  OS: Chaos Calmer, r49389                FW: 0.7.9~164                       
  HW: TP-Link TL-WR841N/ND v9                                             
root@33332-4830-776a:~# ip link show br-wan
8: br-wan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue 
    link/ether a6:d9:bb:13:e1:e8 brd ff:ff:ff:ff:ff:ff

  OS: 17.01-SNAPSHOT, r3981+103-184fe1    FW: 1.0.0~112                       
  HW: TP-Link TL-WR841N/ND v9                                             
root@33332-4830-776a:~# ip link show br-wan
7: br-wan: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN qlen 1000
    link/ether a6:d9:bb:13:e1:e8 brd ff:ff:ff:ff:ff:ff

[wusel (Kai 'wusel' Siering)]

Frohes Neues Jahr!

Es beginnt mit 0.7.9~164 (Gluon v2016.2.7+) als “testing”-Version — bitte alle “Tester” im Kreis Gütersloh, das betrifft die Knoten …

Knoten	Uptime	Links	Clients
33330-Physiotherapie-Zeitzen	0h	0	0
33332-S107-RPT-OG-8be4	10d	5	2
33334-Hessenheide	1h	0	0
33415-Alter-Bahnhof-Kaunitz1	0h	1	0
33415-Alter-Bahnhof-Kaunitz2	0h	1	0
33415-Kolping-Pfarrheim-Kaunitz	0h	1	1
33415-Kolping-Pfarrheim-Kaunitz1	15d	2	1
33829-Buergerhaus-Masch-2A-2e40	0h	1	0
ffgt-aale894f64b1306	13d	0	1

… sowie der Müritz-Region und der Feldberger Seenplatte, dies betrifft die Knoten …

Knoten	Uptime	Links	Clients
17192-Jugendtreff-Papenberg	29d	0	1
17192-Lange-Str-6ff2	-9d	0	0
17192-Neuer-Markt-5038	3d	0	0
17192-Speicher-No1	0h	0	1
17192-Stadtbibliothek-0904	49d	0	0
17192-Strelitzer-Str-a010	1h	0	2
17192-Teenotel-5fc2	0h	0	0
17192-Teenotel-e6ae	0h	0	0
17192-Werderweg-381e	0h	0	0
17194-Fewo-MV-6430	0h	0	1
17194-Tressow-7002	1h	0	0
17194-Tressow-c5d8	-12h	0	0
17209-Zum-Kleinen-Urlaub-a71e	0h	0	4
17252-Hotel-Seepromenade	0h	0	0
17252-Hotel-Seepromenade-2	0h	0	7
17252-Hotel-Seepromenade-3	1h	0	1

… etwaige Unregelmäßigkeiten zu melden. Es sollte keine geben, daher ist der aktuelle Plan, diese Firmware, die Voraussetzung für ein möglichst streßfreies Update auf Firmware 1.0 basierend auf Gluon v2018.1 ist, am Sonntag (6.1.19) nach “stable” zu schieben.

Pinging @m.bitterlich (Müritz) und @charrr (Feldberg) … Bitte zeitnah ein “HAAAALT!”, falls das bei Euch nicht tun sollte.

[wusel (Kai 'wusel' Siering)]

FTR:

Kurzum: wohl um den Jahreswechsel wird die Firmware 1.0 nach heutigem Stand nach »stable« wechseln und entsprechend werden sich dann alle Knoten diese Version per Autoupdate ziehen.

Das klappte »natürlich« nicht, weil wir ja erst eine neue 0.7.9er auf alle Knoten packen wollen. Daher ist die aktuellste 0.7.9er-FW aktuell in »testing« und geht in der Nacht zu Sonntag nach »stable«. Kurz darauf folgt dann 1.0.0, die derzeit in »rawhide« und »experimental« schon getestet wird.

[wusel (Kai 'wusel' Siering)]

Und mit einem Tag Verspätung sollten die Knoten sich nun auch die neue »stable«-Firmware installieren, nachdem ich Dummerchen auch die zweite Signatur hinzugefügt habe:

root@33332-4830-776a:~# /usr/sbin/autoupdater
Connecting to firmware.ipv4.4830.org (193.26.120.20:80)
wget: can't connect to remote host (193.26.120.20): Network is unreachable
There seems to have gone something wrong downloading the manifest from http://firmware.ipv4.4830.org/stable/sysupgrade
Connecting to firmware.ipv6.4830.org ([2a06:e881:1700:1:400:c0ff:fefb:e216]:80)
-                    100% |*******************************| 53550   0:00:00 ETA
Not enough valid signatures!
No usable mirror found.

ffgt@colosses:~/jenkins_data/build$ gluon-ffgt-v2016.2/contrib/sign.sh /tmp/secret-wusel /firmware/stable//sysupgrade/stable.manifest

root@33332-4830-776a:~# /usr/sbin/autoupdater
Connecting to firmware.ipv6.4830.org ([2a06:e881:1700:1:400:c0ff:fefb:e216]:80)
-                    100% |*******************************| 53679   0:00:00 ETA
New version available.
Stopping cron...
Stopping haveged...
Stopping micrond...
Stopping sysntpd...
Stopping gluon-radvd...
Stopping uhttpd...
Stopping sse-multiplexd...
Stopping alfred...
sed: /etc/crontabs/root: No such file or directory
Command failed: Not found
Stopping gluon-respondd...
vm.drop_caches = 3
Connecting to firmware.ipv6.4830.org ([2a06:e881:1700:1:400:c0ff:fefb:e216]:80)
lua_Rev7OU           100% |*******************************|  3520k  0:00:00 ETA
Connection to 2001:bf7:1310:11:ea94:f6ff:fea4:776a closed.

Brace for updates