Firmware 1.0

wusel · 4. August 2018 um 22:22

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

per SSH auf “next boot config-mode” konfigurieren (/etc/config/gluon-setup-mode, dort IIRC “config-mode” auf 1 (statt 0) setzen), rebooten.
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

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 · 4. August 2018 um 22:28

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 · 5. August 2018 um 08:40

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 · 5. August 2018 um 20:01

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 · 5. August 2018 um 22:02

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 · 5. August 2018 um 22:26

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 · 5. August 2018 um 22:57

Hmm, ich glaube, ich muß da was zitieren

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?

=> 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 · 6. August 2018 um 02:48

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

Das Problem ist leider real

gtpix · 6. August 2018 um 06:10

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 · 6. August 2018 um 07:56

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 · 6. August 2018 um 21:09

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 · 6. August 2018 um 23:04

Die Einstellung wird übernommen …

github.com

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

#!/bin/sh

( WANMAC="`uci get network.wan.macaddr`" ; \
 if [ ! -z "${WANMAC}" ]; then \
  uci get system.@system[0].staticwanmac || uci set system.@system[0].staticwanmac="${WANMAC}" ;\
  uci commit ;\
 fi ) >/dev/null 2>&1

… 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 · 7. August 2018 um 21:30

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

github.com/freifunk-gluon/gluon

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

opened 09:23PM - 07 Aug 18 UTC

closed 10:10PM - 09 Aug 18 UTC

Adorfer

0. type: bug

since https://github.com/freifunk-gluon/gluon/commit/0cb98882d05924878775196fcdf…a600c3d846215 (this is kernel 4.4.140) it looks that all images on x86/x64 (img.gz/kvm/vmdk) suffer from corrupt fs after 2nd or 3rd reboot. Kernel is stuck during mount on fs-check at about 4s in... sometimes after about 340 seconds anothter short message that stuff is really damaged. can be reproduced on multiple builds. On v2018.1-8 it was working fine. there are systems affected "running sysupgrade" and systems "fresh install from img.gz".

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 · 11. August 2018 um 02:11

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 · 13. August 2018 um 15:36

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 …

gtpix · 13. August 2018 um 17:15

Wie sieht es bei den TP-Link CPE210 v1.0 aus? Rawhide Aufspielung jetzt über sysupgrade möglich?

gtpix · 13. August 2018 um 17:22

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.

wusel · 13. August 2018 um 17:30

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 …

gtpix · 13. August 2018 um 19:46

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.

Thomas · 14. August 2018 um 19:02

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.