Was ich noch komisch finde ist, dass auf der Map Seite die Links nicht immer sauber angezeigt werden.
Erst der 841er und jetzt der 300er, warum auch immer
Aus dem Wizard raus ist immer etwas tricky. Der Wizard geht immer auf den nächsten unerfüllten Punkt (Geokoordinaten; Kontakt; finale Maske mit Namenswahl usw.); optimalerweise erst nach »Advanced« gehen für Remotezugriff (und ggf. andere Einstellungen), dann Wizard durchspielen. Weil: nicht gespeicherte Eingaben gehen verloren. (Sprich: Namen eintippen, dann auf Advanced => Name nicht gesetzt. Nach der Seite mit Namenswahl usw. kommt bei »Speichern« aber schon der Reboot, dann geht kein Advanced mehr.)
Ja, und auch setup.4830.org könnte man ein wenig Designliebe erfahren …
Ist es das? Hrmpft; eigentlich sollte es per Default angehakt sein, wenn noch keine Wahl getroffen wurde, sonst der bisherige Wert da stehen. Muß ich mir noch mal ansehen 
Oh, ja, das wäre interessant. Mit Gluon v2022.1+ wird das definitiv nicht der Fall sein; auch so’n Punkt, wo wir vorab drauf hinweisen sollten.
Danke!
Bei jedenUpdate? Das währe doof. Auf jeden Fall bei meinen Knoten
Was ändert sich denn da?
Siehe Gluon-Dokumentation, insbesondere Wired mesh (Mesh-on-WAN/LAN) — Gluon 2022.1 documentation
Teilweise also ein Fortschritt (endlich updatesichere VLANs), und ggf. macht’s unsere Patches für Config-on-WAN obsolet. We’ll see …
Das macht sinn.
Wird aber dann auf jeden Fall ein interssantes Update.
Wir müssen dann versuchen heraus zu finden welche Szenarien es alles gibt. Aber das wird ja noch etwas auf sich warten lassen.
Ich habe auf meinen 841 die Nachtuhre aktiviert. Sie funktioniert in meinen Augen nicht. Also WLAN wird nicht abgeschaltet. Kann das noch wer einma gegenprüfen, ob andere das Problem auch haben?
1 „Gefällt mir“
Korrekt. Es wurde ein Flag gesetzt, nicht aber auch die Zeiten.
Damit zusammenhängendes Thema, haben Eure Knoten die aktuelle Zeit? Meiner nicht so richtig:
root@33332-Schalueckstr-107-bc62:~# ps w | grep ntp
2605 root 1212 S< /usr/sbin/ntpd -n -N -S /usr/sbin/ntpd-hotplug -p ntp.4830.org -p ntp.services.ffgt.net
5002 root 1212 S grep ntp
root@33332-Schalueckstr-107-bc62:~# date
Thu May 5 19:04:04 CEST 2022
root@33332-Schalueckstr-107-bc62:~# opkg install ntpdate
Installing ntpdate (4.2.8p15-1) to root...
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/mipsel_24kc/packages/ntpdate_4.2.8p15-1_mipsel_24kc.ipk
Installing libevent2-core7 (2.1.11-1) to root...
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/mipsel_24kc/base/libevent2-core7_2.1.11-1_mipsel_24kc.ipk
Installing libevent2-pthreads7 (2.1.11-1) to root...
Downloading http://downloads.openwrt.org/releases/19.07-SNAPSHOT/packages/mipsel_24kc/base/libevent2-pthreads7_2.1.11-1_mipsel_24kc.ipk
Configuring libevent2-core7.
Configuring libevent2-pthreads7.
Configuring ntpdate.
Error resolving ntp.4830.org: Name does not resolve (-2)
root@33332-Schalueckstr-107-bc62:~# ntpdate -v ntp.4830.org
5 May 19:06:12 ntpdate[5080]: ntpdate 4.2.8p15@1.3728-o Wed Apr 20 10:38:55 UTC 2022 (1)
17 Jan 23:44:51 ntpdate[5080]: step time server 2a00:5080:1:20::1 offset +22225111.110678 sec
Denke, ich habe das jetzt funktional, auch die etwaigen OWE-APs werden nun deaktiviert:
root@33332-Schalueckstr-107-bc62:~# iwinfo
mesh0 ESSID: "12:42:de:ca:fb:ad"
Access Point: 1A:DB:2D:55:62:79
Mode: Mesh Point Channel: 9 (2.452 GHz)
Tx-Power: 20 dBm Link Quality: 56/70
Signal: -54 dBm Noise: unknown
Bit Rate: 6.5 MBit/s
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: 14C3:7628 14C3:0004 [MediaTek MT76x8]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
mesh1 ESSID: "12:42:de:ca:fb:ad"
Access Point: 16:59:C0:CA:BC:64
Mode: Mesh Point Channel: 44 (5.220 GHz)
Tx-Power: 22 dBm Link Quality: 59/70
Signal: -50 dBm Noise: unknown
Bit Rate: 6.5 MBit/s
Encryption: none
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 14C3:7662 14C3:7662 [MediaTek MT76x2E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy1
Neuer Build läuft …
Macht bei mir keine Probleme. Hatte es gestern auf den 841er geprüft, war OK und heute auf den anderen auch.
Mache heute noch einen Test mit der Nachtuhre.
Knoten auf der Karte anzeigen ist jetzt per Default gesetzt.
Habe aber noch eine Seite gefunden die sauber übersetzt werden sollte.
Müssen noch weitere Funktionen getestet werden?
- Privates WLAN
- Mesh on LAN / WAN ?
Die beiden habe ich aktuell noch nicht.
Das ist ein »fsck-you-lua?!« — ich verstehe noch nicht, wie ich diese Daten übergeben kann. Relevant wird das eigentlich primär bei fastd, wo ggf. der Key vorab verschickt werden/bekannt sein muß (falls wir mal wieder fastd-Meshes mit eingetragenen Knoten haben wollen würden — mir fielen da ein paar Einsatzzwecke ein).
Ok, dann ist’s ein lokales Problem:
root@33332-Schalueckstr-107-bc62:~# nslookup ntp.services.ffgt.net
Server: 127.0.0.1
Address: 127.0.0.1#53
*** Can't find ntp.services.ffgt.net: No answer
Name: ntp.services.ffgt.net
Address 1: fd42:ffee:ff12:aff::201
Address 2: fd42:ffee:ff12:aff::202
root@33332-Schalueckstr-107-bc62:~# nslookup ntp.4830.org
Server: 127.0.0.1
Address: 127.0.0.1#53
*** Can't find ntp.4830.org: No answer
Name: ntp.4830.org
Address 1: 2001:638:610:be01::104
Address 2: 2a00:5080:1:20::1
Address 3: 2a03:4000:6:b079::c03d
Schätze, ntp.services.ffgt.net kann dann wohl mal weg … [Done für den nächsten Build; ntp.services.ffgt.net-Einträge auf public v6 geändert.]
Hmm, das sollte eigentlich tun — vielleicht habe ich aber auch hier i18n falsch verstanden; der nächste Build wird es zeigen 
Habe ich auf meinem Test-R6120 an, tut soweit, ca. 95/45 meiner 1000/50er Leitung — der R6120 hat halt nur 100 MBIt/sec.
Should do, aber feel free
Nachtruhe funktioniert. Getestet aif de, 1200er und den 841er.
Kann es sein das es heute morgen mit der .35 er noch nicht ging? Aktuell haben alle die .36
Yepp, second that (R6120, also mit OWE-SSID, und mit aktiviertem privaten WLAN):
root@33332-Schalueckstr-107-bc62:~# date
Thu Jan 19 23:31:00 CET 2023
root@33332-Schalueckstr-107-bc62:~# cat /lib/gluon/release
1.4.0~35
root@33332-Schalueckstr-107-bc62:~# iwinfo
mesh0 ESSID: "12:42:de:ca:fb:ad"
Access Point: 1A:DB:2D:55:62:79
Mode: Mesh Point Channel: 9 (2.452 GHz)
Tx-Power: 20 dBm Link Quality: 67/70
Signal: -43 dBm Noise: unknown
Bit Rate: 26.0 MBit/s
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: 14C3:7628 14C3:0004 [MediaTek MT76x8]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
wan0 ESSID: "UU WPA3"
Access Point: 1A:DB:2D:55:62:7B
Mode: Master Channel: 9 (2.452 GHz)
Tx-Power: 20 dBm Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: WPA3 SAE (CCMP)
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: 14C3:7628 14C3:0004 [MediaTek MT76x8]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy0
wan1 ESSID: "UU WPA3"
Access Point: 1E:59:C0:CA:BC:64
Mode: Master Channel: 44 (5.220 GHz)
Tx-Power: 22 dBm Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: WPA3 SAE (CCMP)
Type: nl80211 HW Mode(s): 802.11nac
Hardware: 14C3:7662 14C3:7662 [MediaTek MT76x2E]
TX power offset: none
Frequency offset: none
Supports VAPs: yes PHY name: phy1
Eigentlich nicht …
Hmm. Das könnte hieran … liegen
Bei mir sieht aktuell auch alles gut aus.
→ Experimental ?
Ich würde heute Abend noch den respondd-Patch mitreinbacken (und die kaputten mailto-Links fixen), und danach gen experimental gehen wollen.
Soll ich noch etwas testen?
Vermutlich; laß’ uns nach der MV das Thema wieder betrachten …
… mein »Joy-IT JT-OR750i« läßt sich seit Version 1.4.0~36 leider nicht mehr dazu überreden, Firmwareupdates durchzuführen. Weder mit autoupdater noch über die Config-Modus (mit ~42 versucht).
Nachtrag: 1.4.0~36 war auch die erste Version, die ich da installiert habe.
Einen im Auslieferungszustand habe ich noch. Den teste ich mal am WE.
Cul8er
Matthias
1 „Gefällt mir“
Hmm. Mein Mi 4A Gigabit Edition mochte nicht von 1.4.0 auf 1.5.0 sich updaten, per autoupdater hing das Teil, Download der FW nach /tmp brachte eine Fehlermeldung über einen Versionsmismatch.
Sprich: Magst Du mal ein cd /tmp ; wget $URL ; sysupgrade -v gluon-4830<TAB> beim Joy-IT probieren, vielleicht gibt das genauere Diagnostik.
That said: Joy-IT und 4A Gigabit kommen offiziell erst in Gluon v2021.1.1 (Joy-IT) bzw. v2022.1 (4A GE), die Backports in unser Gluon v2020.2.x aka 1.4.0 bergen daher natürlich die Gefahr, daß es darin noch Bugs/Inkompatibilitäten gibt. Aber von 1.4.0~36 auf 1.4.0~42 sollte das eigentlich schon tun — mach bitte mal ein dmesg | grep "ffgt@":
root@33332-Schalueckstr-107-bc62:~# dmesg | grep "ffgt@"
[ 0.000000] Linux version 5.10.161 (ffgt@kaos) (mipsel-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r20044+10-ddeeb35007) 11.2.0, GNU ld (GNU Binutils) 2.37) #0 Wed Feb 8 17:04:11 2023
(Ältere 1.4er Builds wurden noch auf tomjon gebaut, was aber die gleiche Plattform ist (AMD Ryzen 5 3600) — unsere Intel(R) Xeon(R) E5645 im alten Buildserver colosses kauen ca. doppelt bis dreimal solange an einem Build, der auf dem Ryzen schon knapp 70 Minuten dauert.) Aber eigentlich dürfte das kein Grund sein, warum es beim Joy-IT nicht klappt.