Firmware 1.0

[gtpix (Ralf Singenstroth)]

rawhide kann ich nicht automatisch aktivieren.

[Thomas (Thomas Hollenbeck)]

Geht per SSH

[wusel (Kai 'wusel' Siering)]

Korrekt. Einmal per SSH drauf, /etc/config/autoupdater editieren, experimental-Eintrag kopieren und in rawhide ändern.

[Thomas (Thomas Hollenbeck)]

@wusel
kann es sein das map.4830.org keine aktuellen Daten mehr liefert seit dem mein kaputter Eintrag da drin war? Es verschwinden keine Knoten mehr und tauchen auch keine mehr auf.

[m.bitterlich (Matthias Bitterlich)]

Hi Wusel.

@wusel

Nachdem aber einige Zeit ins Land gegangen ist seit der Veröffentlichung der v2016.2 Anfang 2017 und nun der v2018.1, und das aktuelle »Gluon« bei manchen Geräten tiefgreifende Änderungen voraussetzt (Änderung der Partitionierung des Festspeichers bei manchen Geräten, Änderung der Partitionsgröße bei x86, …), haben wir uns entschlossen, einen harten Schnitt zu machen: es gibt unsererseits keinen Migrationspfad von unserer alten Firmware (0.7.x oder älter) und der kommenden Version 1.0.x.

Das bedeutet, ich brauche u.U. wieder eine Leiter um an die Knoten auf dem »Dach« zu kommen und noch einen mobilen Internet-Router für die Neu-Konfiguration dieser Knoten?
… oder ich stelle ›Autoupdate‹ aus.

Welche alten Funktionalitäten sind dann nicht mehr möglich?
Neues Gateway, Zeitserver, fastd/L2TP …?

Da meist die Wege hier lang sind und nur manuelles ›Upgrade‹ vorort geht , muss ich mir schon ein wenig über Migrationskonzepte Gedanken machen. Knoten nur mit WLAN-Mesh bekomme ich so nicht aus der Ferne auf Version 1.x - Oder liege ich da falsch.
Vorteil ist gezwungenermaßen: es gibt wieder Klasch und Tratsch, Kaffee und Kuchen umsonst.

Cul8er
Matthias

[wusel (Kai 'wusel' Siering)]

@m.bitterlich

Das bedeutet, ich brauche u.U. wieder eine Leiter um an die Knoten auf dem “Dach” zu kommen und noch einen mobilen Internet-Router für die Neu-Konfiguration dieser Knoten?

Bei den CPEs weiß ich ehrlich gesagt nicht, wie das laufen kann. Da wir aber sowieso ein »Separations-Update« machen müssen, kann es sein, daß wir da die Updates in Gluon-v2016.2, die als Vorbereitung für v2017/v2018 notwendig sind mit versenken und erst das Update ausrollen und erst danach 1.0. »Leider« haben wir auch ein paar CPE 210 im Netz …

841er müßtest Du

1. per SSH auf »next boot config-mode« konfigurieren (/etc/config/gluon-setup-mode, dort IIRC »config-mode« auf 1 (statt 0) setzen), rebooten.

2. Per setup.4830.org finden (müßtest wohl vor Ort im gleichen LAN sein …) und 1.0er FW per Web-UI einspielen.

Alternativ: per SSH dauf gehen, 1.0er FW per wget nach /tmp holen, dann sysupgrade -v /tmp/gluon-4830 und gut.

Im Grunde wollen wir im Kreis GT die 841 »rausphasen«; für Müritz (bei Feldberg stellt sich die Frage nicht ;)) könnten wir’s auch drin lassen, dann müßten wir halt »endlich« auf Basis des anfragenden Knotens unterschiedliche Images/Manifeste senden.

Die Erfordernis des händischen Updates soll im Kreis GT dazu führen, daß wir mit den »full-service« Knotenbetreibern (also insbes. Kneipen u. dgl., die den Knoten damals hingestellt und installiert bekommen haben und von denen wir keine Kontaktadressen haben — die hinterlegte Adresse ist die des damaligen Aufstellers, das nutzt nur leider nichts, da er sich aus FFGT zurückgezogen hat). Wir haben leider doch viele Knoten, um die sich nicht wirklich gekümmert wird, die überlastet sind oder wo die Anbindung suboptimal ist. Lange, traurige Geschichten

Welche alten Funktionalitäten sind dann nicht mehr möglich?
Neues Gateway, Zeitserver, fastd/L2TP …?

Für Müritz ändert sich »nur« fastd → L2TP. Sprich anderes GW. Im Kreis GT wollen (müssen) wir endlich das eine Mesh in 4 kleinere splitten.

Wie gesagt, für den Kreis GT ist der Plan der besagte; für Müritz können wir gerne anders verfahren, Ihr habt ein paar der Geburtsfehler, die wir mitgenommen haben, ja ausgelassen

[wusel (Kai 'wusel' Siering)]

Das kann gut sein, ich wunderte mich auch, daß ein reanimierter Test-Knoten nicht auftauchte; da bestehende Knoten aber ihre Position durchaus veränderten, habe ich dem weiter keine Beachtung geschenkt. Muß ich mir die Tage mal angucken …

Gruß aus Unterfranken

[wusel (Kai 'wusel' Siering)]

Garbage in, garbage out

Traceback (most recent call last):
  File "./backend.py", line 185, in <module>
    main(options)
  File "./backend.py", line 62, in main
    nodedb = json.load(nodedb_handle)
  File "/usr/lib/python3.4/json/__init__.py", line 265, in load
    return loads(fp.read(),
  File "/usr/lib/python3.4/codecs.py", line 319, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 716780: invalid continuation byte

FTR:

ffgt@map:~/ffmap-d3/build/tng$ json_pp <nodes.json >nodes.json-20180802_
ffgt@map:~/ffmap-d3/build/tng$ mv nodes.json-20180802_ nodes.json
ffgt@map:~/ffmap-d3/build/tng$ (cd /home/ffgt/ffmap-backend-20151114/ ; PATH=$HOME:$PATH ./backend.py -a aliases.json -d /home/ffgt/ffmap-d3/build/tng/ --prune 14 --vpn de:ad:be:ef:02:01 de:ad:be:ef:02:02 de:ad:be:ef:02:03 de:ad:be:ef:02:04 1e:ed:36:27:3a:0c 52:31:bd:f2:70:1f da:eb:ac:11:27:8a 66:c0:c3:26:10:53) ; echo $?
Traceback (most recent call last):
  File "./backend.py", line 185, in <module>
    main(options)
  File "./backend.py", line 62, in main
    nodedb = json.load(nodedb_handle)
  File "/usr/lib/python3.4/json/__init__.py", line 265, in load
    return loads(fp.read(),
  File "/usr/lib/python3.4/codecs.py", line 319, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe4 in position 104981: invalid continuation byte
1
ffgt@map:~/ffmap-d3/build/tng$ dd if=nodes.json bs=1 skip=104500 count=1000 | more
1000+0 records in
1000+0 records out
1000 bytes (1.0 kB) copied, 0.00121537 s, 823 kB/s
[…] "contact" : "freifunk (�t) […]
ffgt@map:~/ffmap-d3/build/tng$ vi nodes.json
ffgt@map:~/ffmap-d3/build/tng$ (cd /home/ffgt/ffmap-backend-20151114/ ; PATH=$HOME:$PATH ./backend.py -a aliases.json -d /home/ffgt/ffmap-d3/build/tng/ --prune 14 --vpn de:ad:be:ef:02:01 de:ad:be:ef:02:02 de:ad:be:ef:02:03 de:ad:be:ef:02:04 1e:ed:36:27:3a:0c 52:31:bd:f2:70:1f da:eb:ac:11:27:8a 66:c0:c3:26:10:53) ; echo $?
0

Es hat jemand wohl ein Sonderzeichen im Kontaktfeld eingegeben, keine Ahnung, in welchem Zeichensatz. Aus dem vermeintlichen ‘ä’ wird dann irgendwie ein 3-Byte-Code, der letztlich kein UTF-8 ist, was aber erwartet wird. Yeah

Wird wohl auf ein “asciify” des Kontakfelds hinauslaufen, um sowas zu verhindern …

[m.bitterlich (Matthias Bitterlich)]

Bei meinem 1043ND v2.0 taucht folgende Meldung nach VPN-Aufbau auf.
Was sollte gesendet werden?

Fri Jun 8 21:50:02 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted

Das vorhandene Logfile

Fri Jun  8 21:49:43 2018 user.notice : Added device handler type: bridge
Fri Jun  8 21:49:43 2018 user.notice : Added device handler type: Network device
Fri Jun  8 21:49:43 2018 user.notice : Added device handler type: tunnel
Fri Jun  8 21:49:44 2018 authpriv.info dropbear[1151]: Not backgrounding
Fri Jun  8 21:49:45 2018 daemon.warn netifd: You have delegated IPv6-prefixes but haven't assigned them to any interface. Did you forget to set option ip6assign on your lan-interfaces?
Fri Jun  8 21:49:45 2018 kern.info kernel: [   35.460507] device eth0 entered promiscuous mode
Fri Jun  8 21:49:45 2018 kern.info kernel: [   35.479259] br-wan: port 1(eth0) entered forwarding state
Fri Jun  8 21:49:45 2018 kern.info kernel: [   35.484768] br-wan: port 1(eth0) entered forwarding state
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'wan6' is enabled
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'wan' is enabled
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'mesh_wan' is enabled
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'local_node' is enabled
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'local_node' is setting up now
Fri Jun  8 21:49:45 2018 kern.info kernel: [   35.577997] IPv6: ADDRCONF(NETDEV_UP): local-node: link is not ready
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'local_node' is now up
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'gluon_bat0' is setting up now
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'loopback' is enabled
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'loopback' is setting up now
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'loopback' is now up
Fri Jun  8 21:49:45 2018 kern.info kernel: [   35.647699] eth1: link up (1000Mbps/Full duplex)
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'mesh_lan' is enabled
Fri Jun  8 21:49:45 2018 kern.info kernel: [   35.735215] IPv6: ADDRCONF(NETDEV_UP): br-client: link is not ready
Fri Jun  8 21:49:45 2018 daemon.notice netifd: Interface 'client' is enabled
Fri Jun  8 21:49:46 2018 kern.info kernel: [   35.929027] device local-port entered promiscuous mode
Fri Jun  8 21:49:46 2018 kern.info kernel: [   35.968611] br-client: port 1(local-port) entered forwarding state
Fri Jun  8 21:49:46 2018 kern.info kernel: [   35.974929] br-client: port 1(local-port) entered forwarding state
Fri Jun  8 21:49:46 2018 kern.info kernel: [   35.985867] IPv6: ADDRCONF(NETDEV_CHANGE): br-client: link becomes ready
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.006534] IPv6: ADDRCONF(NETDEV_CHANGE): local-node: link becomes ready
Fri Jun  8 21:49:46 2018 daemon.notice netifd: bridge 'br-wan' link is up
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'wan6' has link connectivity
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'wan6' is setting up now
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'wan' has link connectivity
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'wan' is setting up now
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'mesh_wan' has link connectivity
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'mesh_wan' is setting up now
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Network device 'local-port' link is up
Fri Jun  8 21:49:46 2018 daemon.notice netifd: veth 'local-node' link is up
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'local_node' has link connectivity
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Network device 'lo' link is up
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'loopback' has link connectivity
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Network device 'eth1' link is up
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'mesh_lan' has link connectivity
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'mesh_lan' is setting up now
Fri Jun  8 21:49:46 2018 daemon.notice netifd: bridge 'br-client' link is up
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'client' has link connectivity
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'client' is setting up now
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.434595] batman_adv: bat0: Adding interface: primary0
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.440055] batman_adv: bat0: Interface activated: primary0
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'bat0' is enabled
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.451288] device bat0 entered promiscuous mode
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.456036] br-client: port 2(bat0) entered forwarding state
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.461848] br-client: port 2(bat0) entered forwarding state
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.467901] br-wan: port 1(eth0) entered disabled state
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Network device 'bat0' link is up
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'bat0' has link connectivity
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'bat0' is setting up now
Fri Jun  8 21:49:46 2018 daemon.notice netifd: Interface 'bat0' is now up
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.771486] batman_adv: bat0: Interface deactivated: primary0
Fri Jun  8 21:49:46 2018 kern.info kernel: [   36.830225] IPv6: ADDRCONF(NETDEV_UP): primary0: link is not ready
Fri Jun  8 21:49:47 2018 kern.info kernel: [   36.915229] batman_adv: bat0: Interface activated: primary0
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'gluon_bat0' is now up
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_wan' is now up
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Network device 'primary0' link is up
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_lan' is now up
Fri Jun  8 21:49:47 2018 daemon.notice netifd: wan (1371): udhcpc: started, v1.25.1
Fri Jun  8 21:49:47 2018 daemon.notice netifd: bridge 'br-wan' link is down
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'wan' has link connectivity loss
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_wan' has link connectivity loss
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Network alias 'eth1' link is up
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_lan_mesh' is enabled
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_lan_mesh' has link connectivity
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_lan_mesh' is setting up now
Fri Jun  8 21:49:47 2018 daemon.notice netifd: mesh_lan (1285): Command failed: Unknown error
Fri Jun  8 21:49:47 2018 kern.info kernel: [   37.357724] eth0: link up (1000Mbps/Full duplex)
Fri Jun  8 21:49:47 2018 kern.info kernel: [   37.406315] br-wan: port 1(eth0) entered forwarding state
Fri Jun  8 21:49:47 2018 kern.info kernel: [   37.411865] br-wan: port 1(eth0) entered forwarding state
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Network device 'eth0' link is up
Fri Jun  8 21:49:47 2018 user.notice sysctl: net.ipv6.conf.local-node.forwarding = 0
Fri Jun  8 21:49:47 2018 user.notice firewall: Reloading firewall due to ifup of local_node (local-node)
Fri Jun  8 21:49:47 2018 daemon.notice netifd: bridge 'br-wan' link is up
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'wan6' has link connectivity
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'wan6' is setting up now
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'wan' has link connectivity
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'wan' is setting up now
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_wan' has link connectivity
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_wan' is setting up now
Fri Jun  8 21:49:47 2018 kern.debug kernel: [   37.573647] ath: EEPROM regdomain: 0x8114
Fri Jun  8 21:49:47 2018 kern.debug kernel: [   37.573665] ath: EEPROM indicates we should expect a country code
Fri Jun  8 21:49:47 2018 kern.debug kernel: [   37.573674] ath: doing EEPROM country->regdmn map search
Fri Jun  8 21:49:47 2018 kern.debug kernel: [   37.573683] ath: country maps to regdmn code: 0x37
Fri Jun  8 21:49:47 2018 kern.debug kernel: [   37.573693] ath: Country alpha2 being used: DE
Fri Jun  8 21:49:47 2018 kern.debug kernel: [   37.573701] ath: Regpair used: 0x37
Fri Jun  8 21:49:47 2018 kern.debug kernel: [   37.573711] ath: regdomain 0x8114 dynamically updated by user
Fri Jun  8 21:49:47 2018 daemon.notice netifd: mesh_wan (1392): Command failed: Permission denied
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_wan' is now down
Fri Jun  8 21:49:47 2018 daemon.notice netifd: Interface 'mesh_wan' is setting up now
Fri Jun  8 21:49:48 2018 kern.info kernel: [   37.966260] br-client: port 1(local-port) entered forwarding state
Fri Jun  8 21:49:48 2018 user.notice sysctl: net.ipv6.conf.br-client.forwarding = 0
Fri Jun  8 21:49:48 2018 daemon.notice netifd: Interface 'wan6' is now down
Fri Jun  8 21:49:48 2018 daemon.notice netifd: Interface 'wan6' is setting up now
Fri Jun  8 21:49:48 2018 kern.info kernel: [   38.456264] br-client: port 2(bat0) entered forwarding state
Fri Jun  8 21:49:48 2018 daemon.notice netifd: Interface 'mesh_lan_mesh' is now up
Fri Jun  8 21:49:48 2018 daemon.notice netifd: Interface 'mesh_wan_mesh' is enabled
Fri Jun  8 21:49:48 2018 daemon.notice netifd: Network alias 'br-wan' link is up
Fri Jun  8 21:49:48 2018 daemon.notice netifd: Interface 'mesh_wan_mesh' has link connectivity
Fri Jun  8 21:49:48 2018 daemon.notice netifd: Interface 'mesh_wan_mesh' is setting up now
Fri Jun  8 21:49:48 2018 daemon.notice netifd: Interface 'mesh_wan' is now up
Fri Jun  8 21:49:48 2018 daemon.notice netifd: mesh_wan (1462): Command failed: Unknown error
Fri Jun  8 21:49:49 2018 daemon.notice netifd: Interface 'wan' is now down
Fri Jun  8 21:49:49 2018 daemon.notice netifd: Interface 'wan' is setting up now
Fri Jun  8 21:49:49 2018 kern.info kernel: [   39.406279] br-wan: port 1(eth0) entered forwarding state
Fri Jun  8 21:49:49 2018 daemon.notice netifd: Interface 'mesh_wan_mesh' is now up
Fri Jun  8 21:49:49 2018 daemon.notice netifd: wan (1633): udhcpc: started, v1.25.1
Fri Jun  8 21:49:49 2018 kern.info kernel: [   39.828679] batman_adv: bat0: Adding interface: eth1
Fri Jun  8 21:49:49 2018 kern.info kernel: [   39.833732] batman_adv: bat0: The MTU of interface eth1 is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1528 would solve the problem.
Fri Jun  8 21:49:49 2018 kern.info kernel: [   39.858002] batman_adv: bat0: Interface activated: eth1
Fri Jun  8 21:49:50 2018 kern.info kernel: [   39.976951] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
Fri Jun  8 21:49:50 2018 kern.info kernel: [   40.076950] batman_adv: (null): no_rebroadcast: Changing from: disabled to: enabled
Fri Jun  8 21:49:50 2018 kern.info kernel: [   40.226587] batman_adv: bat0: Adding interface: br-wan
Fri Jun  8 21:49:50 2018 kern.info kernel: [   40.231817] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1528 would solve the problem.
Fri Jun  8 21:49:50 2018 kern.info kernel: [   40.256257] batman_adv: bat0: Interface activated: br-wan
Fri Jun  8 21:49:50 2018 daemon.notice netifd: wan (1633): udhcpc: sending discover
Fri Jun  8 21:49:50 2018 daemon.notice netifd: wan (1633): udhcpc: sending select for 192.168.2.104
Fri Jun  8 21:49:50 2018 kern.info kernel: [   40.495859] batman_adv: bat0: Changing gw mode from: off to: client
Fri Jun  8 21:49:50 2018 daemon.notice netifd: wan (1633): udhcpc: lease of 192.168.2.104 obtained, lease time 1814400
Fri Jun  8 21:49:50 2018 kern.info kernel: [   40.749731] batman_adv: bat0: hop_penalty: Changing from: 30 to: 15
Fri Jun  8 21:49:50 2018 kern.info kernel: [   40.798759] batman_adv: bat0: orig_interval: Changing from: 1000 to: 5000
Fri Jun  8 21:49:51 2018 daemon.notice netifd: Interface 'wan' is now up
Fri Jun  8 21:49:51 2018 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Fri Jun  8 21:49:51 2018 kern.info kernel: [   41.516382] IPv6: ADDRCONF(NETDEV_UP): client0: link is not ready
Fri Jun  8 21:49:51 2018 kern.info kernel: [   41.681376] device client0 entered promiscuous mode
Fri Jun  8 21:49:51 2018 daemon.notice hostapd: client0: interface state UNINITIALIZED->COUNTRY_UPDATE
Fri Jun  8 21:49:51 2018 daemon.err hostapd: Using interface client0 with hwaddr e6:24:a9:c6:60:00 and ssid "mueritz.freifunk.net"
Fri Jun  8 21:49:52 2018 kern.info kernel: [   41.913360] IPv6: ADDRCONF(NETDEV_CHANGE): client0: link becomes ready
Fri Jun  8 21:49:52 2018 kern.info kernel: [   41.920168] br-client: port 3(client0) entered forwarding state
Fri Jun  8 21:49:52 2018 kern.info kernel: [   41.926284] br-client: port 3(client0) entered forwarding state
Fri Jun  8 21:49:52 2018 daemon.notice hostapd: client0: interface state COUNTRY_UPDATE->ENABLED
Fri Jun  8 21:49:52 2018 daemon.notice hostapd: client0: AP-ENABLED
Fri Jun  8 21:49:52 2018 kern.info kernel: [   42.221437] IPv6: ADDRCONF(NETDEV_UP): ibss0: link is not ready
Fri Jun  8 21:49:52 2018 kern.info kernel: [   42.317651] ibss0: Created IBSS using preconfigured BSSID 00:23:de:ca:fb:ad
Fri Jun  8 21:49:52 2018 kern.info kernel: [   42.324743] ibss0: Creating new IBSS network, BSSID 00:23:de:ca:fb:ad
Fri Jun  8 21:49:52 2018 kern.info kernel: [   42.332801] IPv6: ADDRCONF(NETDEV_CHANGE): ibss0: link becomes ready
Fri Jun  8 21:49:52 2018 daemon.notice netifd: Network device 'ibss0' link is up
Fri Jun  8 21:49:52 2018 daemon.notice netifd: Interface 'ibss_radio0' is enabled
Fri Jun  8 21:49:52 2018 daemon.notice netifd: Interface 'ibss_radio0' has link connectivity
Fri Jun  8 21:49:52 2018 daemon.notice netifd: Interface 'ibss_radio0' is setting up now
Fri Jun  8 21:49:52 2018 daemon.notice netifd: Network device 'client0' link is up
Fri Jun  8 21:49:52 2018 daemon.notice netifd: Interface 'wan6' is now up
Fri Jun  8 21:49:53 2018 daemon.notice netifd: ibss_radio0 (1915): ip: SIOCSIFMTU: No such device
Fri Jun  8 21:49:53 2018 daemon.notice netifd: Interface 'ibss_radio0' is now up
Fri Jun  8 21:49:53 2018 daemon.info dnsmasq[1972]: started, version 2.78 cachesize 150
Fri Jun  8 21:49:53 2018 daemon.info dnsmasq[1972]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Fri Jun  8 21:49:53 2018 daemon.info dnsmasq[1972]: reading /var/gluon/wan-dnsmasq/resolv.conf
Fri Jun  8 21:49:53 2018 daemon.info dnsmasq[1972]: using nameserver 192.168.2.1#53
Fri Jun  8 21:49:53 2018 daemon.info dnsmasq[1972]: cleared cache
Fri Jun  8 21:49:53 2018 kern.info kernel: [   43.706164] batman_adv: bat0: Adding interface: ibss0
Fri Jun  8 21:49:53 2018 kern.info kernel: [   43.711371] batman_adv: bat0: Interface activated: ibss0
Fri Jun  8 21:49:53 2018 kern.notice kernel: [   43.771126] random: nonblocking pool is initialized
Fri Jun  8 21:49:54 2018 kern.info kernel: [   43.926288] br-client: port 3(client0) entered forwarding state
Fri Jun  8 21:49:54 2018 user.notice firewall: Reloading firewall due to ifup of mesh_lan (eth1)
Fri Jun  8 21:49:55 2018 daemon.notice fastd[2124]: fastd v18 starting
Fri Jun  8 21:49:55 2018 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Fri Jun  8 21:49:55 2018 daemon.notice netifd: Network device 'mesh-vpn' link is up
Fri Jun  8 21:49:55 2018 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity
Fri Jun  8 21:49:55 2018 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Fri Jun  8 21:49:55 2018 daemon.notice fastd[2124]: changed to UID 0, GID 800
Fri Jun  8 21:49:55 2018 daemon.info fastd[2124]: adding peer <mesh_vpn_backbone_peer_gw06>
Fri Jun  8 21:49:55 2018 user.notice firewall: Reloading firewall due to ifup of mesh_lan_mesh (eth1)
Fri Jun  8 21:49:55 2018 daemon.info fastd[2124]: adding peer <mesh_vpn_backbone_peer_gw05>
Fri Jun  8 21:49:55 2018 daemon.info fastd[2124]: resolving host `gw05.4830.org' for peer <mesh_vpn_backbone_peer_gw05>...
Fri Jun  8 21:49:55 2018 daemon.info fastd[2124]: resolving host `gw06.4830.org' for peer <mesh_vpn_backbone_peer_gw06>...
Fri Jun  8 21:49:55 2018 daemon.info fastd[2124]: resolved host `gw06.4830.org' successfully
Fri Jun  8 21:49:55 2018 daemon.info fastd[2124]: resolved host `gw05.4830.org' successfully
Fri Jun  8 21:49:55 2018 daemon.notice procd: /etc/rc.d/S96led: setting up led USB
Fri Jun  8 21:49:55 2018 daemon.notice procd: /etc/rc.d/S96led: setting up led WLAN
Fri Jun  8 21:49:55 2018 daemon.notice netifd: Interface 'mesh_vpn' is now up
Fri Jun  8 21:49:56 2018 kern.info kernel: [   46.348813] batman_adv: bat0: Adding interface: mesh-vpn
Fri Jun  8 21:49:56 2018 kern.info kernel: [   46.354235] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1406) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1528 would solve the problem.
Fri Jun  8 21:49:56 2018 kern.info kernel: [   46.378852] batman_adv: bat0: Interface activated: mesh-vpn
Fri Jun  8 21:49:56 2018 kern.info kernel: [   46.421802] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
Fri Jun  8 21:49:57 2018 daemon.info fastd[2124]: sending handshake to <mesh_vpn_backbone_peer_gw06>[192.251.226.99:10169]...
Fri Jun  8 21:49:57 2018 user.notice firewall: Reloading firewall due to ifup of wan (br-wan)
Fri Jun  8 21:49:57 2018 daemon.notice procd: /etc/rc.d/S99alfred: /etc/rc.d/S99alfred: waiting 30 secs for br-client address...
Fri Jun  8 21:49:57 2018 daemon.notice procd: /etc/rc.d/S99alfred: /etc/rc.d/S99alfred: starting alfred
Fri Jun  8 21:49:57 2018 daemon.notice procd: /etc/rc.d/S99alfred: /etc/rc.d/S99alfred: starting batadv-vis
Fri Jun  8 21:49:58 2018 daemon.info fastd[2124]: sending handshake to <mesh_vpn_backbone_peer_gw05>[192.251.226.66:10169]...
Fri Jun  8 21:49:58 2018 daemon.info fastd[2124]: received handshake response from <mesh_vpn_backbone_peer_gw05>[192.251.226.66:10169] using fastd v17
Fri Jun  8 21:49:58 2018 daemon.info dnsmasq[2367]: started, version 2.78 cachesize 150
Fri Jun  8 21:49:58 2018 daemon.info procd: - init complete -
Fri Jun  8 21:49:58 2018 daemon.info dnsmasq[2367]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Fri Jun  8 21:49:58 2018 daemon.info dnsmasq[2367]: using local addresses only for domain lan
Fri Jun  8 21:49:58 2018 daemon.warn dnsmasq[2367]: no servers found in /tmp/resolv.conf.auto, will retry
Fri Jun  8 21:49:58 2018 daemon.info dnsmasq[2367]: read /etc/hosts - 4 addresses
Fri Jun  8 21:49:58 2018 daemon.info dnsmasq[2367]: read /tmp/hosts/dhcp.cfg02411c - 0 addresses
Fri Jun  8 21:49:58 2018 daemon.info dnsmasq[1972]: reading /var/gluon/wan-dnsmasq/resolv.conf
Fri Jun  8 21:49:58 2018 daemon.info dnsmasq[1972]: using nameserver fe80::1%br-wan#53
Fri Jun  8 21:49:58 2018 daemon.info dnsmasq[1972]: using nameserver 192.168.2.1#53
Fri Jun  8 21:49:59 2018 daemon.info fastd[2124]: 192.251.226.66:10169 authorized as <mesh_vpn_backbone_peer_gw05>
Fri Jun  8 21:49:59 2018 daemon.notice fastd[2124]: connection with <mesh_vpn_backbone_peer_gw05> established.
Fri Jun  8 21:49:59 2018 daemon.info fastd[2124]: new session with <mesh_vpn_backbone_peer_gw05> established using method `salsa2012+umac'.
Fri Jun  8 21:49:59 2018 user.notice firewall: Reloading firewall due to ifup of wan6 (br-wan)
Fri Jun  8 21:49:59 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted
Fri Jun  8 21:49:59 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted
Fri Jun  8 21:49:59 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted
Fri Jun  8 21:49:59 2018 daemon.info urandom_seed[2370]: Seed saved (/etc/urandom.seed)
Fri Jun  8 21:50:00 2018 user.notice firewall: Reloading firewall due to ifup of ibss_radio0 (ibss0)
Fri Jun  8 21:50:01 2018 user.notice firewall: Reloading firewall due to ifup of mesh_vpn (mesh-vpn)
Fri Jun  8 21:50:01 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted
Fri Jun  8 21:50:01 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted
Fri Jun  8 21:50:01 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted
Fri Jun  8 21:50:01 2018 daemon.notice netifd: Interface 'client' is now up
Fri Jun  8 21:50:02 2018 user.notice firewall: Reloading firewall due to ifup of client (br-client)
Fri Jun  8 21:50:02 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted
Fri Jun  8 21:50:02 2018 daemon.warn fastd[2124]: sendmsg: Operation not permitted
Fri Jun  8 21:50:26 2018 daemon.info dnsmasq[2367]: reading /tmp/resolv.conf.auto
Fri Jun  8 21:50:26 2018 daemon.info dnsmasq[2367]: using local addresses only for domain lan
Fri Jun  8 21:50:26 2018 daemon.info dnsmasq[2367]: using nameserver fd39:e4e3:eee1::5#53
Fri Jun  8 21:50:26 2018 daemon.info dnsmasq[2367]: using nameserver 2620:0:ccc::2#53
Fri Jun  8 21:50:27 2018 user.notice firewall: Reloading firewall due to ifupdate of client (br-client)

[wusel (Kai 'wusel' Siering)]

@m.bitterlich

Was sollte gesendet werden?

Daten? Keinen blassen Schimmer; allerdings ist das eingebettet in »reloading firewall«-Meldungen, besteht da ein Zusammenhang? Wobei, da sollte das Paket dran abprallen und nicht zu einer Kernel-Meldung führen. Ist das eine neue Meldung, trat diese in vorigen 0.7er und 1.0er Versionen nicht auf?

[m.bitterlich (Matthias Bitterlich)]

Mir ist das erst jetzt mit der 1.0~73 aufgefallen.
Diese Version scheint auch nicht richtig in den Konfig-Modus nach einem Sysupgrad von 0.7.9 (CPE210v1.0) zu kommen … cgi-bin-Fehler - ~72 ging ohne Probleme.

[wusel (Kai 'wusel' Siering)]

@m.bitterlich

1.0.0~73 … scheint auch nicht richtig in den Konfig-Modus nach einem Sysupgrad von 0.7.9 (CPE210v1.0) zu kommen … cgi-bin-Fehler - ~72 ging ohne Probleme.

Hmm, ich glaube, ich muß da was zitieren

@http://firmware.4830.org

Von der Verwendung der Rawhide-Firmware wird ganz aus­drück­lich abgeraten, diese ist latent buggy und wirk­lich nur der erste Wurf für in­ter­ne Tests … Raw­hide-Images wer­den au­to­ma­tisch nach Co­de­än­der­ungen er­zeugt und hoch­ge­laden, sie sind nicht vor­her ge­testet wor­den!

Einerseits finde ich es ja cool, daß Ihr fleißig Euch auf rawhide stürzt — aber das ist latent kontraproduktiv, denn so manche Version davon schmeißt Fehler. Erst wenn rawhide soweit lokal gestetet wurde, daß ich glaube, daß da keine groben Krabbelkäferinfekte mitkommen, schiebe ich das normalerweise nach experimental und eigentlich beginnt dann erst das Betasten, äh, Beta-testen.

Bzgl. CPE, Du hast dies gelesen?

@http://gluon.readthedocs.io/en/v2018.1.x/releases/v2018.1.html#important-notes

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.

=> Wie hast Du die CPE auf 1.0.0~73 gebracht? Lt. Doku führt Upgrade von 0.7.9 (Gluon v2016.2.4-basiert) auf 1.0.0~* (Gluon v2018.1.1-pre-basiert) zum Brick?

[wusel (Kai 'wusel' Siering)]

FTR, eine generisches Gluon v2018.1-Problem ist aufgetaucht (sigh warum sollte auch diese Version verschont bleiben?):

Gluon 2018.1.x Autoupdater Configverlust-Gefahr

Das Problem ist leider real

[gtpix (Ralf Singenstroth)]

Ja, habe ich auch schon gelesen.

…”Wenn ihr derzeit plant, eine 2018.1.x auszurollen, dann stellt das ggf. noch zurück, es halt den Autoupdater betrifft, der aktiv wird, wenn dann das darauf folgende Update ansteht…"

[m.bitterlich (Matthias Bitterlich)]

@wusel

=> Wie hast Du die CPE auf 1.0.0~73 gebracht? Lt. Doku führt Upgrade von 0.7.9 (Gluon v2016.2.4-basiert) auf 1.0.0~* (Gluon v2018.1.1-pre-basiert) zum Brick?

Entweder über die Konfig-Seite oder über SSH – beides ohne Speichern der Einstellungen.
Mit 1.0.0~72 ging es gut durch bis zur Konfiguration und danach per SSH mit sysupgrade auf 1.0.0~73 weiter.
Nur direkt zur 1.0.0~73 ging es nicht.

Im Fehlerfalle kam das Gerät im Konfig-Modus per SSH mit einem Downgrade klar.

Und JA ich hab den ›Disclamer‹ gelesen.
Deshalb mach ich das mit meinen Geräten vorort und mit den CPEs, da die hier auch in Zukunft wichtig sind.
Die Version 1.0.0~76 funktioniert jetzt wieder besser …

[m.bitterlich (Matthias Bitterlich)]

Was mir heute noch aufgefallen ist: Wie ist es mit dem Beibehalten der MAC-Adresse auf den Knoten bei Upgrades z.B. bei restriktiven Firewalls?
Der Schalter im Konfigurationsmenü ist weg …

[wusel (Kai 'wusel' Siering)]

@m.bitterlich

Wie ist es mit dem Beibehalten der MAC-Adresse auf den Knoten bei Upgrades z.B. bei restriktiven Firewalls?
Der Schalter im Konfigurationsmenü ist weg …

Die Einstellung wird übernommen …

ffgtso/ffgt_packages-v2018.1/blob/master/ffgt-setup-mode/files/lib/gluon/upgrade/001-aaaearly-save-wan-mac.sh

… aber bislang nicht weiter benutzt. Soweit ich das überblicken kann, sollte die MAC-Bastelei durch sein, sprich diese Einstellungen stabil. Aber den Bereich muß ich mir noch angucken; das Save-MAC-Feature würde ich aber auslaufen lassen wollen, d. h. nur noch von alten Systemen die MAC übernehmen, aber dies nicht mehr neu setzbar machen — AFAICS hat sich da in v2017 und v2018 nichs mehr geändert, d. h. mit neu installierten Knoten sollte das Problem weg sein.

[wusel (Kai 'wusel' Siering)]

Regen, Traufe — deshalb steige ich mit .1 i. d. R. erst ein, wenn .2 draußen ist Anyway: ich habe die Patches nachgezogen, die das Autoupdater-Issue fixen — und prompt haben wir die nächste Beulenpest an der Haxe

v2018.1.x: g0cb9888: x86 images may corrupt ext-fs

Achtung, in 1.0.0~78 ist dann also x86-64/AMD64 defekt Upstream ist man bei OpenWRT im Bilde (und hatte das gleiche Problem mit OpenWRT 18.06), hoffe auf kurzfristigen Fix …

1.0.0~79 hat wieder Kernel 4.4.139 statt 4.4.140 und sollte safe sein; leider sind damit auch die autoupdater-Fixes nicht mehr drin …

[wusel (Kai 'wusel' Siering)]

1.0.0~85 und folgende sollten einerseits wieder auf x86 laufen (extX fixed) und andererseits auch den sysupgrade-Bug nicht mehr haben. Wir sind damit auf »Gluon v2018.1 plus 12 Commits«

1.0.0~86 sollte weitgehend (lies: vollständig) im Config-Mode funktionieren, also ab dafür!

[wusel (Kai 'wusel' Siering)]

Moin Folks,

auf die 1.0.0~90 bitte ich Euch zu stürzen, da sollte soweit erstmal alles drin sein (»Nachtruhe«-Patch gucke ich noch nach). Zwei know Issues: Bei Neuinstallation geht’s nach der ersten Positionierung mit Fehlermeldung zurück, die Koordinaten wären irgendwie nicht in Ordnung, ferner fehlen die Fehlermeldungen bei der Kontaktangabe, warum die eingegebene Adresse zurückgewiesen wid …