[gelöst] Probleme mit Wake-On-LAN

[Dogge]

Ich habe an meinem Router (Fritzbox) ein altes Laptop hängen, auf das ich per rsync und SSH meine Backups schiebe. Mittlerweile kann ich es leider nicht mehr per Wake-On-LAN aufwecken. Leider ist mir nicht bewusst, etwas geändert zu haben was das bewirken könnte.

Wenn ich den Befehl zum Aufwachen sende, möchte das Laptop aufwachen (ich höre die Festplatte anfahren) aber es scheint irgendwo abzubrechen denn es reagiert nicht auf Pings und wenn ich später nochmal den Aufwachbefehl sende höre ich wieder das typische Anfahren der Festplatte.

Es handelt sich um ein Laptop mit Debian Wheezy. Heruntergefahren wird es nicht, sonder in pm-suspend-hybrid geschickt.

interfaces

Code: Alles auswählen

allow-hotplug eth0
iface eth0 inet static
	address	192.168.178.22
	netmask	255.255.255.0
	gateway	192.168.178.1
	post-up /sbin/ethtool -s eth0 wol g
	pre-down /sbin/ethtool -s eth0 wol g

ethtool eth0

Code: Alles auswählen

Settings for eth0:
	Supported ports: [ TP MII ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	Supported pause frame use: No
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	Advertised pause frame use: Symmetric Receive-only
	Advertised auto-negotiation: Yes
	Link partner advertised link modes:  10baseT/Half 10baseT/Full 
	                                     100baseT/Half 100baseT/Full 
	Link partner advertised pause frame use: Symmetric Receive-only
	Link partner advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: MII
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: pumbg
	Wake-on: g
	Current message level: 0x00000033 (51)
			       drv probe ifdown ifup
	Link detected: yes

Hat jemand eine Idee woran das liegen könnte oder in welchem Log ich dazu Informationen bekommen könnte?

[Dogge]

Heute hat die Kiste (beim zweiten Versuch) mal wieder auf Wake-On-LAN reagiert. Hat jemand eine Idee was da schief laufen könnte? Wird vielleicht wegen irgendwelchem Zeug (laptop-mod, acpi) die Netzwerkkarte so beeinflusst, dass sie beim Starten keine Verbindung herstellt? Ohne Netzwerkzugriff über SSH oder andere Dienste wird nämlich der Server wieder in StandBy geschickt. Das würde ja erklären, warum ich öfter höre, dass es anläuft aber dann über das Netz keinen Zugriff bekomme.

Hier das Script zum Schlafenschicken (aufgerufen über /etc/rc.local):

Code: Alles auswählen

cat /usr/local/bin/auto_suspend 
#!/bin/bash

# Zweck:
#  System nach einer Karenzzeit ohne SSH-Zugriffe automatisch in den Schlaf (STR oder STD) versetzen
#  Sinnvoll ist es, den Rechner per Wake_On_LAN wecken zu lassen, sobald das System gebraucht wird.

# Dieses Skript prüft alle $CHECK_INTERVALL Sekunden nach, ob 
#  auf diesen Rechner per SSH zugegriffen wird
# Ist dies nicht der Fall, so wird das System (ca.) $SUSPEND_DELAY Sekunden nach 
#  dem Ende des letzten SSH-Zugriffs per 
#   /usr/sbin/pm-suspend    wenn SUSPEND_OR_HIBERNATE='SUSPEND'
#   /usr/sbin/pm-hibernate  wenn SUSPEND_OR_HIBERNATE='HIBERNATE'
#  in den Schlaf versetzt
# Erfolgt ein SSH-Zugriff in der "Karenzzeit" $SUSPEND_DELAY,
#  so wird der Zähler zurückgesetzt, sodass wieder erst $SUSPEND_DELAY Sekunden nach 
#  dem Ende des letzten SSH-Zugriffs das System in den Schlaf versetzt wird
# Das Skript sollte idealerweise per rc.local gestartet werden.
# Das Skript läuft nach RESUME (Wiederaufwachen) weiter.



#-----------------ANPASSEN!---------------#
# entkommentieren, um zu sehen, was das Skript macht. Dann sollte man das Skript aber manuell starten!
#set -x

#-----------------ANPASSEN!---------------#
# wie oft (in Sekunden) soll kontrolliert werden, ob (noch) aktive SSH-Sitzungen vorhanden sind?
CHECK_INTERVALL=30

#-----------------ANPASSEN!---------------#
# Anzahl Sekunden, die vergehen sollten ab Ende der letzten SSH-Sitzung
#  bevor in SUSPEND/HIBERNATE gewechselt wird
SUSPEND_DELAY=900

#-----------------ANPASSEN!---------------#
# SUSPEND=Suspend_To_RAM (S3)
# HIBERNATE=Suspend_To_Disk (S4)
SUSPEND_OR_HIBERNATE='SUSPEND'



#-----------------NICHT AENDERN!----------#
# Variablen für letzten Zeitpunkt ohne SSH-Sitzung(en) und aktuellen Zeitpunkt
LAST_NO_SSH_TIMESTAMP='x'
CURRENT_TIMESTAMP='x'

sleep 600

while true
do
 # aktuellen Zeitpunkt speichern
 CURRENT_TIMESTAMP=$(date +%s)
 
 # Sind (noch) Gast-SSH-Sessions aktiv?
 # nachdem die letzte SSH-Session beendet wurde, wartet der SSHD noch eine Zeit lang im STATE=TIME_WAIT darauf, ob noch Pakete ankommen
 # wir zählen die Anzahl der SSH-Sitzungen
 SSH_SESSIONS=$(netstat -utp | grep -E '(dlna|ssh|smb|tvheadend)' | wc -l)
 
 if [ $SSH_SESSIONS -ge 1 ]
 then
   # weil SSH-Sitzungen (noch) aktiv sind, LAST_NO_SSH_TIMESTAMP "leeren" bzw. "kennzeichnen"
   LAST_NO_SSH_TIMESTAMP='x'
 else
  # da keine SSH-Session (mehr) aktiv
  # 
  # wenn schon ein älterer TIMESTAMP in LAST_NO_SSH_TIMESTAMP steht, wollen wir diesen nicht überschreiben
  #   daher Abfrage $LAST_NO_SSH_TIMESTAMP == 'x'
  if [ $LAST_NO_SSH_TIMESTAMP == 'x' ]
  then  
   # da noch kein TIMESTAMP in LAST_NO_SSH_TIMESTAMP steht
   #   speichere aktuellen TIMESTAMP in LAST_NO_SSH_TIMESTAMP !
   LAST_NO_SSH_TIMESTAMP=$CURRENT_TIMESTAMP
  fi
   # wenn seit mind. $SUSPEND_DELAY [Sekunden] keine SSH-Session aktiv war, 
   #   dann SUSPEND/HIBERNATE gemaess Angabe in $SUSPEND_OR_HIBERNATE
   if [ $(($CURRENT_TIMESTAMP-$LAST_NO_SSH_TIMESTAMP)) -gt $SUSPEND_DELAY ]
   then
      case $SUSPEND_OR_HIBERNATE in
          SUSPEND)
                 /usr/sbin/pm-suspend-hybrid
                 ;;
          HIBERNATE)
                 /usr/sbin/pm-hibernate
                 ;;
                  *)
                 echo "Unbekannte Option"
                 ;;
      esac
   fi 
 fi
 
 sleep $CHECK_INTERVALL
done 

Das Script habe ich mal auf wiki.ubuntuusers.de gefunden und minimal auf meine Zwecke angepasst.

[Dogge]

Heute klappte das Aufwecken komischerweise auf Anhieb. Seltsam, weil es die letzten 2 Wochen einfach nicht funktionierte. Nach dem einloggen über SSH bekam ich dort aber folgende Meldung:

Code: Alles auswählen

Message from syslogd@backup at May 17 13:29:10 ...
 kernel:[71069.198432] Uhhuh. NMI received for unknown reason 3c on CPU 0.

Message from syslogd@backup at May 17 13:29:10 ...
 kernel:[71069.198532] Do you have a strange power saving mode enabled?

Message from syslogd@backup at May 17 13:29:10 ...
 kernel:[71069.198622] Dazed and confused, but trying to continue

Ich weiß nicht ob die etwas mit dem Problem zu tun hat und was ich mit ihr anfangen soll. Was könnte denn ein "strange power saving mode" sein?

[smutbert]

niesommer hatte dieselben Meldungen:
viewtopic.php?f=33&t=148569&start=30

Da waren es Probleme die der Kernel mit der Hardware hatte oder oder und ein defektes Netzwerkkabel. Dementsprechend würde ich dir raten, als erstes ein anderes Netzwerkkabel und den Kernel aus den Backports zu testen. (Ein paar andere Sachen, die du probieren könntest, wenn das nichts hilft, habe ich dort auch gepostet, aber das wäre nur Trial&Error…)

[Dogge]

Defektes Netzwerkkabel könnte auch die Probleme mit dem Wake-On-LAN erklären. Die Kiste rennt seit dem Sommer mit Wheezy-Kerneln, von daher schaue ich erst mal ob ich ein Netzwerkkabel rumfliegen habe.

[Dogge]

Mal ein kurzer Abriss was sich bisher getan hat:
Bevor ich dazu kam nach einem Netzwerkkabel zu kramen hat WOL plötzlich wieder problemlos funktioniert, daher habe ich jetzt erst mal nichts unternommen. Never touch...
Die obskure Meldung bzgl. Stromsparmechanismen trat auch nicht wieder auf.
Derzeit vermute ich, dass die Probleme beim Starten aus dem Suspend evtl. von einer defekten USB-Festplatte kamen. Ich habe, mittlerweile nämlich mit einer Platte viele Probleme gehabt (wurde während der Datenübertragung mit rsync ausgehängt und danach als neues Device erkannt [vorher sdc, danach sdd] und ließ sich nicht mehr mounten). Ich habe die Daten auf eine neue USB-Festplatte, die ich noch auf Lager hatte übertragen und werde jetzt weiter beobachten.

Sollte ich erneut Probleme mit WOL, oder diese seltsame Meldung bekommen, habe ich ja diesen Thread im Hinterkopf und werde das Kabel oder den Kernel tauschen.

[Dogge]

Nachdem es einige Tage einfach ohne Probleme tat, was es sollte ging es dann irgendwann wieder los. Daraufhin habe ich dann das Netzwerkkabel getauscht -> keine Besserung. Anschließend den 3.14er Kernel aus den Backports installiert -> keine Besserung.

Mittlerweile habe ich aber festgestellt, dass das Problem ein anderes ist als ursprünglich vermutet. Als ich das Notebook (Server) aufklappte, war es aktiv. D.h. das aufwachen ist nicht das Problem sondern das Netzwerk. Die Kiste wacht zwar auf, ist aber über das Netzwerk nicht erreichbar.

Lt. ifconfig hat sich die Kiste ihre statische IP geholt, aber es kommt nicht mal ein Ping vom Server zur FritzBox durch (oder umgekehrt). Ich hab mal die üblichen Verdächtigen wie syslog etc. angeschaut, aber da ist mir nichts aufgefallen.
Vielleicht weiß ich auch nur nicht in welchem Log ich was zur Ursache finden könnte, bzw. nach was ich suchen sollte. Kann mir da jemand einen Tipp bzgl. logs oder möglicher Ursachen geben?

[Dogge]

Das könnte etwas damit zu tun haben:

Code: Alles auswählen

/var/log/dmesg:[   10.687925] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
/var/log/dmesg:[   10.689034] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
/var/log/dmesg:[   10.689956] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
/var/log/dmesg:[   10.690865] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
/var/log/dmesg:[   10.693074] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
/var/log/dmesg:[   10.694155] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
/var/log/dmesg:[   10.695075] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
/var/log/dmesg:[   10.696014] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
/var/log/dmesg.0:[    1.074699] r8169 0000:06:00.0 eth0: RTL8102e at 0xffffc9000067e000, 88:ae:1d:31:cd:17, XID 04e00
000 IRQ 40

kern.log:

Code: Alles auswählen

Jun 15 11:45:50 backup kernel: [111564.374644] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111564.375241] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111564.375835] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111564.376432] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111564.376984] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111564.377532] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111564.378085] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111564.378633] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111564.379231] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111565.177933] r8169 0000:06:00.0 eth0: rtl_phy_reset_cond == 1 (loop: 100, delay: 1).
Jun 15 11:45:50 backup kernel: [111565.178503] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111565.179146] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111565.179694] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 11:45:50 backup kernel: [111565.180242] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:34 backup kernel: [111570.865278] r8169 0000:06:00.0 eth0: RTL8102e at 0xffffc9002194a000, 88:ae:1d:31:cd:17, XID 04e00000 IRQ 42
Jun 15 12:00:36 backup kernel: [111572.912954] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:36 backup kernel: [111572.914685] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:36 backup kernel: [111572.916320] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:36 backup kernel: [111572.917731] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:36 backup kernel: [111572.920606] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:36 backup kernel: [111572.922272] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:36 backup kernel: [111572.923681] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:36 backup kernel: [111572.925153] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:37 backup kernel: [111573.341464] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:37 backup kernel: [111573.343263] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:37 backup kernel: [111573.344743] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:37 backup kernel: [111573.346158] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:37 backup kernel: [111573.349379] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:37 backup kernel: [111573.350948] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:37 backup kernel: [111573.352373] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).
Jun 15 12:00:37 backup kernel: [111573.353950] r8169 0000:06:00.0 eth0: rtl_phyar_cond == 1 (loop: 20, delay: 25).

Kann damit jemand was anfangen?

[Dogge]

Ok, scheinbar ist der Kerneltreiber nicht das Wahre [1][2]. Ich habe jetzt mal, wie in forums.debian.net beschrieben, das Modul r8169 entladen und das Modul r8101 gebaut. Das Netzwerk funktioniert immerhin schon mal mit dem neuen Modul, d.h. ab jetzt heißt es abwarten ob das Problem Geschichte ist oder weiterhin auftritt.

[1] http://www.linuxquestions.org/questions ... 175484398/
[2] http://forums.debian.net/viewtopic.php?f=16&t=42324

[Dogge]

Falls jemand noch den Monolog verfolgt: Auch das Kernelmodul von der Realtek-Seite brachte keine Besserung.

Aus Verzweiflung habe ich einfach meinen Chromebook Acer C720 Kernel (derzeit 3.14.7) installiert. Komischerweise scheint das Problem behoben. Ich hatte jetzt schon ca. 10 Aufwachvorgänge ohne Probleme und ich war nun 6 Tage auf Dienstreise und es wachte sofort auf. Es hat zwar auch häufig bei täglichem Aufwecken Fehlschläge gegeben, aber wenn ich länger weg war eigentlich immer.

Wundert mich jetzt etwas. Der Kernel ist nichts anderes als der Vanilla-Kernel von kernel.org mit diesen Patches um ein Acer C720 Touchpad zu unterstützen. Die Config habe ich beim ersten Bau vom damaligen Testing-Kernel (ich glaube es war 3.11.x) übernommen und nur die Chrome-OS Module eingebunden. Bei neuen Modulen habe ich immer die Vorgabe übernommen.

Von daher dürften sich meine Kernel nicht groß von den Debian-Kerneln unterscheiden. Debian entfernt zwar Binärblobs aus dem Upstream, aber durch die firmware-* Pakete sollte doch dann das gleiche rauskommen. Ich werde das mal weiterhin beobachten, aber bisher sieht es aus als wäre das Problem gelöst. Auch wenn es mich etwas irritiert.

[smutbert]

zumindest einer verfolgt Deinen Monoglog (hatte einfach nichts beizusteuern)

[Dogge]

zumindest einer verfolgt Deinen Monoglog aber ich konnte einfach nichts beisteuern

Dann komme ich mir immerhin nicht vor wie der verrückte Kerl, der in der Innenstadt predigt ohne dass jemand Notiz davon nimmt.

[Dogge]

Code: Alles auswählen

uptime
 19:24:38 up 41 days, 14 min,  1 user,  load average: 0,60, 0,81, 0,39

Da die Kiste mit selbstgebautem Kernel keine Probleme mehr macht, markiere ich das als gelöst.