Firmware 1.0

wusel · 16. Juli 2018 um 12:05

Orginaler Blog-Post: https://freifunk-kreisgt.de/firmware-1-0/

Lange hat es gedauert, aber wir sind nun auf dem Weg zur ›magischen‹ Versionsnummer 1.0 unserer Firmware.

Wer kürzlich mal wieder auf unseren Firmwareserver geschaut hat, dem mag aufgefallen sein, daß im »Bastelzweig« (»rawhide«) erste Versionen einer Firmware mit der Versionsnummer »1.0.0« aufgetaucht sind.

Parallel ist auch die Liste der prinzipiell unterstützten Geräte länger geworden, u. a. werden wir demnächst z. B. TP-Link TL-WR1043N v5 und TP-Link Archer C7 v4 unterstützen können.

Möglich wird dies durch die gewissenhafte und zeitaufwendige Arbeit fleißiger Firmwaretüftler, die die Freifunk-Basisfirmware »Gluon« erstellen.
In der jüngst veröffentlichten Version »v2018.1« sollen viele Probleme, die in den 2017er Versionen noch vorhanden waren – und deren Existenz der Grund für uns war, nicht von der 2016er-Basis auf eine 2017er-Version zu wechseln –, nun ausgemerzt sein. Außerdem ermöglicht es jene neue Basisversion, eine Firmware für verschiedene Communities zu erstellen — etwas, was wir in unserer Firmware in den letzten zwei Jahren schon eingebaut und mit Geolokalisierung verknüpft haben.

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.

Für die noch immer ausstehende Netzwerkteilung (von einem Netz über den ganzen Kreis GT zu getrennten Netzen für Gütersloh Stadtgebiet, Nord- und Südkreis GT sowie Rheda-Wiedenbrück Stadtgebiet) werden wir folglich noch eine entsprechende 0.7er sowie 1.0er Firmware erstellen und per Autoupdate verteilen. Das wird dann wohl auch die letzte 0.7er Firmware sein. Auch alte Knoten können im Grunde auf die Version 1.0.x gebracht werden, aber eben nur durch manuelle Neuinstallation, nicht per einfachem Upgrade — jener Weg ist uns einfach zu fragil.

Mit Firmware 1.0 möchten wir auch endlich von der überholten Tunnellösung »fastd« zu »L2TP« wechseln, mit weniger Last – und mehr Durchsatz – auf beiden Seiten der Leitung dann.

Dies erst einmal als »Appetizer«, als Info, daß es bald wieder Freifunk-Firmware für tatsächlich noch kaufbare Router geben wird — kurz, daß Freifunk im Kreis Gütersloh und der Müritz-Region »noch zuckt« ;-)

charrr · 16. Juli 2018 um 16:11

Update ließ sich problemlos installieren (Ubiquiti Unifi AC MESH) und es scheint auch alles zu funktionieren. Der Knoten ist seit dem Update allerdings von der Karte verschwunden (rawhide?) (NodeID: 788a20726785)

charrr · 17. Juli 2018 um 06:03

nach dem Update auf 1.0.0~28 erscheint der Knoten auch wieder auf der Karte

outlawx · 17. Juli 2018 um 06:57

Großartig Es geht floorwärts

Mit der ~28 wirklich in der Tat wieder auf der Karte zu sehen. Update über SSH von ~19 auf ~28 hat geklappt, löste allerdings firmware.4830.org nicht auf - habs in die /etc/hosts eingetragen.

@charrr Nutzt du im Küstersteig VDSL? Der DSLAM ist ja nicht weit weg… Wenn ja, wie sind die Durchsatzraten? L2TP läuft noch nicht, oder?

lg outlawx

charrr · 17. Juli 2018 um 08:29

@outlawx
VDSL2 17a (ITU G.993.2), 25.088 kbit/s kommen hier bei uns an.
L2TP scheint noch nicht zu laufen. Durchsatz laut ookla Speedtest weiterhin ~12 Mbps Down / ~4 Mbps Up

wusel · 17. Juli 2018 um 12:12

Achtung, das sind wirklich die allerallerersten Builds — be careful

Insbesondere bitte die, die ‚rawhide‘ inkl. Autoupdater nutzen, bitte das JETZT nicht abschalten Denn beim Update von 0.7 auf 1.0 wandern die Knoten derzeit in die (zukünftige) Auffang-Umgebung ‚zzz‘ (derzeit technisch identisch mit dem Gütersloher Mesh, allerdings mit ‚freifunk.4830.org‘ als SSID):

To be fixed soon — derzeit sollte das alle - quasi versehentlich, da rawhide auf Autoupdate - aktualisierten Knoten betreffen … Tja, hat mich der Autoupdater wieder ausgetrickst, mit ‚gluon-4830*‘ statt ‚gluon-ffgt*‘ dachte ich, eine neue Basis zu legen; nun gibt’s dann später einfach neue signing Keys

wusel · 17. Juli 2018 um 22:15

Jajaja Defaultmäßig war nur noch respondd (Kartenserver pollt die Knoten) aktiviert, mußte für unseren alten, auf Push ausgelegten Kartenserver den ~~guten~~ alten Alfred (A.L.F.R.E.D – Almighty Lightweight Fact Remote Exchange Daemon – auf jedem Knoten bläst die Daten per Multicast ins Mesh) hinzuziehen …

Hmm, das sollten wir möglichst rausfinden, warum das nicht tut/tat. Nicht, daß es da Einstellungsprobleme/verkappte schwarze Löcher (== dysfunktionale Services) im Netz gibt.

Bei VDSL am Küstersteig? Oder in der FW?

Ich baue die FW jetzt erst einmal soweit, daß der »FFGT-Markenkern« vorhanden ist – Freifunk- und Config-Mode über WAN; Einbindung von setup.4830.org, um die lokale IP des Knotens im Config-Mode einfach zu ermitteln; Geolokalisierung und basierend darauf automatische Auswahl der Site-Config –, und das der Einfachheit halber auf Basis fastd. Wenn das soweit ist, würde ich die FW nach Experimental und dann Testing hieven, auf daß auch Langzeitstabilität getestet werden kann. Damit könnten dann auch schon neue Knoten (mit frischer Hardware ;)) ans Netz. Parallel würde ich dann in Rawhide auf L2TP/Tunneldigger schwenken — bedingt neue GWs usw., fällt also auch nicht vom Himmel.

charrr · 18. Juli 2018 um 10:30

1.0.0~31

Fehlermeldung beim Neustart in den Config-Modus

500 Interner Serverfehler

Entschuldigung, auf dem Server ist ein unerwarteter Fehler aufgetreten.

Failed to execute dispatcher target for entry '/wizard'.
The called action terminated with an exception:
...lib/gluon/config-mode/wizard/0010-ffgt-geolocate.lua:1: module 'luci.cbi' not found:
no field package.preload['luci.cbi']
no file './luci/cbi.lua'
no file '/usr/share/lua/luci/cbi.lua'
no file '/usr/share/lua/luci/cbi/init.lua'
no file '/usr/lib/lua/luci/cbi.lua'
no file '/usr/lib/lua/luci/cbi/init.lua'
no file './luci/cbi.so'
no file '/usr/lib/lua/luci/cbi.so'
no file '/usr/lib/lua/loadall.so'
no file './luci.so'
no file '/usr/lib/lua/luci.so'
no file '/usr/lib/lua/loadall.so'

Thomas · 18. Juli 2018 um 16:36

Hi,

den 841er (33378-freifunk-e894f67835d0) habe ich bewusst auf Rawhide stehen, da er nur noch ein reiner Testknoten ist. Habe ihn gestern getestet per Laptop am LAN Port, sah auf den ersten Blick gut aus. Werde die Tage immer mal wieder probieren.
@wusel Danke für deine Arbeit. War ja im letzter Zeit recht ruhig, aber eher aus dem Grunde weil fast immer alles lief. Super Arbeit.

wusel · 20. Juli 2018 um 00:34

Danke für die Info — habe ich “leider” aber auch bei der Installation auf meiner Fritz!Box 4020 sehen müssen (und dabei relativ gut debuggen und beheben können — der aktuelle Web-Krempel scheint kein wirres Caching mehr zu machen, yeah!) …

Yepp, aller Anfang ist schwer — ein Grund, warum wir so schleppend “der Karavane” folgen (die aktuelle Stable-FW basiert auf einer rund 1 Jahr alten Gluon-Version) ist primär, daß wir uns seinerzeit gewissen Ziele gesetzt haben/Design-Vorgaben von Gluon für unpraktisch hielten (und halten). Heißt im Umkehrschluß, daß wir Nacharbeiten müssen. Und jedes Gluon-Release hält, teils auch bedingt durch Änderungen “Upstream”, d. h. bei OpenWRT/LEDE, “Überaschungen” für uns bereit. Da hier kein OpenWRT-/LEDE-Entwickler sitzt, und die Dokumentation teilweise den Eindruck erweckt, von Insidern für Insider geschrieben worden zu sein, ist das immer eine Sache voller Blut, Schweiß und Tränen — man kann das teilweise den Commit-Nachrichten entnehmen

That said, 1.0.0~34 blendet auch schon wieder unserere Karte ein — aber jetzt sind wieder größere Änderungen notwendig, um den (IMHO vorhandenen) Komfort der 0.7er FW bei der Ersteinrichtung zu kopieren.

wusel · 20. Juli 2018 um 00:45

In dem Fall: Super! Das hilft prinzipiell viel — aber es bedeutet eben auch, daß das Risiko, daß solch ein Knoten “gebrickt” wird, hoch ist: “rawhide” wird gebaut und auf den Firmware-Server geschoben — niemand weiß vorher, was die FW macht, sie hat vorher nie einen Knoten gesehen. Ich hab’ jetzt den Build-Umfang wieder verkleinert (statt “ziemlich alles” baut derzeit “nur” x86 und ar71xx-generic, statt ~35 Minuten ist der Build jetzt in ~11 Minuten durch), aber in ar71xx-generic sind halt alle Atheros-Kisten mit mehr als 4 MB Flash.

Letztlich kann ich nicht mehr tun als zu warnen “rawhide” ist “frisch vom Knochen” sozusagen, das im Autoupdater zu haben, kann Eure Geräte, auch irreparabel, zum Türstopper machen, bevor irgendwer auch nur die Chance hatte, da reinzugucken. Wer das mit diesem Wissen dennoch tut: (ernstlich) vielen Dank! Nur sagt nicht, es hätte niemand gewarnt

Thomas · 20. Juli 2018 um 11:05

Dient sowieso nur als Türstopper . Denn der C7 wird bei mir wird auch nur noch als Offloader eingesetzt. Habe Unifi APs installiert, da mit meinen eigenen WLAN mit drei verschiedenen APs Probleme hatte.

wusel · 21. Juli 2018 um 14:15

Aus gegebenem Anlaß nochmal der Hinweis, daß »rawhide« mit Vorsicht zu genießen ist.

Bitte keinesfalls auf Knoten, die per Mesh-on-LAN/WAN mit anderen Knoten verbunden sind, ausprobieren. Stand jetzt hat »rawhide« noch den Bug, daß es die Auswahl, welche Netzkonfiguration der Knoten verwenden soll, von der 0.7er Firmware – die einen FFGT-Eigenbau dafür verwendet – in die 1.0er Firmware – die das neue »Multidomain«-Feature von Gluon v2018.1 nutzen wird –nicht überträgt.
Gluon v2018.1 setzt in dem Fall – keine Infomation (in Gluon-v2018.1-Notation) vorhanden – eine Defaultkonfiguration, in unserem Falle FFGT-alt (bis auf Adressen und Anzahl der Gateways identisch mit FFGT-neu).

Wenn nun also ein Knoten mit Müritz-Konfiguration mit einem anderen Knoten auf Müritz-Konfiguration per Kabel verbunden ist und auf ein aktuelles »rawhide« upgegraded wird, haben wir einen Knoten mit FFGT- und einen mit Müritz-Netz, die per Kabel verbunden sind und damit beide Meshes verbinden.
Gluon v2018.1 bietet Möglichkeiten, daß solche versehentliche Verbindungen zukünftig verhindert werden (VXLAN als Trenner), das können wir aber nicht direkt aktivieren, denn dann würden alle Kabelmeshes mindestens zeitweise zusammenbrechen … Daher auch der bisherige Plan, daß ein sysupgrade (via Autoupdate) nicht angeboten wird; die funktionalen Änderungen zwischen FW 0.7 und 1.0 sind recht groß.

m.bitterlich · 21. Juli 2018 um 21:34

Moin.
Zwei Probleme traten bei mir mit der 1.0.0~34 auf …

Auf meinem WR1043ND kam folgende Meldung.

Die Firmware 1.0.0~34 für WBS210 v1.2 ist nicht gültig … und ich hab mich schon sooo darauf gefreut.

wusel · 21. Juli 2018 um 23:44

Könnt Ihr bei sowas bitte mit CTRL-U (oder wie auch immer, je nach OS/Browser) den Quelltext laden und davon Screenshot oder Fehlermeldung per cut & waste posten? Da steht nämlich die Zeilennummer, in der, und i. d. R. auch ein Grund, warum der Fehler entstanden ist. Danke!

Puh, äh … was? Welche Meldung in welchem Kontext?

Thomas · 22. Juli 2018 um 12:30

Hmm, komisch mein 841er hängt sich ca. alle 10-15 Minuten auf sobald auf dem LAN Port nen Raspberry dran hängt.
Gibt es irgendwo Logs die man vor dem Reboot abfangen kann?
Vom Bauchgefühl her würde ich sagen Strommangel. Hängt per POE am Netz. Habe leider gerade kein Netzteil zum testen. Morgen mal eins vom anderen Standort mit bringen.

Oder hilft das etwas?

root@33378-freifunk-e894f67835d0:~# tail /sys/kernel/debug/crashlog
<6>[ 690.998650] [ 4076] 0 4076 281 24 4 0 0 0 dropbear
<6>[ 691.007823] [ 4093] 0 4093 297 11 4 0 0 0 ash
<6>[ 691.016551] [ 4283] 0 4283 329 46 4 0 0 0 dhcpv6.script
<6>[ 691.026171] [ 4284] 0 4284 295 19 3 0 0 0 jshn
<6>[ 691.034990] [ 4285] 0 4285 296 9 3 0 0 0 sh
<6>[ 691.043628] [ 4287] 0 4287 296 9 3 0 0 0 sh
<6>[ 691.052265] [ 4289] 0 4289 261 3 3 0 0 0 sh
<6>[ 691.060903] [ 4291] 0 4291 261 3 3 0 0 0 dhcpv6.script
<0>[ 691.070513] Kernel panic - not syncing: Out of memory: system-wide panic_on_oom is enabled
<0>[ 691.070513]

Thomas · 22. Juli 2018 um 12:59

Time: 1532264166.178937
Modules: ath9k@80de0000+1aa68 ath9k_common@80dd8000+562e ath9k_hw@80d80000+57c8c ath@80c58000+47d3 mac80211@80d00000+65c82 cfg80211@80c80000+394b8xt_CT@80c38000+a10 compat@81b98000+2bed batman_adv@81ba0000+1a063 gpio_button_hotplug@81b5c000+1890
<6>[ 1.498420] eth0: Atheros AG71xx at 0xba000000, irq 5, mode:GMII
<6>[ 2.095426] ag71xx ag71xx.0: connected to PHY at ag71xx-mdio.1:04 [uid=004dd042, driver=Generic PHY]
<6>[ 2.105675] eth1: Atheros AG71xx at 0xb9000000, irq 4, mode:MII
<6>[ 2.113382] nf_conntrack version 0.5.0 (425 buckets, 1700 max)
<6>[ 2.120106] xt_time: kernel timezone is -0000
<6>[ 2.125359] ip_tables: © 2000-2006 Netfilter Core Team
<6>[ 2.131994] NET: Registered protocol family 10
<6>[ 2.141818] ip6_tables: © 2000-2006 Netfilter Core Team
<6>[ 2.147863] NET: Registered protocol family 17
<6>[ 2.152605] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
<6>[ 2.165668] Ebtables v2.0 registered
<6>[ 2.170148] 8021q: 802.1Q VLAN Support v1.8
<6>[ 2.182387] VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
<6>[ 2.191773] Freeing unused kernel memory: 292K
<14>[ 3.267441] init: Console is alive
<14>[ 3.271219] init: - watchdog -
<14>[ 4.050462] kmodloader: loading kernel modules from /etc/modules-boot.d/*
<14>[ 4.119088] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
<14>[ 4.137134] init: - preinit -
<6>[ 4.820840] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
<5>[ 4.850954] random: procd: uninitialized urandom read (4 bytes read, 7 bits of entropy available)
<6>[ 6.413891] eth0: link up (1000Mbps/Full duplex)
<6>[ 6.418713] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
<5>[ 7.084465] jffs2: notice: (387) jffs2_build_xattr_subsystem: complete building xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead, 0 orphan) found.
<14>[ 7.102687] mount_root: switching to jffs2 overlay
<12>[ 7.120373] urandom-seed: Seeding with /etc/urandom.seed
<6>[ 7.331205] eth0: link down
<14>[ 7.348047] procd: - early -
<14>[ 7.351153] procd: - watchdog -
<14>[ 7.978562] procd: - watchdog -
<14>[ 7.982135] procd: - ubus -
<5>[ 8.037776] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
<5>[ 8.047646] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
<5>[ 8.057114] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
<5>[ 8.066689] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
<5>[ 8.076457] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
<5>[ 8.086015] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
<5>[ 8.095575] random: ubusd: uninitialized urandom read (4 bytes read, 13 bits of entropy available)
<14>[ 8.105338] procd: - init -
<14>[ 8.443777] kmodloader: loading kernel modules from /etc/modules.d/*
<6>[ 8.462365] batman_adv: B.A.T.M.A.N. advanced 2013.4.0 (compatibility version 14) loaded
<6>[ 8.473549] Loading modules backported from Linux version wt-2017-01-31-0-ge882dff19e7f
<6>[ 8.481831] Backport generated by backports.git backports-20160324-13-g24da7d3c
<7>[ 8.586688] ath: EEPROM regdomain: 0x0
<7>[ 8.586715] ath: EEPROM indicates default country code should be used
<7>[ 8.586725] ath: doing EEPROM country->regdmn map search
<7>[ 8.586749] ath: country maps to regdmn code: 0x3a
<7>[ 8.586762] ath: Country alpha2 being used: US
<7>[ 8.586771] ath: Regpair used: 0x3a
<7>[ 8.598789] ieee80211 phy0: Selected rate control algorithm ‘minstrel_ht’
<6>[ 8.605655] ieee80211 phy0: Atheros AR9531 Rev:1 mem=0xb8100000, irq=47
<14>[ 8.647927] kmodloader: done loading kernel modules from /etc/modules.d/*
<5>[ 10.047176] random: jshn: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
<5>[ 10.071466] random: ubusd: uninitialized urandom read (4 bytes read, 16 bits of entropy available)
<6>[ 19.571298] device eth0 entered promiscuous mode
<6>[ 19.598001] IPv6: ADDRCONF(NETDEV_UP): br-client: link is not ready
<6>[ 19.701584] device eth1 entered promiscuous mode
<6>[ 19.728783] br-wan: port 1(eth1) entered forwarding state
<6>[ 19.734483] br-wan: port 1(eth1) entered forwarding state
<6>[ 19.863590] IPv6: ADDRCONF(NETDEV_UP): local-node: link is not ready
<6>[ 19.932603] device wan15 entered promiscuous mode
<6>[ 20.061177] IPv6: ADDRCONF(NETDEV_CHANGE): local-node: link becomes ready
<6>[ 20.203017] device local-port entered promiscuous mode
<6>[ 20.269092] br-client: port 3(local-port) entered forwarding state
<6>[ 20.275633] br-client: port 3(local-port) entered forwarding state
<6>[ 20.282197] IPv6: ADDRCONF(NETDEV_CHANGE): br-client: link becomes ready
<6>[ 20.565714] br-wan: port 1(eth1) entered disabled state
<6>[ 21.184011] eth0: link up (1000Mbps/Full duplex)
<6>[ 21.190940] br-client: port 1(eth0) entered forwarding state
<6>[ 21.196884] br-client: port 1(eth0) entered forwarding state
<7>[ 21.845070] ath: EEPROM regdomain: 0x8114
<7>[ 21.845097] ath: EEPROM indicates we should expect a country code
<7>[ 21.845109] ath: doing EEPROM country->regdmn map search
<7>[ 21.845121] ath: country maps to regdmn code: 0x37
<7>[ 21.845134] ath: Country alpha2 being used: DE
<7>[ 21.845144] ath: Regpair used: 0x37
<7>[ 21.845158] ath: regdomain 0x8114 dynamically updated by user
<6>[ 22.186284] eth1: link up (100Mbps/Full duplex)
<6>[ 22.191037] br-wan: port 1(eth1) entered forwarding state
<6>[ 22.196744] br-wan: port 1(eth1) entered forwarding state
<6>[ 22.272464] br-client: port 3(local-port) entered forwarding state
<6>[ 22.434084] br-client: port 2(wan15) entered forwarding state
<6>[ 22.440084] br-client: port 2(wan15) entered forwarding state
<6>[ 22.725858] br-client: port 3(local-port) entered disabled state
<6>[ 22.732197] br-client: port 2(wan15) entered disabled state
<6>[ 22.738059] br-client: port 1(eth0) entered disabled state
<6>[ 22.903186] device eth0 left promiscuous mode
<6>[ 22.907822] br-client: port 1(eth0) entered disabled state
<6>[ 23.016179] eth0: link down
<6>[ 23.169147] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
<6>[ 23.233610] device local-port left promiscuous mode
<6>[ 23.238804] br-client: port 3(local-port) entered disabled state
<6>[ 23.473922] IPv6: ADDRCONF(NETDEV_UP): local-port: link is not ready
<6>[ 23.480804] device wan15 left promiscuous mode
<6>[ 23.485646] br-client: port 2(wan15) entered disabled state
<6>[ 23.665349] IPv6: ADDRCONF(NETDEV_UP): wan15: link is not ready
<6>[ 24.000349] device eth0 entered promiscuous mode
<6>[ 24.078120] device local-port entered promiscuous mode
<6>[ 24.138552] IPv6: ADDRCONF(NETDEV_UP): ibss0: link is not ready
<6>[ 24.168031] device wan15 entered promiscuous mode
<6>[ 24.192528] br-wan: port 1(eth1) entered forwarding state
<6>[ 24.317274] br-client: port 3(wan15) entered forwarding state
<6>[ 24.323351] br-client: port 3(wan15) entered forwarding state
<6>[ 24.329307] br-client: port 2(local-port) entered forwarding state
<6>[ 24.335755] br-client: port 2(local-port) entered forwarding state
<6>[ 24.394463] batman_adv: bat0: Adding interface: primary0
<6>[ 24.399997] batman_adv: bat0: Interface activated: primary0
<6>[ 24.436286] ibss0: Created IBSS using preconfigured BSSID 00:42:de:ca:fb:ad
<6>[ 24.443569] ibss0: Creating new IBSS network, BSSID 00:42:de:ca:fb:ad
<6>[ 24.464183] IPv6: ADDRCONF(NETDEV_CHANGE): ibss0: link becomes ready
<6>[ 24.611411] device bat0 entered promiscuous mode
<6>[ 24.616680] br-client: port 4(bat0) entered forwarding state
<6>[ 24.622633] br-client: port 4(bat0) entered forwarding state
<6>[ 24.893511] batman_adv: bat0: Interface deactivated: primary0
<6>[ 24.946814] IPv6: ADDRCONF(NETDEV_UP): primary0: link is not ready
<6>[ 25.047241] batman_adv: bat0: Interface activated: primary0
<6>[ 25.194771] eth1: link down
<6>[ 25.563986] eth0: link up (1000Mbps/Full duplex)
<6>[ 25.568983] br-client: port 1(eth0) entered forwarding state
<6>[ 25.574993] br-client: port 1(eth0) entered forwarding state
<6>[ 25.792992] br-wan: port 1(eth1) entered disabled state
<6>[ 25.865329] br-client: port 3(wan15) entered disabled state
<6>[ 26.274812] eth1: link up (100Mbps/Full duplex)
<6>[ 26.332738] br-client: port 2(local-port) entered forwarding state
<6>[ 26.340192] br-wan: port 1(eth1) entered forwarding state
<6>[ 26.345983] br-wan: port 1(eth1) entered forwarding state
<6>[ 26.400891] br-client: port 3(wan15) entered forwarding state
<6>[ 26.407036] br-client: port 3(wan15) entered forwarding state
<6>[ 26.622534] br-client: port 4(bat0) entered forwarding state
<6>[ 27.572730] br-client: port 1(eth0) entered forwarding state
<6>[ 28.183724] batman_adv: bat0: Adding interface: ibss0
<6>[ 28.188963] batman_adv: bat0: Interface activated: ibss0
<6>[ 28.342511] br-wan: port 1(eth1) entered forwarding state
<6>[ 28.402524] br-client: port 3(wan15) entered forwarding state
<6>[ 30.016610] batman_adv: bat0: Changing gw mode from: off to: client
<6>[ 30.073328] batman_adv: bat0: hop_penalty: Changing from: 30 to: 15
<6>[ 30.080796] batman_adv: bat0: orig_interval: Changing from: 1000 to: 5000
<6>[ 33.571504] batman_adv: bat0: Adding interface: mesh-vpn
<6>[ 33.577114] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1426) 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.
<6>[ 33.602161] batman_adv: bat0: Interface activated: mesh-vpn
<6>[ 33.695915] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
<5>[ 35.512555] random: nonblocking pool is initialized
<4>[ 943.378660] crond invoked oom-killer: gfp_mask=0x2420848, order=0, oom_score_adj=0
<4>[ 943.386591] CPU: 0 PID: 911 Comm: crond Not tainted 4.4.135 #0
<4>[ 943.392646] Stack : 8042159c 00000000 00000001 80480000 818865fc 804747e3 8040298c 0000038f
<4>[ 943.392646] 804e378c 00001ade 00000040 00000000 00000000 800a7f10 00000006 00000000
<4>[ 943.392646] 00000000 00000000 8040649c 80f2b994 804e6542 800a5e8c 02420848 00000000
<4>[ 943.392646] 00000001 801fd600 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 943.392646] 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
<4>[ 943.392646] …
<4>[ 943.429677] Call Trace:
<4>[ 943.432229] [<800721cc>] show_stack+0x54/0x88
<4>[ 943.436746] [<800d5468>] dump_header.isra.4+0x48/0x130
<4>[ 943.442071] [<800d5c38>] check_panic_on_oom+0x48/0x84
<4>[ 943.447290] [<800d5d64>] out_of_memory+0xf0/0x324
<4>[ 943.452178] [<800d9888>] __alloc_pages_nodemask+0x6b8/0x724
<4>[ 943.457967] [<800d2960>] pagecache_get_page+0x154/0x270
<4>[ 943.463396] [<80134cb0>] __getblk_slow+0x15c/0x374
<4>[ 943.468364] [<80160418>] squashfs_read_data+0x1c8/0x6e8
<4>[ 943.473787] [<80164628>] squashfs_readpage_block+0x32c/0x4d8
<4>[ 943.479651] [<801622a4>] squashfs_readpage+0x5bc/0x6d0
<4>[ 943.484970] [<800dd030>] __do_page_cache_readahead+0x1f8/0x264
<4>[ 943.491010] [<800d479c>] filemap_fault+0x1a8/0x458
<4>[ 943.495984] [<800efc1c>] __do_fault+0x64/0xd0
<4>[ 943.500506] [<800f2824>] handle_mm_fault+0x4a4/0xb40
<4>[ 943.505653] [<80076e98>] __do_page_fault+0x134/0x470
<4>[ 943.510796] [<80060820>] ret_from_exception+0x0/0x10
<4>[ 943.515916]
<4>[ 943.517457] Mem-Info:
<4>[ 943.519844] active_anon:680 inactive_anon:14 isolated_anon:0
<4>[ 943.519844] active_file:127 inactive_file:176 isolated_file:0
<4>[ 943.519844] unevictable:0 dirty:0 writeback:0 unstable:0
<4>[ 943.519844] slab_reclaimable:171 slab_unreclaimable:1974
<4>[ 943.519844] mapped:13 shmem:33 pagetables:107 bounce:0
<4>[ 943.519844] free:268 free_pcp:0 free_cma:0
<4>[ 943.552566] Normal free:1072kB min:1024kB low:1280kB high:1536kB active_anon:2720kB inactive_anon:56kB active_file:508kB inactive_file:704kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:32768kB managed:27512kB mlocked:0kB dirty:0kB writeback:0kB mapped:52kB shmem:132kB slab_reclaimable:684kB slab_unreclaimable:7896kB kernel_stack:448kB pagetables:428kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:7448 all_unreclaimable? yes
<4>[ 943.597401] lowmem_reserve[]: 0 0
<4>[ 943.600858] Normal: 84kB (UME) 348kB (ME) 4816kB (UM) 032kB 064kB 0128kB 0256kB 0512kB 01024kB 02048kB 0*4096kB = 1072kB
<4>[ 943.613116] 336 total pagecache pages
<4>[ 943.616901] 0 pages in swap cache
<4>[ 943.620332] Swap cache stats: add 0, delete 0, find 0/0
<4>[ 943.625721] Free swap = 0kB
<4>[ 943.628696] Total swap = 0kB
<4>[ 943.631682] 8192 pages RAM
<4>[ 943.634476] 0 pages HighMem/MovableOnly
<4>[ 943.638436] 1314 pages reserved
<6>[ 943.641690] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
<6>[ 943.650521] [ 451] 0 451 298 19 4 0 0 0 ubusd
<6>[ 943.659433] [ 452] 0 452 223 9 4 0 0 0 askfirst
<6>[ 943.668597] [ 614] 0 614 306 35 5 0 0 0 logd
<6>[ 943.677414] [ 621] 0 621 429 159 4 0 0 0 haveged
<6>[ 943.686501] [ 847] 0 847 225 10 4 0 0 0 gluon-arp-limit
<6>[ 943.696302] [ 882] 0 882 430 53 5 0 0 0 netifd
<6>[ 943.705297] [ 911] 0 911 297 10 4 0 0 0 crond
<6>[ 943.714201] [ 939] 0 939 264 10 3 0 0 0 dropbear
<6>[ 943.723380] [ 956] 0 956 225 13 3 0 0 0 uradvd
<6>[ 943.732375] [ 1308] 0 1308 225 16 3 0 0 0 micrond
<6>[ 943.741461] [ 1332] 0 1332 224 9 3 0 0 0 sse-multiplexd
<6>[ 943.751179] [ 1405] 0 1405 296 9 4 0 0 0 udhcpc
<6>[ 943.760181] [ 1418] 0 1418 254 20 3 0 0 0 odhcp6c
<6>[ 943.769274] [ 1476] 0 1476 254 19 3 0 0 0 odhcp6c
<6>[ 943.778357] [ 1528] 0 1528 321 20 4 0 0 0 uhttpd
<6>[ 943.787354] [ 1702] 0 1702 280 18 4 0 0 0 dnsmasq
<6>[ 943.796439] [ 1934] 0 1934 301 33 3 0 0 0 fastd
<6>[ 943.805359] [ 2012] 453 2012 263 18 3 0 0 0 dnsmasq
<6>[ 943.814450] [ 2150] 0 2150 297 10 3 0 0 0 ntpd
<6>[ 943.823261] [ 2171] 0 2171 259 26 3 0 0 0 alfred
<6>[ 943.832262] [ 2175] 0 2175 288 36 4 0 0 0 batadv-vis
<6>[ 943.841616] [ 2263] 0 2263 509 45 4 0 0 0 respondd
<6>[ 943.850791] [ 4994] 0 4994 329 47 5 0 0 0 dhcpv6.script
<6>[ 943.860413] [ 5012] 0 5012 296 9 4 0 0 0 sh
<6>[ 943.869052] [ 5013] 0 5013 304 18 5 0 0 0 dhcpv6.script
<6>[ 943.878664] [ 5015] 0 5015 297 12 3 0 0 0 cat
<6>[ 943.887392] [ 5016] 0 5016 232 14 3 0 0 0 batctl
<6>[ 943.896389] [ 5017] 0 5017 225 18 3 0 0 0 micrond
<0>[ 943.905470] Kernel panic - not syncing: Out of memory: system-wide panic_on_oom is enabled
<0>[ 943.905470]

wusel · 22. Juli 2018 um 18:05

Es steht derzeit auf der Kippe, ob wir für den 841 eine v1.0 rausbringen oder nicht; Flash ist zu klein, und RAM auch kritisch. Danke für die Info, das klingt eher nach “nicht” …

Wobei …

Thomas:

<5>[ 35.512555] random: nonblocking pool is initialized
<4>[ 943.378660] crond invoked oom-killer: gfp_mask=0x2420848, order=0, oom_score_adj=0
<4>[ 943.386591] CPU: 0 PID: 911 Comm: crond Not tainted 4.4.135 #0
<4>[ 943.392646] Stack : 8042159c 00000000 00000001 80480000 818865fc 804747e3 8040298c 0000038f

cron? Da sollte doch micron als Low-Memory-Footprint-Ersatz laufen?

<4>[ 943.600858] Normal: 84kB (UME) 348kB (ME) 4816kB (UM) 032kB 064kB 0128kB 0256kB 0512kB 01024kB 02048kB 0*4096kB = 1072kB
<4>[ 943.613116] 336 total pagecache pages
<4>[ 943.616901] 0 pages in swap cache
<4>[ 943.620332] Swap cache stats: add 0, delete 0, find 0/0
<4>[ 943.625721] Free swap = 0kB
<4>[ 943.628696] Total swap = 0kB
<4>[ 943.631682] 8192 pages RAM
<4>[ 943.634476] 0 pages HighMem/MovableOnly
<4>[ 943.638436] 1314 pages reserved
<6>[ 943.641690] [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
<6>[ 943.650521] [ 451] 0 451 298 19 4 0 0 0 ubusd
<6>[ 943.659433] [ 452] 0 452 223 9 4 0 0 0 askfirst
<6>[ 943.668597] [ 614] 0 614 306 35 5 0 0 0 logd
<6>[ 943.677414] [ 621] 0 621 429 159 4 0 0 0 haveged
<6>[ 943.686501] [ 847] 0 847 225 10 4 0 0 0 gluon-arp-limit
<6>[ 943.696302] [ 882] 0 882 430 53 5 0 0 0 netifd
<6>[ 943.705297] [ 911] 0 911 297 10 4 0 0 0 crond
<6>[ 943.714201] [ 939] 0 939 264 10 3 0 0 0 dropbear
<6>[ 943.723380] [ 956] 0 956 225 13 3 0 0 0 uradvd
<6>[ 943.732375] [ 1308] 0 1308 225 16 3 0 0 0 micrond
<6>[ 943.741461] [ 1332] 0 1332 224 9 3 0 0 0 sse-multiplexd
<6>[ 943.751179] [ 1405] 0 1405 296 9 4 0 0 0 udhcpc
<6>[ 943.760181] [ 1418] 0 1418 254 20 3 0 0 0 odhcp6c
<6>[ 943.769274] [ 1476] 0 1476 254 19 3 0 0 0 odhcp6c
<6>[ 943.778357] [ 1528] 0 1528 321 20 4 0 0 0 uhttpd
<6>[ 943.787354] [ 1702] 0 1702 280 18 4 0 0 0 dnsmasq
<6>[ 943.796439] [ 1934] 0 1934 301 33 3 0 0 0 fastd
<6>[ 943.805359] [ 2012] 453 2012 263 18 3 0 0 0 dnsmasq
<6>[ 943.814450] [ 2150] 0 2150 297 10 3 0 0 0 ntpd
<6>[ 943.823261] [ 2171] 0 2171 259 26 3 0 0 0 alfred
<6>[ 943.832262] [ 2175] 0 2175 288 36 4 0 0 0 batadv-vis
<6>[ 943.841616] [ 2263] 0 2263 509 45 4 0 0 0 respondd
<6>[ 943.850791] [ 4994] 0 4994 329 47 5 0 0 0 dhcpv6.script
<6>[ 943.860413] [ 5012] 0 5012 296 9 4 0 0 0 sh
<6>[ 943.869052] [ 5013] 0 5013 304 18 5 0 0 0 dhcpv6.script
<6>[ 943.878664] [ 5015] 0 5015 297 12 3 0 0 0 cat
<6>[ 943.887392] [ 5016] 0 5016 232 14 3 0 0 0 batctl
<6>[ 943.896389] [ 5017] 0 5017 225 18 3 0 0 0 micrond
<0>[ 943.905470] Kernel panic - not syncing: Out of memory: system-wide panic_on_oom is enabled
<0>[ 943.905470]

Mal gucken, warum da zwei crons laufen, danke für den Hint!

m.bitterlich · 22. Juli 2018 um 19:21

Auf der WBS210 v1.2 läuft zurzeit ‚gluon-ffggrz-0.9.1-exp20170615-tp-link-wbs210-v1.20.bin‘
und ich möchte gern ‚gluon-4830-1.0.0~34-tp-link-wbs210-v1.20.bin‘ ohne Konfigurationsübernahme. Die Checkbox im zweiten Bild war beim Absenden leer …

outlawx · 22. Juli 2018 um 19:29

du verwendest aber schon eine *sysupgrade.bin, oder??? Weil auf Stock-Firmware biste ja nicht mehr…