- Dev - Freifunk Nordwest

TP-Link 1043 ND Ver 2.1
by Andreas Rudolph 23 Apr '18

23 Apr '18

Hallo zusammen, beim Flashen ist irgendetwas nicht so gelaufen, wie es sollte und nun hängt der Router in der Bootschleife. Folgende Information kann ich per serieller Schnittstelle auslesen, leider komme ich nicht weiter, um z.b. die Bootschleife zu beenden. Im Internet habe ich gefunden, dass man tpl (TPL?) kurz vor dem Reboot eingeben soll. Ich habe nur irgendwie das Gefühl, dass dies nicht ankommt (wie kann ich dies überprüfen?). Habt Ihr Tips, wie ich den wieder zum Leben erwecken kann? Könnt ihr das im Mainframe? Wegen meiner auch mit der Original Firmware... Vielen Dank. Gruß Andreas Rudolph ## Booting image at 9f020000 ... Uncompressing Kernel Image ... Too big uncompressed streamLZMA ERROR 1 - must RESET board to recover U-Boot 1.1.4 (Jun 13 2014 - 15:14:01) ap135 - Scorpion 1.0DRAM: sri Scorpion 1.0 ath_ddr_initial_config(178): (16bit) ddr2 init tap = 0x00000003 Tap (low, high) = (0x0, 0x1a) Tap values = (0xd, 0xd, 0xd, 0xd) 64 MB Flash Manuf Id 0xef, DeviceId0 0x40, DeviceId1 0x17 flash size 8MB, sector count = 128 Flash: 8 MB Using default environment *** Warning *** : PCIe WLAN Module not found !!! *** Warning *** : PCIe WLAN Module not found !!! In: serial Out: serial Err: serial Net: ath_gmac_enet_initialize... athrs_sgmii_res_cal: cal value = 0xe No valid address in Flash. Using fixed address No valid address in Flash. Using fixed address ath_gmac_enet_initialize: reset mask:c02200 Scorpion ----> S17 PHY * athrs17_reg_init: complete : cfg1 0x80000000 cfg2 0x7114 eth0: ba:be:fa:ce:08:41 eth0 up athrs17_reg_init_wan done SGMII in forced mode athr_gmac_sgmii_setup SGMII done : cfg1 0x800c0000 cfg2 0x7214 eth1: ba:be:fa:ce:08:41 eth1 up eth0, eth1 Setting 0x18116290 to 0x58b1a14f Autobooting in 1 seconds

1 0

hoodselector-bug?
by lrnzo 21 Apr '18

21 Apr '18

gerade das hier gefunden, vielleicht ist hier ein bug? LEDE Version: LEDE Reboot 17.01-SNAPSHOT r3862+42-60f8d388c6 (r3862+42-60f8d388c6) Gluon Version: v2017.1.5-21-g6639a649 Gluon Release: 20180403 Selected Hood: default ------------------------------------------------------------------------------ root@ffnw-LOHNetzIndustrie-Museum03:~# hoodselector The hoodselector is still running. root@ffnw-LOHNetzIndustrie-Museum03:~# cat /tmp/hoodselector_error command failed: No such device (-19) command failed: No such device (-19) ifconfig: SIOCGIFFLAGS: No such device ifconfig: SIOCGIFFLAGS: No such device Command failed: Request timed out Command failed: Request timed out Command failed: Request timed out Command failed: Request timed out Failed to parse json data: unexpected end of data Command failed: Request timed out Failed to parse json data: unexpected end of data Command failed: Request timed out /usr/bin/lua: /usr/sbin/hoodselector:110: attempt to index local 'a' (a nil value) stack traceback: /usr/sbin/hoodselector:110: in function 'h' /usr/sbin/hoodselector:181: in function 'r' /usr/sbin/hoodselector:481: in main chunk [C]: ?

2 2

Fwd: Ubiquiti XM Firmware
by Stefan Dunkel 21 Apr '18

21 Apr '18

Kann sich darum mal jemand kümmern? Danke! Von meinem iPhone gesendet Anfang der weitergeleiteten Nachricht: > Von: Henning Ahlers <ha.oldb(a)gmail.com> > Datum: 17. April 2018 um 19:49:01 MESZ > An: stefan.dunkel(a)ffnw.de > Betreff: Ubiquiti XM Firmware > Antwort an: ha.oldb(a)gmail.com > > Hallo! > > Ich habe zur Zeit 6 AP's, die ich betreue und ich bzw. die Bekannten sind damit echt zufrieden. > > Das letzte Auto-Update am 3. April hat auch bei 5 AP's super geklappt. Nur bei dem AP "ffnw-ol-hao-outdoor" (hier war zum Zeitpunkt des Updates ein "Ubiquiti NSM2 XM" installiert) hat das Update nicht funktioniert. > > Daraufhin habe ich einen "Ubiquiti NanoStation loco M2" neu auf die Firmwareversion April 2018 geflasht. > > Dieses funktionierte leider genauso wenig, wie das Update. > > Am Standort "OldenburgRaiffeisen*" und am "Mainframe/Space" waren ebenso ein NSM2 mit XM Firmware, die auch nach dem Update nicht in der Map auftauchen. > > Ich habe nun übergangsweise einen loco M2 mit Firmware Dezember 2017 installiert. > > FRAGE: Gibt es noch ein bereinigtes Update für die Ubiquiti XM Firmware, oder werden diese nicht mehr unterstützt? > > Viele Grüße, > > Henning Ahlers

3 3

Status LED bei FW Update
by Klaus Dint 18 Apr '18

18 Apr '18

Hallo, lässt es sich vielleicht einrichten, dass wenn ein Firmware Update beim FF Router durchgeführt wird (egal ob automatisch oder manuell durch autoupdater -f oder über das Webinterface) dies durch das Blinken einer Status LED wie der Power LED wie auch bei der Originalfirmware angezeigt wird? So könnte verhindert werden, dass die Firmware gebricked wird, wenn man das Gerät mal neu starten möchte, sich aber nicht sicher ist, ob nicht gerade ein Firmware Update stattfindet. Man könnte dies dann direkt am Gerät feststellen, ähnlich wie es z.B. auch beim Update der FritzBoxen der Fall ist. Danke und freundliche Grüße Klaus Dint

3 3

SSH Startscreen: Info über Firmware und Routermodell
by Klaus Dint 18 Apr '18

18 Apr '18

Hallo, wenn man sich mit einem Router über SSH verbindet, kann man leider nicht einfach erkennen,ob dieser nun mit der Fastd oder der L2TP Firmware arbeitet. Lässt sich dies noch zum "Welcome Screen" in der Konsole hinzufügen? Lässt sich vielleicht auch noch die Info hinzufügen, um welches Routermodell inkl. Version es sich handelt? Wäre hilfreich, wenn man zwar die Adressen alle gespeichert hat, aber nicht immer direkt weiß, wo nochmal welches Modell verwendet wird. Gruß Klaus Dint

1 0

Sign Request 201804013
by Jan-Tarek Butt 18 Apr '18

18 Apr '18

Moin zusammen, Ich habe heute eine neue Firmware gebaut. Basisdaten: * Firmware-Version: 20180413 * Gluon-Version: v2017.1.x * Commit ID: d06427d469230c457ab2b8fc8277b0b9c5bb2b73 * Download-fastd: https://firmware.ffnw.de/fastd/20180413 * Download-l2tp: https://firmware.ffnw.de/l2tp/20170413 Folgende Gluon spezifischen Änderungen gab es: * modules: update Gluon packages - 8b2f752daca5 batman-adv-legacy: update to latest git - 743527a47a22 batman-adv-legacy: batctl: backport TL header lines fix (#181) * modules: update LEDE * generic: do not attempt to build kmod-usbip * gluon-core: reduce mac80211 fq_codel memory limit to 256KB on devices with 32MB RAM Mehr und detailliertere Informationen findet ihr hier: https://github.com/freifunk-gluon/gluon/compare/883c32f2f1dc368626069865c07… Folgende Communnity spezifischen Änderungen gab es: package repo: * Add netdevice watchdog. Die Änderungen an unseren eigenen Paketen können im Packages-Repository hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/packages/compare/20180403..… siteconf repo: * UniFi AP AC Lite/Pro können nun wieder den autoupdater nutzen. Änderungen an der Siteconf können im Siteconf-Repo hier eingesehen werden: https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/compare/20180403..… Ich bitte euch die Änderungen zu prüfen und die Firmware im Anschluss zu signieren. Die Dokumentation zum Signaturprozess findet ihr im Wiki unter: https://wiki.nordwest.freifunk.net/Firmware/Releaseprozess#Firmware_signier… Schöne Grüße Tarek

4 8

wifiperf
by lrnzo 16 Apr '18

16 Apr '18

Hallo Leute, könnte man in der Firmware für die Modelle, wo der Platz reicht, das paket iperf3 mit einbauen? dann könnten die Router nämlich mit dem Script unter [1] regelmäßig den Durchsatz zu ihren Wifi-mesh Nachbarn messen und man könnte das irgendwie (tm) darstellen. zZ wird sich einfach die iperf3 Ausgabe im json-Format in einer Datei pro Meshnachbar gemerkt. [1] https://git.ffnw.de/lrnzo/wifiperf/blob/master/wifiperf.sh LG Lorenz

2 2

Mesh-Knoten bekommt keine IP, LQ 100 Prozent
by Malte Modler 14 Apr '18

14 Apr '18

Hallo, vielleicht hilft es euch als zusätzliche Info für die vielen Bugs. Ich bin mir sicher dass es ein neustart richten würde, aber ich lasse es erstmal so falls ihr noch weitere Infos für iwelche Bugs braucht. mein Meshknoten bekommt keine IP, hat aber eine Linkqualität von 100% bzw. 92% es handelt sich um folgenden Knoten: > https://map.ffnw.de/#/de/map/e894f6cd4638 Das Setup ist wie Folgt: <Internet="Vodafone/KDG">----<whv-mm-1="TP-Link Archer c7">))))))(((((<whv-mm-2="TP-Link WDR4300v1"> Logread: > https://pastebin.com/BnmSAjMS > ~# ip a > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel > state UP qlen 1000 > link/ether e8:94:f6:cd:46:36 brd ff:ff:ff:ff:ff:ff > inet6 fe80::ea94:f6ff:fecd:4636/64 scope link > valid_lft forever preferred_lft forever > 3: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000 > link/ether de:0f:4c:39:cf:a6 brd ff:ff:ff:ff:ff:ff > 4: teql0: <NOARP> mtu 1500 qdisc noop state DOWN qlen 100 > link/void > 9: br-wan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue > state UP qlen 1000 > link/ether 3a:c9:4c:0d:69:88 brd ff:ff:ff:ff:ff:ff > inet6 fe80::38c9:4cff:fe0d:6988/64 scope link > valid_lft forever preferred_lft forever > 10: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-wan state UP qlen 1000 > link/ether e8:94:f6:cd:46:36 brd ff:ff:ff:ff:ff:ff > 11: local-port@local-node: <BROADCAST,MULTICAST> mtu 1500 qdisc > noqueue state DOWN qlen 1000 > link/ether e8:94:f6:cd:46:38 brd ff:ff:ff:ff:ff:ff > 12: local-node@local-port: <NO-CARRIER,BROADCAST,MULTICAST,UP,M-DOWN> > mtu 1500 qdisc noqueue state LOWERLAYERDOWN qlen 1000 > link/ether 16:41:95:40:f7:dc brd ff:ff:ff:ff:ff:ff > inet6 fd74:fdaa:9dc4::127/128 scope global deprecated > valid_lft forever preferred_lft 0sec > inet6 fe80::1441:95ff:fe40:f7dc/64 scope link > valid_lft forever preferred_lft forever > 13: primary0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1532 qdisc noqueue > master bat0 state UNKNOWN qlen 1000 > link/ether 3a:c9:4c:0d:69:8b brd ff:ff:ff:ff:ff:ff > inet6 fe80::38c9:4cff:fe0d:698b/64 scope link > valid_lft forever preferred_lft forever > 14: bat0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue > state UNKNOWN qlen 1000 > link/ether e8:94:f6:cd:46:38 brd ff:ff:ff:ff:ff:ff > inet6 fe80::ea94:f6ff:fecd:4638/64 scope link > valid_lft forever preferred_lft forever > 2096: mesh-vpn: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1312 qdisc > fq_codel master bat0 state UNKNOWN qlen 1000 > link/ether 3a:c9:4c:0d:69:8f brd ff:ff:ff:ff:ff:ff > inet6 fe80::38c9:4cff:fe0d:698f/64 scope link > valid_lft forever preferred_lft forever > 2097: mesh1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc noqueue > master bat0 state UP qlen 1000 > link/ether 3a:c9:4c:0d:69:8d brd ff:ff:ff:ff:ff:ff > inet6 fe80::38c9:4cff:fe0d:698d/64 scope link > valid_lft forever preferred_lft forever > 2098: client1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-client state UP qlen 1000 > link/ether 3a:c9:4c:0d:69:8c brd ff:ff:ff:ff:ff:ff > inet6 fe80::38c9:4cff:fe0d:698c/64 scope link > valid_lft forever preferred_lft forever > 2099: mesh0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1532 qdisc noqueue > master bat0 state UP qlen 1000 > link/ether 3a:c9:4c:0d:69:89 brd ff:ff:ff:ff:ff:ff > inet6 fe80::38c9:4cff:fe0d:6989/64 scope link > valid_lft forever preferred_lft forever > 2100: client0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc > noqueue master br-client state UP qlen 1000 > link/ether e8:94:f6:cd:46:37 brd ff:ff:ff:ff:ff:ff > inet6 fe80::ea94:f6ff:fecd:4637/64 scope link > valid_lft forever preferred_lft forever > 1863: br-client: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state > DOWN qlen 1000 > link/ether 3a:c9:4c:0d:69:8c brd ff:ff:ff:ff:ff:ff

2 2

Bugs in Firmware - neues Update?
by Stefan Dunkel 13 Apr '18

13 Apr '18

Hi zusammen, heute im Laufe des Tages sind mehr als 300 Router verschwunden. Diese zeigen häufig im logread unregister_netdevice Fehler an. Erstaunlich finde ich das dies etwa 7 Tage nach dem Update bei allen Routern los geht. Teilweise reagieren diese noch auf ssh, teilweise nicht. @tarek: wie weit bist du mit dem bauen der neuen Firmware? VG Stefan Von meinem iPhone gesendet

1 0

Würgaround für UAP-AC-PRO
by Simon Kurka 11 Apr '18

11 Apr '18

Ich habe gerade ne Menge zu dem UniFi-AC sysupgrade Bug quergelesen und meine ein bisschen was verstanden zu haben. Vielleicht hilft es dem ein oder anderen: Die UniFi-AC Geräte setzen auf einen Flip-Flop-Flash. Daher kommen auch kernel0 und kernel1. Bei jeden Stock-Upgrade wird das Update in den inaktiven Flash geschrieben und beim Reboot der Flash gewechselt. Bei Fehlern wird der Flash einfach wieder zurück geflipt. Auf diese Weise wird immer eine funktionierende Firmware vorhanden. Die Auswahl wird über die bs-Partition getroffen. OpenWrt's sysupgrade macht (noch) keinen Gebrauch von dieser Methode, die ja auch stark geräteabhängig ist. Letztlich beschreibt das sysupgrade immer nur den kernel0 Part und liest von dort. Nun kann es den Fall geben (bspw): Neues Gerät wird mit neuer Firmware ohne mtd ausgeliefert [bs=0]. Es wird ein Downgrade auf eine Version mit mtd ausgeführt [Stock-(Up)grade -> bs=1]. Wir flashen auf kernel0 und kernel1 ein OpenWrt Image [bs=1]. Wir booten von kernel1. Alles läuft. Die Kernel-Module in beiden Partitionen sind kompatibel. sysupgrade! kernel0 wird beschrieben, kernel1 bleibt. Wir booten von kernel1. Kaputt. Kernel Module in kernel0 und kernel1 sind inkompatibel. Das Fallbeispiel basiert auf Vermutungen. Punkt ist, dass wohl alles gut ist, wenn unmittelbar vor dem flashen von OpenWrt [bs=0] ist. Es wird dann immer kernel0 beschrieben beim sysupgrade und auch von da gebootet. kernel1 gammelt einfach herum. Setzen kann man das mit folgendem Befehl: > dd if=/dev/zero bs=1 count=1 of=/dev/mtdN Wobei N die Partitionsnummer von bs ist. Die findet ihr mit folgendem Befehl: > cat /proc/mtd Vielleicht mag unser Herr und Meister der Shellscripte, Dr. lrnzo :-P, mal schauen, ob man das in einen Einzeiler verwursteln kann, der sowohl in der Stock-Firmware, als auch bei uns ausführbar ist? Wichtig ist allerdings beim ersten flashen trotzdem beide (kernel0 und kernel1) zu beschreiben, da der Bootloader(?) immer eine von Ubiquiti signierte Firmware bevorzugt startet. Dementsprechend müssen beide Flash-Speicher mit unsignierten Firmwares beschrieben werden. In OpenWrt wurde die bs-Parition beschreibbar gemacht [1], sodass man diesen Fix auch nachträglich anwenden kann. Ich weiß nicht, ob diese Änderung bei uns schon enthalten ist. Ansonsten hänge ich nochmal den Link zum OpenWrt Bugreport [2] und zum Bugreport in Gluon [3] an. [1] https://github.com/lede-project/source/commit/f17173f5a36999f070a2ccbde2953… [2] https://bugs.openwrt.org/index.php?do=details&task_id=662 [3] https://github.com/freifunk-gluon/gluon/issues/1301 -- Viele Grüße, Simon

3 9