Schau einmal in die Logfiles.
Möglicherweise ein DHCP Timeout, was Du mit einer festen IP am Pi begenen kannst.
Servus !
Moinsen,
Also wir reden doch von einem Zero !? Dann muss an der zweiten µUSB Buchse doch ein OTG Adapter oder ein USB Hub angeschlossen sein ?
GGF könnte man auch so etwas nutzen, wie einen HUB mit integrierter Netzwerkschnittstelle.
Und wichtig wäre es was der Auslöser ist. Du sagst der USB sei daran Schuld, wie kommst du darauf ?
Könnte es auch eine schwächelnde Stromversorgung sein ? Und nur die mittelbare Folge wäre dann das verlieren des Adapters, und dann als weitere Folge der Verbindungsverlust ?
Auch diese OTG Adapter µUSB auf USB Typ A haben nicht das ewige leben. Und das Zero so meine Erfahrungen reagiert sehr sehr eigen wenn man an dieser OTG Buchse rum macht, egal ob das mal was wackelt, oder eine Verbindung getrennt wird.
Moinsen,
Zwei Punkte, weil ohne 
kommen wir hier nicht einmal ansatzweise weiter.
Einmal die LOGs , ja in diesen findet man eine Erklärung in welcher Reihenfolge etwas abgelaufen ist, und nicht nur auf Vermutungen beruhend.
Und bei dem DLINK Ethernet Adapter dürfen wir uns sicherlich auch ein Modell heraussuchen ?
Wenn der Ethernet-Adapter ähnlich einem USB-Stick ist, also eine starre Verbindung zum OTG Adapter besteht, hier nun auch wieder was nur die oder du wissen kannst, dann besteht immer eine mechanische Last auf dem OTG-Adapter und der Buchse auf der Platine. Also wenn kein Stückchen Kabel zwischen der USB Buchse des Pi und dem eigentlichen DLINK Adapter dazwischen ist, kann es auch sein das die Buchse schon mechanisch ausgeleiert ist.
Und beim Thema Stromversorgung, das Zero ist um einiges Toleranter als die größeren Modelle, und wenn es dann knapp wird, kann es durchaus sein das sich ein USB Gerät abmeldet, weil die Spannung zu gering ist, aber das Zero deswegen noch weiter läuft. Aber auch hier ein Blick ins LOG ob irgendwo eine solche Warnmeldung gibt: cat /var/log/syslog* | grep voltage
Hallo Dodger,
Müsste bei einem Stromproblem nicht der komplette Raspi abstürzen?
Der OTG Adapter ist dich passiv, oder?
Nö. Das hängt vom Umfang des Stromproblems ab.
Diese Deaktivieren und Reaktivieren zeichnet das Betriebssystem fein säuberlich auf. Kannst Du in der aktuellen Sitzung über dmesg abrufen. Oder ansonsten in den Log-Dateien (deswegen auch die Frage von RTFM dazu).
Dieses Deaktivieren und Reaktivieren verbraucht dann auch Ressourcen, die noch mehr Strom verbrauchen. Du kannst damit in einen Teufelskreis geraten: Die CPU ist zu annähernd 100 % mit diesem De- und Reaktivieren beschäftigt, dass sonst nichts mehr zu laufen scheint.
Zu den Diensten. Am häufigsten sind betroffen:
In den Log-Dateien findest Du dann endlose Wiederholungen der versuchten Einbindung / Abmeldung der immer wieder gleichen Hardware.
Die häufigste Ursache sind Probleme des Netzteils (z.B. Verwendung eines Handy-Ladekabels, Alterung des Netzteils bzw. der verbauten Kondensatoren), Kontaktprobleme (Oxidation).
Wenn ich hier ein paar Deiner Probleme identifiziert habe, und Dich die Thematik näher interessiert, dann wirf mal einen Blick in meine Linkliste zum Thema "Mysterium". Dort sind 34 Links zu solchen Effekten.
Beste Grüße
Andreas
In die Meldungen des Kernels mit dmesg -T o.ä. zu schauen ist ein guter Ansatz. Andere nützliche Infos kann man allgem. unter /var/log finden. Dein USB LAN Adapter ist ja laut Eintrag im Logfile ein USB 3 Adapter, es wäre nicht das erste Mal, dass es bei der Kombination von USB 3 Geräten an USB 2 Ports evtl. zu Problemen kommen kann. Vielleicht kannst Du mit einem anderem USB2 zu LAN Adapter mal testen ob da ein ähnliches Verhalten auftritt.
Das ist das Ergebnis des Fehlers. Die Ursache liegt davor, vor dem ersten "Failed to read ..."
https://github.com/JMLX42/AX88179_178A_Linux_Driver hat Dein Internet wohl nicht gefunden.
Servus !
Hallo Dodger ,
hier hat jemand eine "Problemlösung" für den buggy Treiber mit dem Programm usbreset gefunden. Ist vielleicht eine Möglichkeit, wenn man das automatisiert ablaufen lässt. z.B. über Watchdog, Ping und Repair-Binary (siehe man watchdog und man watchdog.conf) oder über ein selbstprogrammiertes Ping-Script.
Gruß Martin
Moinsen,
Ich verstehe nicht die Grundhaltung. Erst nimmt einen OTG Adapter daher, der ohnehin nicht der stabilste ist, dann schlägt man sich mit einem Treiber herum, und verplempert viel viel Zeit mit Erklärungen und Begründungen warum nicht.
Ich hatte in meinem Post #4 schon eine Alternative aufgezeigt, die einfach nur in Anstecken und funktioniert enden wird. Klar ist der Platzbedarf möglicher Weise etwas größer, was ich auch nicht bestreiten will, aber mehr als einen Teil von 100MBIT /SEK Netto geht dort ohnehin nicht durch, weil der USB nicht mehr schafft. Warum dann diese Kopfstände mit einem externen USB-to-Ethernet Adapter der wahrscheinlich auch noch mehr Strom verbrauchen dürfte, einen eigen Treiber zum Nachinstallieren benötigt, als diese Fertiglösung zum "Anstecken" !? Plug & Play... gibt es auch beim PICO und bei LINUX
