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" <[email protected]
<mailto:[email 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
[email protected] <mailto:[email protected]>
https://lists.funkfeuer.at/mailman/listinfo/discuss
<https://lists.funkfeuer.at/mailman/listinfo/discuss>
--
Discuss mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/discuss
