Wie sieht es bei den TP-Link CPE210 v1.0 aus? Rawhide Aufspielung jetzt über sysupgrade möglich?
Ah, sorry, Info gefunden.
Gluon 2018.1
Important notes
This version changes the flash partition layout on some devices (TP-Link CPE/WBS 210/510). To avoid upgrade failures, make sure to upgrade to Gluon 2017.1.8 or the latest Gluon 2016.2.x (unreleased) before installing Gluon 2018.1.
Nope, erst müßte eine (noch?) nicht existente 0.7er auf Basis v2016.2.unreleased eingespielt werden, AFAIK. Ob factory Geht: dunno. Müßte man mal im großen Forum fragen …
Ich habe es vernünftig gemacht. Original Firmware der TP-Link CPE210 v1.0 per Tftpd aufgespielt und danach das Factory Image 1.0.0~90 geladen. Alles neu Konfiguriert und schnell mal getestet. Fazit: läuft gut, soweit ich das bis jetzt sagen kann.
Habe gestern einen meiner 841 aktualisiert. Habe die Einstellungen übernommen, bin einmal in die Konfigmode gegangen. Sieht ganz gut aus. Die Netzbasierte Geolokalisierung funktionert aber immer noch nicht. Ich habe schon Koordinaten drin, die allerdings absichtlich nicht passen.
Dann ist mir noch aufgefallen, dass die RAM Nutzung höher ist als vorher.
Werde mal weiter testen.
Die “Netzbasierte Geolokalisierung” hat bei mir wiederum funktioniert aber den Punkt leider gute 50m versetzt. Vermutlich liegt es hier an der geringen WLAN-Dichte. 
Wie ist die richtige Verfahrensweise dazu?
Koordinaten 0:0 und Haken drinne + [weiter]
oder Koordinaten suchen und Haken trotzdem drinne lassen?
…
crontab / micron
Da ich die Verfügbarkeit der Geräte/Internet und Reboots mit Skripten über /etc/crontab/root in der “alten” Firmware manage, habe ich die Konfig zu micrond gesucht und hier einen Hinweis gefunden:
https://ffmuc.net/wiki/p/Crontab
ntpd
Die beiden Standard-Zeitserver sind nicht wirklich aus dem Müritzer Netz verfügbar …
list server 'ntp.4830.org'
list server 'ntp.services.ffgt.net'
Da für cron/micron die Zeit wichtig ist, habe ich erstmal meinen Offloader eingetragen:
list server 'fd39:e4e3:eee1:0:218:f3ff:fe99:301'
Als Sicherheit habe ich folgenden Eintrag noch in /etc/crontab/root
*/55 * * * * /usr/sbin/ntpd -n -q -d -p fd39:e4e3:eee1:0:218:f3ff:fe99:301 > /etc/_set_time_on_boot_
Nun sind die Firmware-Upgates für diesen Eintrag tödlich (/etc/config/system wird neu geschrieben) … Kai, kannst du dir das mal anschauen, ob du dafür eine elegante Lösung findest?
Sollten erreichbar sein und sind es auch — zumindest ntp.4380.org?
root@17258-FW-Test-4830-b9d0:~# traceroute ntp.4830.org
traceroute to ntp.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277), 30 hops max, 16 byte packets
1 mueritz-bgp1.mueritz.freifunk.net (2001:bf7:170::5) 14.776 ms 15.627 ms 22.005 ms
2 bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277) 17.318 ms 17.080 ms 16.706 ms
root@17258-FW-Test-4830-b9d0:~# traceroute 2a06:e881:1700:1:400:c0ff:fefb:e277
traceroute to 2a06:e881:1700:1:400:c0ff:fefb:e277 (2a06:e881:1700:1:400:c0ff:fefb:e277), 30 hops max, 16 byte packets
1 mueritz-bgp1.mueritz.freifunk.net (2001:bf7:170::5) 15.015 ms 14.770 ms 18.286 ms
2 bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277) 16.998 ms 16.038 ms 17.687 ms
root@17258-FW-Test-4830-b9d0:~# traceroute 2a06:e881:1700:1:400:c0ff:fefb:e21a
traceroute to 2a06:e881:1700:1:400:c0ff:fefb:e21a (2a06:e881:1700:1:400:c0ff:fefb:e21a), 30 hops max, 16 byte packets
1 mueritz-bgp1.mueritz.freifunk.net (2001:bf7:170::5) 15.674 ms 16.200 ms 15.356 ms
2 bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277) 15.799 ms 16.402 ms 16.625 ms
3 gw10.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e21a) 17.604 ms 17.414 ms 17.520 ms
Bei den ffgt.net-Dingern haste recht, das sind Altlasten aus »wir wissen auch nicht so recht«, die fliegen raus — danke für’s finden Evtl. machen wir da einen anycasted Eintrag a la “ntp-any.4830.org”, der dann z. B. auf jedem GW läuft (und so in jedem Mesh funktionierte)?
Ach du bist das — und ich wundere mich schon, warum Kölner jetzt unsere FW nutzen wollen 
Hmm. Letzter Datensatz ist aus dem Juli, da wurde das auf 51.846732; 8.3268735 lokalisiert. Da scheint irgendwas mit dem Hochladen der Daten nicht zu stimmen …
logfiles durchwühl Oops.
GeoLocation Error: dailyLimitExceeded
DBG: G says: 0;0
GeoLocation failed.
Das dürfte wohl mit der Mail vom 17.07.2018 zutun haben:
Google Maps Platform’s new pricing and terms of service go into effect today. You’ll need a billing account to continue using our products, but we’ve noticed you haven’t yet added your billing information. Because of this, starting today your projects are at risk of service interruption.
Hatte eigentlich nicht vor, Google dafür zu bezahlen; free usage tier und dann cutoff ist ja ok, aber – verständlicherweise – möchte Google lieber direkt zum Billing übergehen. Hrmpft.
Okay, neue Baustelle, aber ich hatte da IIRC schon einen Plan B eingebaut; und passend zu Google will Geld sehen hat sich HERE IIRC geöffnet …
Das kann sein; mit ein Grund, warum im Raum steht, die 4/16 MB-Geräte (Flash/RAM) auf v2016.2.x zu lassen und als Auslaufmodell zu behandeln.
Sieht bei mir ähnlich aus:
Also auch in der vorigen Firmware (0.7) wurde schon micrond eingesetzt; und in der akuellen wird die parallele Ausführung von cron versucht zu verhindern — siehe Speicherverbrauchsthema.
*/55 kriege ich zudem nicht geparst — jede Minute * alle 55 Minuten? Geht das?*/5 kenne ich, alle 5 Minuten (statt 0,5,10,15,......). Anyway, mit >/etc/_set_time_on_boot_ schreibst Du wohl alle 55 Minuten ein Datum ins Flash des Routers. Ob das so eine gute Idee ist, wenn sogar das wiederholte Rückschreiben der Config ins Flash zu minimieren versucht wird latent eher nicht.
That said: man könnte die NTP-Server rausparsen und gegen den 1. z. B. 5 und 15 Minuten nach dem Reboot sowie per micrond alle n Minuten (n=45, 60, 240, ?) sowas wie oben gegen den 2. ausführen lassen. (Nur mit Redirect nach /dev/null statt ins Filesystem.)
Okay, fixed.
GeoLocation Error: dailyLimitExceeded
DBG: G says: 0;0
GeoLocation with Google failed. Retrying with HERE.
DBG: HERE says: 51.9053405;8.376885496
DBG: coords now: 51.9053405;8.376885496
DBG: coords 51.9053405;8.376885496 resolve to Muensterstr-4, 33330 Guetersloh (gut)
Händisch hingelegt hatte ich ihn bei 51.905237; 8.3767.
Please retry.
Hmm, vermutlich waren noch nicht rausgealterte Daten vorhanen, auf die greift der Code nämlich in Ermangelungen aktueller Daten zurück — Google-Geolocation sollte seit ca. 1 Monat nicht mehr tun 
Also, der Haken sollte von der Firmware als Default gesetzt werden, wenn a) das Gerät WLAN hat (Futros/VMs ohne WLAN haben i. d. R. keine WLAN-Optionen) und b) noch keine Koordinaten hinterlegt (im System, nicht im Browser). Wenn schon Geokoordinaten hinterlegt sind, sollte der Haken nicht aktiviert sein im GUI. Was Ihr damit macht, ist Eure Sache Wenn der Haken gesetzt ist, versucht die Firmware eine Lokalisierung anhand der WLANs — und ignoriert die eingegebenen Koordinaten. Entweder Automagie, oder manueller Eintrag.
Haardstr-86 ist besser?
Hier auch nicht viel besser; reale Position:
Automagisch ermittelte:
Da die Empfangsstärke bei diesen APIs nicht verwendet wird, wird man mit dem Fehler wohl leben müssen. Für die Zuordnung zu einem Mesh reichts
Test - OK:
root@17194-Tressow-9332:~# traceroute ntp.4830.org
traceroute to ntp.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e21a), 30 hops max, 16 byte packets
1 mueritz-bgp1.mueritz.freifunk.net (2001:bf7:170::5) 54.528 ms 26.950 ms 26.348 ms
2 bgp-gut01.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e277) 27.708 ms 28.041 ms 26.987 ms
3 gw10.4830.org (2a06:e881:1700:1:400:c0ff:fefb:e21a) 28.470 ms 27.612 ms 26.768 ms
Aber warum sind sie so geizig und geben von ihrer Zeit nicht ein wenig ab?
root@17194-Tressow-9332:~# cat /etc/config/system | grep -i "list server"
list server 'ntp.4830.org'
list server 'ntp.services.ffgt.net'
list server 'fd39:e4e3:eee1:0:218:f3ff:fe99:301'
root@17194-Tressow-9332:~# /usr/sbin/ntpd -n -q -d -p ntp.4830.org
ntpd: sending query to 2a06:e881:1700:1:400:c0ff:fefb:e277
Alarm clock
root@17194-Tressow-9332:~# /usr/sbin/ntpd -n -q -d -p ntp.services.ffgt.net
ntpd: sending query to fd42:ffee:ff12:aff::202
Alarm clock
root@17194-Tressow-9332:~# /usr/sbin/ntpd -n -q -d -p fd39:e4e3:eee1:0:218:f3ff:fe99:301
ntpd: sending query to fd39:e4e3:eee1::218:f3ff:fe99:301
ntpd: reply from fd39:e4e3:eee1::218:f3ff:fe99:301: offset:+0.036290 delay:0.055533 status:0x24 strat:1 refid:0x00000000 rootdelay:0.000000 reach:0x01
ntpd: sending query to fd39:e4e3:eee1::218:f3ff:fe99:301
ntpd: reply from fd39:e4e3:eee1::218:f3ff:fe99:301: offset:+0.038816 delay:0.059966 status:0x24 strat:1 refid:0x00000000 rootdelay:0.000000 reach:0x03
root@17194-Tressow-9332:~#Eigentlich sollte es aller 55 min sein. Da du jetzt so hinterfragst hab, ich mal nach geschaut. Funktioniert warscheinlich bei Minuten nur bis */30.
Wed Aug 15 08:55:00 2018 cron.info crond[1041]: USER root pid 16559 cmd ntpd -q -d -p fd39:e4e3:eee1:0:218:f3ff:fe99:301 > /etc/_set_time_on_boot_
Wed Aug 15 09:00:00 2018 cron.info crond[1041]: USER root pid 17049 cmd ntpd -q -d -p fd39:e4e3:eee1:0:218:f3ff:fe99:301 > /etc/_set_time_on_boot_
Wed Aug 15 09:55:00 2018 cron.info crond[1041]: USER root pid 21793 cmd ntpd -q -d -p fd39:e4e3:eee1:0:218:f3ff:fe99:301 > /etc/_set_time_on_boot_
Wed Aug 15 10:00:00 2018 cron.info crond[1041]: USER root pid 22263 cmd ntpd -q -d -p fd39:e4e3:eee1:0:218:f3ff:fe99:301 > /etc/_set_time_on_boot_
Wed Aug 15 10:55:00 2018 cron.info crond[1041]: USER root pid 28805 cmd ntpd -q -d -p fd39:e4e3:eee1:0:218:f3ff:fe99:301 > /etc/_set_time_on_boot_
Das mit dem Schreiben ins Flash ist vielleich nicht so gut, gebe ich zu. Es wird aber nur eine leere Datei geschrieben, bzw. aktualisiert. Da diese die aktuelleste Datei in /etc ist, sollte diese Datum/Zeit-Kombination als aktuelle Zeit beim Boot-Prozess genommen werden. So ist die Zeitdifferenz zur aktuellen Zeit nicht so groß.
Oder habe ich das mit [ $curtime -lt $maxtime ] && date -s @$maxtime in “/etc/init.d/sysfixtime” falsch verstanden?
root@17194-Tressow-9332:~# cat /etc/init.d/sysfixtime
#!/bin/sh /etc/rc.common
# Copyright (C) 2013-2014 OpenWrt.org
START=00
STOP=90
RTC_DEV=/dev/rtc0
HWCLOCK=/sbin/hwclock
boot() {
start && exit 0
local maxtime="$(maxtime)"
local curtime="$(date +%s)"
[ $curtime -lt $maxtime ] && date -s @$maxtime
}
start() {
[ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -s -u -f $RTC_DEV
}
stop() {
[ -e "$RTC_DEV" ] && [ -e "$HWCLOCK" ] && $HWCLOCK -w -u -f $RTC_DEV && \
logger -t sysfixtime "saved '$(date)' to $RTC_DEV"
}
maxtime() {
local file newest
for file in $( find /etc -type f ) ; do
[ -z "$newest" -o "$newest" -ot "$file" ] && newest=$file
done
[ "$newest" ] && date -r "$newest" +%s
}
Letztendlich ist es eine Notlösung, um bei zeitweise defekten NTP-Server eine halbwegs aktuelle Zeit nach einem Reboot auf dem System zu haben.
Weil dieser ganze NTP-Dreck in Ubuntu flambierte Kacke ist ntpd läßt keine Abfragen zu (manpage listet “restrict”-Kommando nicht einmal), und wenn man nach ntp openntpd installiert (apt-get purge ntp; apt-get install openntp), wird man von apparmor gefickt, der einfach mal den Stinkefinger rausholt. systemd macht die Rotze noch richtig klar verständlich (nein, nur das Gegenteil, wie immer bei systemd):
root@ntp:~# systemctl teardown apparmor
Unknown operation teardown.
root@bgp-gut01:~# /etc/init.d/apparmor teardown
* Unloading AppArmor profiles [ OK ]
Gefixt mit der groben Kelle:
root@ffgt-a0f3c1058b90:~# /usr/sbin/ntpd -n -q -d -p ntp.4830.org
ntpd: resolved peer ntp.4830.org to 2a06:e881:1700:1:400:c0ff:fefb:e277
ntpd: sending query to 2a06:e881:1700:1:400:c0ff:fefb:e277
ntpd: reply from 2a06:e881:1700:1:400:c0ff:fefb:e277: offset:+0.003008 delay:0.018349 status:0x24 strat:3 refid:0x6d4ac061 rootdelay:0.037064 reach:0x01
ntpd: sending query to 2a06:e881:1700:1:400:c0ff:fefb:e277
ntpd: reply from 2a06:e881:1700:1:400:c0ff:fefb:e277: offset:+0.002780 delay:0.017023 status:0x24 strat:3 refid:0x6d4ac061 rootdelay:0.037064 reach:0x03
ntpd: sending query to 2a06:e881:1700:1:400:c0ff:fefb:e277
ntpd: reply from 2a06:e881:1700:1:400:c0ff:fefb:e277: offset:+0.002928 delay:0.017512 status:0x24 strat:3 refid:0x6d4ac061 rootdelay:0.037064 reach:0x07
ntpd: sending query to 2a06:e881:1700:1:400:c0ff:fefb:e277
ntpd: reply from 2a06:e881:1700:1:400:c0ff:fefb:e277: offset:+0.002474 delay:0.021017 status:0x24 strat:3 refid:0x6d4ac061 rootdelay:0.037064 reach:0x0f
ntpd: sending query to 2a06:e881:1700:1:400:c0ff:fefb:e277
ntpd: reply from 2a06:e881:1700:1:400:c0ff:fefb:e277: offset:+0.002737 delay:0.018138 status:0x24 strat:3 refid:0x6d4ac061 rootdelay:0.037064 reach:0x1f
Mal tagsüber angucken die Fickschweinkacke …
Fehlermeldung bei Erstinstallation von 1.0.0~94 (auf Ubiquiti AC Mesh)
Failed to execute dispatcher target for entry '/wizard'.
The called action terminated with an exception:
/lib/gluon/config-mode/wizard/0500-contact-info.lua:15: attempt to index global 'util' (a nil value)
& beim Absenden von /config/admin/contact
/usr/lib/lua/gluon/web/template.lua:49: Failed to load template 'admin/contact_done'.
Error while parsing template '/lib/gluon/config-mode/view/admin/contact_done.html':
Syntax error in /lib/gluon/config-mode/view/admin/contact_done.html:45: '%>' expected before end of fileErgänzung
Emailadresse für Kontakt wird trotzdem geschrieben und danach funktioniert auch die erste Seite des Wizards wieder (Eingabe Knotenname etc.)
Ah, fsck. Sorry for that, der Wizard sollte nun, wenn aus dem Wizard in den Admin-Bereich gesprungen wird, wieder in den Wizard zurücksprigen (die Admin-Seiten bleiben im Normallfall mit 'ne "OK"Ausgabe einfach stehen). Dabei habe ich wohl Mist gebaut, gucke nachher mal.
Danke für den Hinweis,
-kai
1.0.0~95 baut gerade und sollte die beiden Flüchtigkeitsfehler behoben haben.
1 „Gefällt mir“