Treiberproblem bei TP-Link 1043 V4 in Firmware v2016.2.3 / v2016.2.4 ?

Hallo zusammen,

seit dem ich vor ein paar Wochen einige TP-Link 1043 V4 aufgestellt habe, fallen hier und da einige dieser Geräte aus.
Zunächst laufen sie einige Tage. Dann stellen die Kupfer-Netzwerkports ihren Dienst ein. Die betroffenen Knoten sind dann in der Regel offline. Falls MeshOnWifi aktiviert ist und ein Mesh per Funk besteht, laufen die Knoten abgesehen von den Kupferports weiter. D.h. sie bedienen die eingebuchten Clients dann über die Mesh-Verbindung. Per SSH eingeloggt kann ich sehen, das die Counter der Kabelschnittstellen stehen bleiben und nicht mehr hochzählen. Per “swconfig dev switch0 show | grep ‘link:’” wird artig angezeigt, das die Kabel gesteckt sind.
Nach einem Reboot ist natürlich erstmal wieder alles normal.

Ein Kandidat ist dieser hier:
https://karte.freifunk-muensterland.de/map/#!v:m;n:8416f95b92bc
Das Problem ist aber bereits an min. zwei weiteren TP-Link 1043 V4 aufgetreten.

Wie kann ich der Ursache beikommen?
Schnittstellen die zwar 0 Durchsatz haben, aber ansonsten keinen sichtbaren Fehler zeigen, könnten eine harte Nuss werden…

Kannst du dazu mal ein Issue im Gluon-Repo auf github aufmachen? Dort schauen mehr Leute rein die an der Entwicklung beteiligt sind. Am besten mit der Ausgabe von logread von einem der betreffenden Knoten.

1 „Gefällt mir“

Issue erstellt…

2 „Gefällt mir“

Neoraider hat gerade einen Backport dafür aus LEDE gemacht.

Ich denke also mit v2017.1.5 werden die V4er (und auch V5er) dann hoffentlich zuverlässig funktionieren.

4 „Gefällt mir“

Hallo Matthias, meine beiden TP-Link 1043 V4 sind leider auch einige male offline ohne das ich einen Grund finden kann (Domaine 37). Wann kommt die neue Software v2017 denn? Aktuell ist zum runterladen nur “gluon-ffmsd37-v2016.2.7+2.7.5-tp-link-tl-wr940n-v4.bin” da.

Und wenn der TP- Link auf “Autom. Updates aktiviert (stable)” steht, zieht er sich dann automatisch dieses update oder muss ich dass nachhalten?

Danke schon jetzt für die Antwort!

Ja, das passiert automatisch, aber erst sobald die 2017er-Firmware als „stable“ ausgeliefert wird. Alternativ @corny456 bitten, dass der die 2017er Firmware für die Domäne 37 (Everswinkel) baut und die Firmware auf den betroffenen Geräten händisch einspielen.

Die baut derzeit einfach noch nicht, weil der Fix für dieses Problem bisher nur im Master drin ist und da müssen wir schon wieder was an unserem Macadressenpaket ändern.

Es soll hoffentlich bald ein Backport in 2017.1.x kommen, den würde ich dir sofort bauen.

1 „Gefällt mir“

OK, danke, dann warte ich lieber noch bevor ist Beta Tester werde.:wink:

Um die Zeit zu überbrücken: Wenn ich bei einem TP-Link 1043 den Fernzugriff eingerichtet habe, kann ich darüber einen Neustart auslösen von Zuhause? Dann müsste ich nicht immer in den Pfarrkeller, um das System neu zu starten .

Danke!

Grundsätzlich geht das. Wenn der Bug des TP-Link 1043 V4 zuschlägt, fallen aber die Kabelgebundenen Anschlüsse des Routers aus. Du kommst dann an das Gerät nur noch ran, wenn es sich noch mit einem anderen Freifunk-Router per WLAN vermesht hat.

1 „Gefällt mir“

Du könntest aber übergangsweise einen Cronjob einrichten der die kiste Pauschal ein bis 2 mal am Tag rebootet.

# Reboot at 4:30am every day
# Note: To avoid infinite reboot loop, wait a minute
# and touch a file in /etc so clock will be set
# properly on reboot before cron starts.
30 4 * * * sleep 70 && touch /etc/banner && reboot
1 „Gefällt mir“

… oder per Cron einen Ping auf den Internet-Router machen und (nur) falls der fehlschlägt, die Kiste durchpusten lassen: :wink:
*/5 * * * * ping -c 1 {Router-IP} || sleep 70 && touch /etc/banner && reboot

{Router-IP} musst Du natürlich durch die IP deines Internet-Routers ersetzen.

2 „Gefällt mir“

http://gluon.readthedocs.io/en/v2017.1.x/releases/v2017.1.5.html

Bugfixes
[…]

  • Fix Ethernet stalls at high throughput on certain devices (#1101)

Das sollte es sein…

1 „Gefällt mir“

Jup :slight_smile:

1 „Gefällt mir“