Aktualisierte Router Firmware 0.9.4.3


#1

In der aktuellen Version 0.9.4.3 gibt es zwei zusätzliche Pakete:

PACKAGES_FFWTBG_REPO=https://github.com/ffwtbg/ffwtbg-packages.git
PACKAGES_FFWTBG_BRANCH=v2017.1.4
PACKAGES_FFWTBG_COMMIT=a3c6410fe37f75bd339ca00b1b225a10bf930f45

Mit diesem Paket erhalten bestimmte Router einen Reboot um 2:00Uhr morgens.
Welche Router das sind, kann man hier nachlesen: https://github.com/ffwtbg/ffwtbg-packages/commit/a3c6410fe37f75bd339ca00b1b225a10bf930f45

PACKAGES_SSIDCHANGER_REPO=https://github.com/freifunk-nord/gluon-ssid-changer.git
PACKAGES_SSIDCHANGER_COMMIT=b0535e2a5c570a76cb06453ee359160c2dd926c2
PACKAGES_SSIDCHANGER_BRANCH=lede

Dies ist ein konfigurier barer SSID Changer der zum tragen kommt, wenn der Freifunk Router sein Gateway nicht mehr erreichen kann. Das gilt für Uplink und Mesh Router. Aktuell konfiguriert ist Freifunk ohne Internet + Nodename. Eine ausführliche Beschreibung findet sich hier: https://github.com/freifunk-nord/gluon-ssid-changer
Die ersten 5 Minuten erscheint übrigens noch nicht die Offline SSID, das scheint noch ein Bug zu sein.

Die Konfiguration erfolgt in der Datei site.conf:

ssid_changer = {
enabled = true,
switch_timeframe = 1,
first = 5,
prefix = 'Freifunk ohne Internet ',
suffix = ‘nodename’,
tq_limit_enabled = false,
tq_limit_max = 45,
tq_limit_min = 35,
},

Feature Wünsche für die nächste Firmware, die vermutlich schon mit Gluon 2017.1.5 bzw. 2017.2 gebaut wird bitte auch hier unter diesen Beitrag. Ebenso natürlich Fehlerbeschreibungen und Lob in Bezug auf diese Version :wink:


#2

first = 5, – the first few minutes directly after reboot within which an Offline-SSID always may be activated (must be <= switch_timeframe)

Heißt im Klartext die switch_timeframe ist derzeit zu klein, ich würde es in der nächsten Firmware mal auf 10 Minuten setzen. Werde dies aber mal testen. Wenn das dann klappt, wäre das schonmal eine kleine Änderung für die nächste Firmware.


#3

Danke für das schnelle Update Marcel :slight_smile:
Wir hätten für die nächste Firmware in Sprockhövel
gerne wieder den Namen der Node aus der offline ssid entfernt. Wenn Du möchtest mache ich auf Github einen PR dafür.

Gruss


#4

Ist vorgemerkt, kannst aber auch gern noch einen PR dafür machen, dann werde ich auch etwas fit was Github angeht. :raising_hand_man:


#5

@mattes
Warum wollt ihr denn den Nodenamen wieder rausnehmen? Ist das nicht einfacher bei einer Fehlersuche vor Ort ?

@marcel_wtt
@mattes
Nur so ne Vermutung…kann mich aber auch täuschen. Bau bzw flash noch mal solche Problemrouter mit der 0.9.4.2 FW (ohne ssid changer). Die einigen wenigen Router die in Herbede vorab von Hand geflasht wurden, hatten keine Ausfälle.


#6

Die in Herbede sind allerdings auch mit Gluon 2017.1.3 gebaut, das WiFi Problem gibt es seit Gluon 2016, vielleicht auch davor und hat mit dem SSID Changer sicher nichts zu tun. Zumindest am Arbeitsspeicher hat sich nichts verändert. Man kann aber sicher versuchen einen Workaround mit Neustart des WiFi zu bauen.


#7

Wie gesagt…Vermutung. Da die Herbeder Router ohne zusätzliche Pakete ne uptime von 2 Tagen ohne Ausfälle hatten.

Ist ja auch schnell geflasht/getestet…


#8

Das hatten wir explizit herausgenommen, weil wir nicht möchten, das dann Hans und Kunz,
die den Router von Firma XY benutzen, dann dort auflaufen und sagen das der Freifunk Router nicht geht.
Soweit ich das noch weiß, hat Lars damals da die “Interessen” der Ladenbesitzer vertreten,
deshalb möchte ich das auch gerne wieder so haben wenn es möglich ist :slight_smile:

Naja Uptime ist nicht das Problem, denn nur das 2Ghz WLAN stürzt ab, was wohl auf viel Client
und oder Collision Traffic zurückzuführen ist. Es betrifft bei uns sehr oft Router die an sehr Frequentierten
Plätzen stehen oder viele Stationen in der nähe sind die Funken (evt. Hidden Stations).

Ich habe die Tage etwas zu dem Problem gelesen, das es scheinbar irgendwas mit dem MCS Modus
zutun haben könnte, weil er in einen MCS Modus springt, den der Wlan Treiber unter LEDE nicht kennt.
Da er den Modus nicht kennt, schaltet er das WLAN-Modul ab. (Ist aber nicht verifiziert)

Gruß
Mattes


#9

Was ich nur nicht verstehe… z.B. Freifunk Winterberg:
Die haben Gluon 2016.2.x & LEDE 2017.1.4 im Einsatz. Auf 841’er…1043’er…ohne Ausfälle.
Welche mit vielen mesh-links…und welche mit vielen Clients.
Liegt es vielleicht gar nicht an der Firmware bzw sollten wir uns mal deren Config ansehen?

Nur als ein Beispiel von vielen:
http://map.freifunk-winterberg.net/#!v:m;n:ec086b7865a2


#10

Nein, die haben ihre initiale config von uns :slight_smile:
Was ich mir sonst noch vorstellen könnte ist,
das es am Kanal 13 liegt. Und was diese Ausfälle betrifft, kannst Du anhand der Karte anderer Communitys schlecht auf unsere schliessen. Ich behaupte jetzt mal, das die WLAN Kanäle hier viel mehr belastet sind.


#11

Da gehe ich konform. Das könnte in der Tat zum Problem werden.


#12

Aber können wir da nicht einfach mal ein “Testfeld” mal auf nen anderen Kanal schicken? Ideal natürlich mit vorhandenen “Problemroutern”.


#13

Wir nutzen doch Kanal 6 und Kanal 13 in verschiedenen Sites, wenn an der Theorie was dran wäre müsste es ja in bestimmten Sites nicht auftreten: https://github.com/freifunk-en/gluon-configs


#14

Ja tritt das Problem bei den Kanal 6ern nicht auf?
Bei uns ist es auch immer nur 2ghz was sich weghängt.
5ghz läuft problemlos weiter, und Clients können ohne Probleme surfen.


#15

Auf 5GHz habe ich mangels Masse in WTT bisher keine Auffälligkeiten. Ich glaube der Kanal spielt keine Rolle.

Wenn man das ganze EN-Netz betrachtet findet man immer den einen oder anderen der nur 5% Linkqualität hat.
Natürlich ist das nervig, aber ist der Effekt wirklich so schlimm? Ich glaube kaum, dass jeder zuhause anfängt ständig den Ping zu messen.

Wieviele Router und welche betrifft das denn so am Tag? Kriegen wir da ne Statistik hin? Vielleicht kommen wir so weiter. Die 4900er machen das auf 2,4GHz auch, das kann ich bestätigen.


#16

Es wäre egal wenn das “mal“ Auftritt, aber es betrifft
bei uns gleich mehrere, die so einmal pro Tag von den Problem betroffen sind. Also inakzeptabel :slight_smile:
Wir testen jetzt mal ob es der Kanal ist.


#17

…da wäre ich mir nicht so sicher…frag mal @Bjoern wie oft er in den letzten 2 Monaten nen ping gemessen hat.:joy:

…aber Spaß beiseite. Ich würde wirklich mal ne nackte FW bauen…ohne zusätzliche Pakete…und nen anderen Kanal. Wenn es dann immer noch Kacke ist können wir ja immer noch nen “quickfix” mit einbauen.


#18

Da sind doch keine zusätzlichen Pakete drin.
Der SSID-Changer und der Reboot Script sind ja keine Dinge, die das Funkverhalten beeinflussen.
(Quickfix würde ich einsehen, da er massiv eingreift, aber die beiden? srsly?)
Hauptsächlich kommen die Probleme aus dem “neuen” WLAN-Treiber.
In 2015.1.2 war es noch der alte, der super stabil lief, was sich schlagartig geändert hat mit dem
neuen Gluon/Kernel.
Kanal wechseln kann man auch per uci, und Bitte nicht noch 20 Firmware Revisionen, wenn ich
die Liste da sehe auf der Map bekomm ich schon Herpes Blasen :stuck_out_tongue:

Edit:

Was die Häufigkeit betrifft… finde die 3% Links :wink:


#19

Ich noch mal :slight_smile:

root@SPR-Rundstrahler-841n:~# opkg update
-ash: opkg: not found

Ist aus Gluon der Paketmanager entfernt worden, weiß jemand dazu etwas?


#20

In Gluon 2017.1 kam eine Änderung:

ar71xx-tiny

The new ar71xx-tiny target has split out of ar71xx-generic; all ar71xx-generic devices with only 4MB of flash have been moved to this target.

In contrast to ar71xx-generic, ar71xx-tiny does not support opkg anymore to save some space.