Gluon v2018.1 veröffentlicht

rotanid · 8. Juli 2018 um 20:22

Gerade wurde nach einem Jahr Entwicklung, hauptsächlich durch @anon75826926 aber mit immer mehr Helfern, die neue Gluon-Version 2018.1 veröffentlicht.
Release Tag: Release v2018.1 · freifunk-gluon/gluon · GitHub
Release Notes: Gluon 2018.1 — Gluon 2018.1.4 documentation
Dies ist das zweite (und letzte) Major-Release basierend auf LEDE 17.01.x.
Das Gluon-Team betrachtet dieses Release in ausnahmslos jeder Hinsicht als besser als die Releases des Branches v2017.1.x an. Deswegen sind auch Upgrades vom Branch v2016.2.x unterstützt und empfohlen, sprich das v2017.1.x überspringend. Hierzu muss man aber den aktuellen Stand von v2016.2.x nutzen, nicht das letzte Release!
Es läuft auch weiterhin Kernel 4.4.x - jedoch wurde an vielen Stellen optimiert um den RAM-Verbrauch zu senken.
Die Neuerungen stehen in den oben verlinkten Release notes, hier nur ganz kurz die Neuigkeiten und Fallstricke für die “tl;dr”-Leute:

Partitionierungsänderung → CPE/WBS-Geräte brauchen vorher latest v2016.2.x oder v2017.1.8 !
verbesserte Stabilität durch gesenkten RAM-Verbrauch
Multidomain Firmwares (ein Image für mehrere Segmente/Hoods/Meshes)
VXLAN für Mesh-on-LAN/WAN (Vermeidung von Bridging von Segmenten)
mehr Geräte unterstützt
Neuimplementierung der Statusseite
mehr Übersetzungsmöglichkeiten
DNS-Cache Option wieder entfernt (DNSSEC Probleme)
ARP limit Paket
router advertisement filter Paket (bestes IPv6 Gateway nutzen)
batman-adv 2018.1

Wichtige Infos für Upgrades (nötige Änderungen an site.conf, site.mk und packages) stehen in den Release Notes - wenn man von v2016.2.x kommt muss man dennoch auch die Release Notes von v2017.1.x lesen!
Es gibt hierzu zwar auch einen Forenthread, wir haben uns aber noch mehr Mühe gegeben, dass die Release Notes alles abdecken - falls etwas fehlt, gerne darauf hinweisen.

Probleme damit bitte im IRC-Channel, auf der Mailing Liste oder als GitHub-Issue melden - nicht hier.

Wichtiger Nachtrag:
Bitte gleich das Release v2018.1.4 nutzen, wenn ihr updated, also dies hier überspringen um einen Bug im Autoupdater zu umgehen.

collimas · 9. Juli 2018 um 13:12

Ein großes Dankeschön für eure Arbeit! Ich hätte da gleich eine Frage, aus der Doku erschließt es sich mir nicht. Wie schreibe ich mehrere Domänen mit Ortsangaben in die domain.conf? Also z.B. ‚Freifunk Lippe Domäne 1: Blomberg‘ oder ‚Freifunk Lippe Domäne 2: Detmold‘ etc. ?

{
  -- multiple codes/names can be defined, the first one is the primary name
  -- additional aliases can be defined
  domain_names = {
    fflip-d1 = 'Freifunk Lippe Domäne 1',
    fflip-d2 = 'Freifunk Lippe Domäne 2',
    fflip-d3 = 'Freifunk Lippe Domäne 3',
    fflip-d4 = 'Freifunk Lippe Domäne 4',
  },

Wie genau lautet die Syntax, um einen Alias zu definieren?

rotanid · 9. Juli 2018 um 14:06

da würde ich nicht jedes Mal „Freifunk Lippe“ vorne dran schreiben, sondern nur „Detmold“ z.B.
hier eine Beispiel-Domäne in Darmstadt: https://git.darmstadt.ccc.de/ffda/site/blob/multidomain/domains/dom10.conf

collimas · 9. Juli 2018 um 16:12

Klar, war auch nur ein Beispiel. Danke!

Was mag es sein, wenn folgender Fehler im Buildlog auftaucht?

*** site error: no domain configurations found

Ich finde in site.conf und site.mk nichts Offenkundiges, was da fehlen könnte.

rotanid · 9. Juli 2018 um 22:35

hast du denn die domain configs im Ordner „domains/“ angelegt?
https://gluon.readthedocs.io/en/latest/features/multidomain.html
"In the site repository, create the domains/ directory, which will hold your domain configurations. "

collimas · 10. Juli 2018 um 02:33

Ich danke dir. Hatte noch einen Typo produziert.

Jason · 10. Juli 2018 um 09:19

Frage:

Die Aussage bezieht sich nur auf CPE/WBS-Geräte?
Alle anderen v2016.2-Release Geräte können direkt ohne Umwege auf v2018.1 aktualisiert werden?

Weil das würde ja bedeuten, dass Communities lediglich für CPE/WBS-Geräte ein v2016.2.x-Zwischenupdate bereitstellen bräuchten.

rotanid · 11. Juli 2018 um 02:26

jein. für viele x86 geräte braucht man zumindest v2016.2.6 - aber das wird nicht mehr bauen, falls man es also nicht schon hat muss man auch hierfür v2016.2.x bauen.

jotzt · 24. Juli 2018 um 21:34

Eine Rocket M2 mit 2018 hat hier vor kurzem die WiFi-Meshlinks komplett verloren. Ein Reboot ändert nichts. Ggf. auch eine fehlerhafte Config, aber alle anderen Geräte mit der Firmware laufen ohne Probleme.

https://karte.freifunk-muensterland.de/map36/#!v:m;n:6872512a2dbb

iwinfo mesh0 a
No station connected

batctl td mesh0

23:30:46.586385 BAT 56:30:cd:45:d6:e3: OGM IV via neigh e2:b8:f7:63:36:31, seq 1018849905, tq 198, ttl 47, v 15, flags [...], length 232, tvlv_len 36
	TVLV TTv1: OGM DIFF [.] ttvn=91 vlan_num=2 entry_num=0
		VLAN ID 0, crc 0x018e852c
		VLAN ID -1, crc 0xdc4323e1
	TVLV DATv1: enabled

usw…

rotanid · 24. Juli 2018 um 23:09

aktuell sehe ich da einen Mesh-Partner?
Wie ist die txpower gesetzt?
Hat sich vielleicht einfach die Location des Gerätes verändert, wurde das vor Ort kontrolliert?

adorfer · 24. Juli 2018 um 23:35

schau mal, wie die /etc/config/wireless ausschaut.
Wenn das ein Knoten ist der „noch von 2014, also AA kommend oder so“ immer nur autogeupdated wurde, dann stehen da manchmal (heute) total krude Dinge drin, also PCI-Pfade, die nicht mehr nötig sind. Oder irgendwelche .11abgn-Sachen.

adorfer · 25. Juli 2018 um 01:52

Ich habe den Eindruck, dass die 2018.1.x es überhaupt nicht mag „falsch angeschlossen“ zu werden.
Der betroffene Router quittiert das mit „load >2“.

Hier war z.B. nach dem Sysupgrade (wie zuerwarten war) die vorher manuelle Zuordnung „eth0 und eth1 auf WAN“ (aka „wan to lan bridge“) verloren gegangen.
Am br-lan hingt ein Sip-Telefon, was so ziemlich alles versucht haben wird „nach Hause zu telefonieren“… aber nicht geschafft hat…

Sprich: Wenn man solche Verkabelungfehler produziert, dann dann ist schnell 90% Last in „system“ und die Kiste bootet ständig neu.
grafik
grafik

rotanid · 25. Juli 2018 um 01:56

was ist das für eine Kiste (der knoten)? und kannst du genau das selbe Szenario mit einer älteren Firmware ausprobieren?

adorfer · 25. Juli 2018 um 02:01

https://map.ffdus.de/#!v:m;n:e894f6519496

Bis gestern 17 Uhr drehte da eine 2016.2.x drauf. Weekly reboot.
grafik
Aber da war die Network-Config auch noch in Ordnung… mal gucken, ob ein downgrade möglich ist.

adorfer · 25. Juli 2018 um 02:09

Nach dem firmwareupgrade hatte er eth0 sowhl in der client-bridge als auch in der mesh-lan-bridge.
Das hat wohl die ebtables-Filter massiv beschäftigt.

/etc/config/network

config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd6b:bc6c:79ca::/48'

config interface 'wan6'
        option proto 'dhcpv6'
        option ifname 'br-wan'
        option ip6table '1'
        option peerdns '0'
        option sourcefilter '0'
        option reqprefix 'no'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '0 1 2 3 4'

config interface 'wan'
        option auto '1'
        option peerdns '0'
        option type 'bridge'
        option proto 'dhcp'
        option multicast_querier '0'
        option macaddr '3e:54:68:61:af:70'
        option igmp_snooping '1'
        option ifname 'eth1'

config rule6 'wan6_lookup'
        option mark '0x01/0x01'
        option lookup '1'

config route6 'wan6_unreachable'
        option type 'unreachable'
        option table '1'
        option target '::/0'
        option metric '65535'
        option gateway '::'
        option interface 'loopback'

config interface 'mesh_wan'
        option ifname 'br-wan'
        option transitive '1'
        option index '0'
        option proto 'gluon_wired'
        option disabled '1'

config interface 'mesh_lan'
        option mesh 'bat0'
        option igmp_snooping '0'
        option mesh_no_rebroadcast '1'
        option transitive '1'
        option macaddr '3e:54:68:61:af:74'
        option ifname 'eth0'
        option index '4'
        option proto 'gluon_wired'
        option disabled '1'

config interface 'mesh_vpn'
        option ifname 'mesh-vpn'
        option mtu '1364'
        option fixed_mtu '1'
        option transitive '1'
        option macaddr '3e:54:68:61:af:77'
        option proto 'gluon_mesh'

config interface 'fallback'
        option sourcefilter '0'
        option proto 'dhcpv6'
        option peerdns '1'

config interface 'mesh_radio0'
        option proto 'gluon_mesh'

config interface 'client'
        option igmp_snooping '1'
        option type 'bridge'
        option auto '1'
        option multicast_querier '1'
        option macaddr 'e8:94:f6:51:94:96'
        list ifname 'bat0'
        list ifname 'eth0'
        list ifname 'local-port'
        option ipv6 '1'
        option keep_ra_dnslifetime '1'
        option sourcefilter '0'
        option peerdns '0'
        option robustness '9'
        option reqprefix 'no'
        option query_interval '2000'
        option query_response_interval '500'
        option proto 'dhcpv6'

config device 'local_node_dev'
        option type 'veth'
        option name 'local-node'
        option peer_name 'local-port'
        option macaddr '04:5c:85:12:ef:e0'
        option peer_macaddr 'e8:94:f6:51:94:96'

config interface 'local_node'
        option ifname 'local-node'
        option ipaddr '10.155.0.1/16'
        option ip6addr 'fda0:747e:ab29:9375::1/128'
        option ip6deprecated '1'
        option proto 'static'

config interface 'gluon_bat0'
        option proto 'gluon_bat0'

config interface 'bat0'
        option multicast_router '2'
        option ifname 'bat0'
        option auto '1'
        option macaddr 'e8:94:f6:51:94:96'
        option learning '1'
        option proto 'none'

config route6 'local_node_route6'
        option target 'fda0:747e:ab29:9375::/64'
        option gateway '::'
        option interface 'client'

rotanid · 25. Juli 2018 um 02:14

das klingt aber jetzt eher nach „sehr ärgerlich, aber nicht ungewöhnlich, dass eine eigene Anpassung bei Upgrades kaputt geht und Probleme macht“ ?

adorfer · 25. Juli 2018 um 03:46

Völlig klar, das war aber nicht der Punkt meines Postings.
Es ging um „wenn ihr plötzlich extreme Load seht, kontrolliert die settings“, nicht mehr und nicht weniger.

jotzt · 25. Juli 2018 um 06:54

Das Gerät ist nach wie vor an Ort und Stelle. Die möglichen Meshpartner empfangen auch alle ein Signal (-75…-80 dBm). txpower ist auf 6 (ubnt Rocket M2)

jotzt · 25. Juli 2018 um 16:10

Das Problem besteht unabhängig von einem Reboot und Downgrade auf 2017.1.8 mit sysupgrade -n. Demnach scheint es kein 2018.1-spezifisches Problem zu sein. Also hier off-topic.