Update bzgl. Firmware 1.0

Firmware
1

Orginaler Blog-Post: https://freifunk-kreisgt.de/update-bzgl-firmware-1-0/

Es gibt nun doch eine Planänderung …

Wir haben uns das Szenario die letzten Monate über genau angesehen, und letztlich ist es doch im Interesse aller Parteien – Nutzern, Knotenbetreibern und uns –, Firmware 1.0 – die auf Gluon v2018.1 basiert – durchgehend für alle bisher unterstützten Geräte zu verteilen, sofern sinnvoll möglich.

Und »sinnvoll möglich« scheint dies auch für die schmalbrüstigen Kisten mit 4MB Flash und 32 MB RAM zu sein — wir haben das intern getestet, und mit dem 2018er-Zweig funktionieren z. B. TP-Links 841er-Knoten vergleichbar stabil wie mit der Vorgängerfirmware 0.7, die noch auf Gluon v2016.2.7 basierte. (Wie berichtet, war dies in anderen Communities mit Gluon v2017.1 als Firmwarebasis leider nicht der Fall, weshalb wir jene Version gezielt ausgelassen haben.)
Um auf Nummer Sicher zu gehen, gibt es, quasi als Weihnachtsgeschenk, eine neue Version der 0.7.9er Firmware, die die letzten Patches der Gluon-v2016.2.7er-Reihe beinhaltet und somit als Brückenbauer u. a. für die CPE dienen kann.

Seit Ende Dezember gibt es wieder neue Testversionen der Firmware, deren Basis wir mittlerweile auch auf Gluon v2018.1.4 gehievt haben. Neu hinzugekommen sind auch Pakete der Darmstädter Kollegen, insbesondere zu nennen ist das Paket »ffda-domain-director«, welches unser selbst­ge­stricktes Skript­werk zur auto­ma­ti­schen, geo­lo­kations­ba­sier­ten Kno­ten­kon­fi­gu­ra­tion ablöst. (Die Kollegen haben das schön in Lua im­ple­men­tiert, statt wie unsereins mit krudem Shell-Skripting, das Feature kon­fi­gurier­bar ge­macht und auch eine Zeit­option ein­ge­baut, sodaß man die Kon­fi­guration auf allen Knoten quasi zum nächsten Boot­zeit­punkt akti­viert und jenen vorab fest­legen kann. Vielen Dank für’s Bereitstellen auf github!)

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.
Insofern die Bitte an die Knotenbetreiber, die das Autoupdate deaktiviert haben: bitte die üblichen Kanäle (Website, Forum, Twitter, Facebook) verstärkt im Auge behalten und kurzfristig ein manuelles Autoupdate starten, danke.

2

Wow. Danke schön. Soll ich die Experimental auf meinem 841 testen?

3

Gerne, aber wirst 'nen manuellen Downgrade machen müssen, d. h. Installation oben Datenübernahme (quasi Neuinstallation mit 0.7.9).

4

Kein Problem. Also sysupgrade Image Experimental. Spiele ich heute oder morgen ein.

5

:+1: :slight_smile:

6

Fazit: Läuft :grin:

  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.

7

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

8

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.

9

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

10

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 :frowning:

11

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.

12

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 :frowning:

13

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.

14

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 …

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
15

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

1 „Gefällt mir“
16

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
17

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.

1 „Gefällt mir“
18

6 Beiträge wurden in ein neues Thema verschoben: Firmware 1.0 und LAN auf “gelb”

20

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.

21

Das bezog sich auf die MAC?

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