Vorösterliche Bescherung

Just for the records: 0.7.9~79 beinhaltet keine Unterstützung für »Wireless-WAN«, also die Nutzung eines (WPA2-verschlüsselten) WLANs (auf Kanal 9) anstelle eines Ethernetanschlusses als Internet-Uplink. Also jene Handvoll Spezialfälle bis auf weiteres bitte nicht händisch auf 0.7.9~xxx/0.8.0 (die kommende »stable«-Version wird als 0.8.0 debütieren) aktualiseren :slight_smile:

Habe gerade auf meinen Archer V7 v2 die aktuelle Rawhide 7.9.85 gespielt. Laufen tut erst mal alles. Das WAN Interface hat aber wieder eine neue MAC bekommen und somit auch eine neue IP vom DHCP.

Auf meinen 841 werde ich es die nächsten Tage einmal testen. Habe mich gerade beim Booten in den Config Modus ausgeperrt. Liegt scheinbar an meiner VLAN Konfiguration.

1 Like

Ja, habe ich auch feststellen müssen, hab’ das Feature vergessen zu portieren. Ich gucke mal, daß das WAN einfach die HW-Adresse behält; macht bei mir auch Probleme, da ich die MAC jeweils freischalten muß, d. h. ich brauche MAC von Original-FW (== Setup-Mode) und dann vom Gluon-WAN, und bei Mesh-on-WAN ändert die MAC erneut. Das ist irgendwie Lötzinn :frowning:

FTR, ab jetzt gibt’s auch ‘ReleaseNotes’ zu den Versionen, wo solche Dinge drinstehen (oder eben fehlen :-)). Verlinkt auf der Firmware-Seite.

So den 841 auch geupdatet. Mein Vlan Konfiguration ist sogar auch heile geblieben nach dem Update. Mal schauen was das System jetzt die nächsten Tage sagt.

FTR: 0.7.9~95 sollte einige Dinge fixen:

    Fix multiple issues:
     - re-enable siteselect cron job, adjust to micron from gluon-cron
     - Make sure /lib/gluon/site-upgrade is run after updating the sitecode in config mode
     - gluon-radv-filterd used wrong (future?) uci module
     - gut.conf wasn't converted to gut.json
     - geoloc/wizard replaced wizard-pre
     - if we have a WAN interface, it's real MAC will be used during normal operation. (But this currently differes from the MAC used for Config Mode, which seems to be the "primary MAC", i. e. the one of the first WiFi. Still needs some thoughs, this ...)

Frage zu der Statusseite.

Bei meinen Windows 10 Rechner wird von der Statusseite im Edge und FF52 nur die Linke Spalte Übersicht angezeigt. Mit Chrome die komplette Seite inkl Statistik und Nachbarknoten.

Schaue ich auf meine Raspberry wird im FF45 auch die komplette Seite angezeigt, genauso wie auf ihm mit Chrome.

Jemand eine Idee woran das liegen kann?

Bei meinen Windows 10 Rechner wird von der Statusseite im Edge und FF52 nur die Linke Spalte Übersicht angezeigt. Mit Chrome die komplette Seite inkl Statistik und Nachbarknoten.

Achselzuck Ich hab’ kein Windows am Start, kann ich somit schwer nachstellen. Aber im Zweifel mal im ›großen Forum‹ gucken, müßte dann ja mehrere Communities betreffen (auch wenn manche größeren ja noch zöger(t)en bzgl. Gluon v2016 und/oder z. T. die bunte Statuspage durch die alte ersetzt haben).

Moin,

0.7.9~104 würde ich gerne in Kürze zur »experimental« hochstufen, manuelle sysupgrades haben bei mir soweit geklappt; wäre klasse, wenn insbesondere Müritzer sich auch noch mal diese Version ansehen könnten (Huhu, @m.bitterlich & @outlawx). Aber auch im Kreis GT dürfen es gerne noch ein paar mehr Tester sein (@gtpix, @Echo, @Snot waren ja früher in dem Bereich auch aktiv).

http://map.4830.org/ffgt/meshflix/ ist eine Beta-Installation einer etwas aufgebohrten Karte (Müritz-Region & Kreis GT; ja, Müritz ohne Statistiken, sorry: ich muß mir da noch ein Schema ausdenken, wie das zukünftig laufen kann/soll), wo u. a. einige Statusinfos für den Umstieg mit ausgegeben werden (›locode‹, aktuelle SSID).
Die 0.7.9~104 gibt zusätzlich Statusinfos zum Uplink heraus (http://map.4830.org/ffgt/meshflix/#!v:m;n:e894f69081ec & http://map.4830.org/ffgt/meshflix/#!v:m;n:f8d111bd6816); ob der »Airtime«-Patch (vgl. http://map.4830.org/ffgt/meshflix/#!v:m;n:24a43cb111d9) der 0.7.4er-FW es noch in die 0.8.0 schaffen wird, kann ich nicht versprechen.

Gerne kann ich testen. Jedoch bin ich erst erst mitte Mai wieder ein paar Tage Zuhause.

0.7.9~104 habe ich soeben getan auf

  • 17255-Bibertours kam von ~96, keine Probleme

  • 16831-Tierarztpraxis kam von ~89, MAC hat sich demnach geändert

  • 17252-Hotel-Seepromenade von 0.7.5 mittels sysupgrade -n auf ~104 geschubst. Ist aber sauber im Config-Mode hochgekommen. Kurzes Zögern wegen dieser WAN&LAN-Geschichte, besonders beim WNDR3700 weil die Farben nicht stimmen :wink:

Schaut also sehr gut aus :grinning:

Viele Grüße
outlawx

Danke für’s Feedback!

Hmm, 17252-Hotel-Seepromenade sehe ich zwei, einen WR841v11 und einen WNDR3700? Den Netgear hast Du auf 0.7.9~105 gebracht, wo ich »rawhide« für den Autoupdater aktiviert habe und der Netgear steht auf »rawhide« für’s Autoupdate — ist das gewollt?!

Noch mal zur Warnung: »rawhide« fällt direkt aus dem Compiler, wird automatisch auf den FW-Server hochgeladen, inkl. signiertem Autoupdate-Manifest. Eine neue Version heißt nur, daß sie durchkompiliert hat … »rawhide« ins Autoupdate aufzunehmen hat den Hintergrund, daß ich mich so auf entsprechenden Knoten einloggen kann, den Knoten von z. B. »experimental« auf »rawhide« umstellen und damit binnen der nächsten Stunde oder so sehen, ob das Auto-Updating klappt (z. B. von 0.7.5~x, unserer Interims-FW auf CC-Basis, die ein Downgrade auf 0.7.4/BB ja nicht verkraftete und die im Kreis GT daher noch immer »guetersloh.freifunk.net« ausstrahlen). (Einloggen, per »vi /etc/config/autoupdater« den »branch« ändern, ausloggen, warten.)
Insofern freue ich mich, wenn Leute »auf Zuruf« Knoten auf »AU: rawhide« stellen – es erweitert das Testszenario bei kritischen Updaten wie auf 0.7.9/0.8.0), aber dauerhaft sollte kein Knoten das aktiviert haben. Grob jeder vierte bis dritte »rawhide«-Build ist für die Tonne und ggf. ›disruptiv‹ für den Knoten …

That said: warum “sysupgrade -n”? 0.7.5 => 0.7.9 sollte sauber funktionieren, auch wenn der FW-Stand von 0.7.5 deutlich älter ist als die letzten 0.7.4er Versionen. 0.7.9 basiert, wie 0.7.5, auf OpenWRT Chaos Calmer (CC) und sollte somit keine Probleme machen. Und ja, die Farben stimmen im Grunde nur bei (Einstiegs-) TP-Link-Geräten …

Sorry, da habe ich voreilig dazwischen gepfuscht. Diese 0.7.5er war (wie bereits irgendwo geschrieben) auf dem Gerät, weil Firmware-Server offline zu der Zeit und nichts besseres zur Hand. Eigentlich sollte der Knoten nur 2 Tage laufen.

Mit dem rawhide als update-Kanal habe ich mich vertan, lasse es für den Moment aber einfach mal so…wird schon kaputt gehen…

Warum “sysupgrade -n”: Da war diese Befürchtung, dass die alte Konfiguration sagt, ätsch ich will mich nicht mehr bzw. dann Config-Mode auf LAN-Port etc.
Aber ich habe jetzt natürlich verstanden, was du mit der ~104 nach experimental bezwecken wolltest: Damit diese Knoten, und der stand wohl auf experimental, dann mal ein Autoupdate erfahren.

Gute Nacht
outlawx

Moin,

ich habe eben auch zwei Knoten auf 0.7.9~105 gebracht …

  • 17194-FirmwareTest-c58 (0.7.9~96)
    …da habe ich über den Config-Modus ein Komplett-Upgrade gemacht und kam sauber im Config-Modus wieder hoch - Daten wieder eingetragen - läuft.
    MAC interresiert hier nicht :wink:

  • 17192-Jugendtreff-Papenberg (0.7.4~210_wrz)
    … ist leider mit "sysupgrade -v gluon-..." schiefgelaufen. :frowning:
    Am Switch ist MAC-Security eingeschaltet und über die MAC wird auch die IP zugewiesen. “Wiederbelebungsversuche” :ambulance: waren leider nicht erfolgreich, sodass ich mir das morgen doch vorort anschauen muss …

cul8er
Matthias

Sorry for that, aber das sind wichtige Erfahrungen — auch wenn leider für Euch doof :frowning: Hmm, ~105 sollte die HW-WAN-MAC setzen, welche leider != der bisherigen Gluon-v2015-WAN-MAC ist und auch != der WAN-MAC in Config-Mode (noch kommt da die LAN-MAC, so LAN vorhanden).

sigh Ich fürchte, ein letztes 0.7.4er Update, welches die aktuelle WAN-MAC speichert, damit 0.7.9 sie übernehmen kann, rückt näher und näher, um die Ausfälle zu minimieren.

Mit welcher Firmware soll ich denn meinen **TP-Link TL-WR841N/ND v11
** beglücken? Aktuell hat er die 0.7.4~118_gut drauf. Auf der FW Seite ist die v11 jedoch durchgestrichen. Ich habe die gluon-ffgt-0.7.4~210 gefunden.

Es ging ja in diesem Faden darum die kommende Firmware auf Basis von Gluon v2016.2.4 zu testen. Dafür ist jetzt als rawhide die 0.7.9 am Start welche dann final sicherlich als 0.8.x daherkommen wird.

Zum einen ging es um die Unterstützung neuer Geräte (z.B. 841n v12) und zum anderen um mögliche Upgradeprobleme (welche sich dann z.B. als geänderte MAC-Adressen WAN-seitig geäußert haben) zu erkennen und durch weitere Zwischen-Updates diese Probleme für den später folgenden Großteil zu beseitigen.

Von daher, wenn du denn testen willst, würde ich jetzt einmal ein normales sysupgrade auf experimental anstoßen und dann evtl. auf rawhide. In 0.7.4~210 sollte die WAN-MAC-Adresse fürs kommende Upgrade in der config hinterlegt werden, damit sie dann weiterverwendet werden kann.
Hier findest du alles weitere dazu Gluon und die WAN-MAC

ps bei der Firmware-Liste die erste durchgestrichene Spalte kann ich auch nicht so wirklich deuten, da vom 841er v11 ja momentan >60 Knoten am Start sind

Das war ein Bug beim Hinzufügen des v12, fixed. Sorry for the confusion.

Faktisch brauchen wir wohl Zwischenupdate mehr, die MAC wird ab 0.7.9/0.8.0 frühzeitig beim Upgrade gesichert, bevor sie verändert werden könnte :wink:

ijk
root@33332-freifunk-buschkoettersweg:/# sysupgrade https://firmware.4830.org/exp erimental/sysupgrade/gluon-ffgt-0.7.4~210-tp-link-tl-wr841n-nd-v11-sysupgrade.bi n Invalid image type. Image check 'platform_check_image' failed.
Und wenn ich das image per scp auf den Router kopieren möchte, habe ich nicht genug Platz. Was nu?
Sollte ich über die DHCP Adresse über Port 80 eine Antwort bekommen?

Filesystem                Size      Used Available Use% Mounted on
rootfs                  448.0K    244.0K    204.0K  54% /
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    14.1M    144.0K     13.9M   1% /tmp
/dev/mtdblock3          448.0K    244.0K    204.0K  54% /overlay
overlayfs:/overlay      448.0K    244.0K    204.0K  54% /
tmpfs                   512.0K         0    512.0K   0% /dev

Ich versuche es später noch mal mit /tmp