[Discuss] [OT]: USB-Powercycle? OpenWRT+LTE-Stick+Tunnel/Verbindungsabbrüche.
Erich N. Pekarek
(spam-protected)
Mo Nov 14 18:11:23 CET 2016
Hallo Jakob!
Am 2016-11-14 um 17:34 schrieb Jakob Riepler:
>
> Hallo Erich!
>
Danke für Deine flotte Antwort!
>
> Prinzipiell habe ich gute Erfahrung damit gemacht, einfach
> regelmäßigen keep-alive traffic (zB einen http request) zu produzieren
> (hatte mal ein ähnliches Problem mit einem 3G Stick, der so was
> HiLink-ähnliches hatte).
>
ICMP-Keepalives macht der TL-WR1043ND sowieso - die sollten auch über
das Gateway laufen. Mein Reset-Script startet beispielsweise erst dann,
wenn diese Pings eine Weile lang unbeantwortet bleiben.
>
> Eine weitere Methode wäre, einen non-HiLink Firmware zu flashen (ich
> weiß aber gerade leider nicht, ob es eine für deinen Stick gibt.
> Müsste man mal nachschauen).
>
Das ist gar nicht erforderlich. Der Stick läuft auf Android. Die
AT-Befehle würden dort von einem AT-Emulator-Dienst interpretiert. Durch
Aufruf einer speziellen URL mittels curl lässt sich der Stick per Skript
in den Nur-Modem-Mode versetzen. Er verharrt auch darin, sofern er nicht
mittels AT-Befehl wieder in den Ethernet-Mode versetzt wird.
Aber manchmal ist er einfach nur "weg". (Denn das reset-script würde ihn
in den Modem-Mode versetzen und eine Reihe von AT-Befehlen absetzen, die
in quasi in den Werkszustand (Ethernet) versetzen; Würde das Skript bei
seinem Start ein Modem vorfinden, würde es davon ausgehen dasselbe tun.
Der Status in dem der Stick sich also befindet, wenn das Script ihn
nicht retten kann, muss ein anderer sein. Dass ein Powercycle genügt,
spricht für einen "indetermined lockup state".
> Wenn das alles nichts bringt, bieten viele USB Hosts (zumindest in PCs
> und Laptops. Ich weiß nicht, wie fortgeschritten selbige in Routern
> sind... Hab das bei meinem Laptop mal mit einem kleinen C Programm
> geschafft. "ganged usb power" sind glaub ich die richtigen Schlagworte
> dazu. Wenn ich wieder zu Hause bin kann ich dir mal einen Link
> schicken, wenn du willst und ich das wieder finde :P) die Möglichkeit,
> den USB Port zu deaktivieren.
>
Per Software ging das mittels echo 0 oder echo 1 nach
/sys/bus/usb/devices/[xyz]/authorized, um zumindest eine teilweise
Reinitialisierung der Treiber zu bewirken. Bis Kernel 3.6 konnte man
auch den Power Level einzelner Port setzen. Neuere Kernel lassen das
(direkt) offenbar nicht mehr zu. Man meines Wissens kann nur ein
Inactivity Timeout setzen, aber nur der Strom wird nur abgeschaltet,
wenn das Endgerät das auch zulässt.
Leider habe ich bis jetzt keine andere Methode gefunden. Links sind
willkommen.
> Wenn der Router das nicht kann (was vermutlich der Fall ist), ist der
> sinnvollste Weg wahrscheinlich ein Relay, mit dem man die Stromzufuhr
> unterbricht (am besten einfach mit einem GPIO Pin vom Router
> ansteuern) oder ein USB Hub, der Power switching beherrscht.
>
Naja, die Idee wäre weniger ein GPIO gewesen, denn dafür muss ich den
Router öffnen, als vielmehr ein USB-Zwischenstecker nach Art der
USB-Relays für Homeautomation.
Wie gesagt, bei 7-port Hubs werden Hubs kaskadiert. 4 Port - 1 Port + 4
Port.
Nehme ich einen 4-Port-Hub, schließe ein USB-Relay an einem der Ports an
und den zweiten Hub an einen weiteren Port, unterbreche jedoch dessen
Power-Lines über das Relay am ersten Port, hätte ich in etwa das, wonach
ich als Komplettlösung suche. Für den Fall, dass ich eine externe
Stromversorgung benötigte, müsste ein zweites, paralleles Relay auch
dessen Stromversorgung unterbrechen.
Nur, wundert es mich, dass es sowas nicht schon gibt. USB-Hubs mit
Kippschaltern pro Port gibt es ja auch... (Vielleicht doch ein
Knopfdruckroboter? ;-).
> LG Jakob
>
>
LG
Erich
> Am 14.11.2016 5:17 nachm. schrieb "Erich N. Pekarek" <(spam-protected)
> <mailto:(spam-protected)>>:
>
> Hallo Liste!
>
> Ich habe bei einer "mobilen Anwendung", die vielleicht auch einige
> von Euch (etwa im Zusammenhang mit einem Funkfeuer-Tunnel)
> interessieren könnte, ein Problem und suche dafür eine passende
> Lösung.
>
> Komponenten:
> TP-Link TL-WR1043NDv1 (Chaos Calmer 15.05.1 Eigenkompilat mittels
> Imagebuilder)
> ZTE MF831 LTE-Stick (Hofer-Version)
> Yesss-Simkarte mit LTE-Paket
> versuchsweise: USB HUB extern gespeist
>
> Anordnung:
> Der ZTE-Sick ist mit der Yesss-Sim-Karte bestückt und arbeitet
> werksseitig in einem HiLink-ähnlichen Ethernet Modus (19d2:1405).
> Am TL-WR1043ND scheint er als emuliertes Ethernet-Interface "usb0"
> mit der IP 192.168.0.1/24 <http://192.168.0.1/24> aufscheint. Die
> Firmware des Sticks ist stark beschnitten, daher kann man nur das
> Allernotwendigste einstellen. Der TL-WR1043ND bezieht seine IP,
> Gateway und DNS-Server mittels DHCP und nattet dieses
> NAT-Interface, das im A1-Netz (Yesss) ebenfalls genattet wird.
> (Grundsätzlich funktioniert das unter diesen Rahmenbedingungen
> soweit gut.)
> Der TL-WR1043ND stellt über OpenVPN einen Tunnel zu einem Server
> mit statischer IPv4-Adresse her. Alternativ wird Miredo genützt,
> um über das Teredo-Protokoll (UDP) IPv6-Konnektivität zu erlangen.
>
> Problem:
> Der ZTE-Stick scheint fallweise abzustürzen. Bei näherer
> Betrachtung steht dies anscheinend im Zusammenhang mit
> "Paket(de-)aktivierungen" oder eventuell sonstiger SIM-Aktivität.
> Steckt man den Stick ab und steckt ihn wieder an, ist der Router
> mit darauf laufendem Watchdog-Cronscript binnen weniger
> Augenblicke wieder online.
>
> Lösungsansatz:
> Der LTE-Stick ZTE MF831 wird grundsätzlich über sein Web-Interface
> angesteuert. Über eine im Internet recherchierbare URL kann man
> den Stick in einen Modem-Modus (19d2:0016) versetzen und mittels
> usb-serial-Modul als /dev/ttyUSB2 über AT-Befehle ansprechen.
> Darüber ließe er sich auch zurücksetzen (zumindest der Mobilteil
> mit AT+CFUN=1,1); anschließend kann man ihn mittels AT+ZCDRUN
> wieder in den Ethernet-Mode versetzen. Dazu gibt es Anleitungen im
> Netz, die ich befolgt habe. Das funktioniert eine Weile recht gut,
> aber manchmal hängt sich der Stick eben komplett auf, ohne, dass
> ich das (aus der Ferne) nachvollziehen kann.
> (Der Stick läuft auf Android und es gibt auch eine Möglichkeit adb
> mit root-shell über eine weitere URL zu aktivieren, aber das ist
> die von mir angestrebte Lösung. Auf diese Weise könnte man einen
> zum auf dem Router hinterlegten ssh-private-key ssh-public-key
> aufspielen und mittels ssh -lroot 192.168.0.1 'reboot' vorgehen.
> Das will ich so nicht und es ist fraglich, ob man den Stick so
> überhaupt noch erreicht, wenn er abzustürzen gedenkt.)
>
> Fragen:
> Hat jemand von Euch Erfahrung auf dem Gebiet? Welche Art
> Software-Reset könnte man noch versuchen und wie führt man den aus?
> Kann man in neueren Linux-Kerneln die Stromzufuhr zu einem
> bestimmten USB-Port per Software steuern? (Der Trick mit
> /sys/bus/usb/devices/usb1/authorized löst das Problem nicht.) Wenn
> ja, wie?
> Kennt jemand von Euch eine Art USB-Relay, mit dem man ein über
> Software steuerbares Äquivalent zum Anstecken/Abstecken
> durchführen kann (nein, kein Roboterarm, ;-)? Ich denke da an eine
> Anordnung aus USB-Hub mit integriertem Device (ansprechbar etwa
> über AT+Commands o.ä.) die ein Relay steuert, hinter dem eine
> weiterer kaskadierter,integrierter USB-Hub liegt. (Also nach Art
> eines 7-Port-Hubs nur mit Relay auf den Powerlines dazwischen).
> Auf Amazon und Ebay finde ich nichts, was meiner Vorstellung
> entspricht, dafür aber zahlreiche Einzelrelays.
>
> Bitte um sachdienliche Hinweise!
>
> Danke!
> LG
> Erich
>
> --
> Discuss mailing list
> (spam-protected) <mailto:(spam-protected)>
> https://lists.funkfeuer.at/mailman/listinfo/discuss
> <https://lists.funkfeuer.at/mailman/listinfo/discuss>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20161114/79d05de7/attachment.htm>
Mehr Informationen über die Mailingliste Discuss