Wake on Lan (WOL) mit em bei 6.3 kaputt gemacht?

max93

Well-Known Member
Hallo Leute!

Endlich (</ironie>) habe ich mal wieder eine Merkwürdigkeit: Seit ewigen Zeiten läuft mein Server (Tyan Board mit em NICs on Board) unter FreeBSD und mindestens seit 6.2-p0 schalte ich den Server mit shutdown -p now aus und konnte ihn von meiner pfSense aus per WOL wiederbeleben. Da klappte 100% zuverlässig.

Vorgestern Abend habe ich auf 6.3 aktualisiert und seither kann ich ihn per WOL nicht mehr aufwecken. Kann jemand vom FreeBSD Team was dran kaputt gemacht haben? Ideen, Vorschläge?

Danke & Ciao.
Markus Mann
];-)
 
imho gibt es in freebsd bisher kein WOL support. das framework hierfür wurde erst kürzlich in CURRENT eingeführt. Der support für einzelne karten steht noch aus. Dass es vorher funktioniert hat würde ich eher als zufall bezeichnen :)
 
WoL hat doch eigentlich nichts mit dem OS des Computers zu tun?

Im BIOS irgendwie was geändert? Z.b die "Wake Up" Sachen?

MfG
 
WoL hat doch eigentlich nichts mit dem OS des Computers zu tun?
Das ist ein weitverbreiteter Irrtum, da die Netzwerkkarte beim herunterfahren des Os dafür konfiguriert wird. Das hat nicht nur was mit dem Bios zu tun.

Soweit ich weiß wurde auch erst kürzlich wol in FreeBSD aufgenommen, oder irre ich mich da?
 
Hallo s-tlk,

Das ist ein weitverbreiteter Irrtum, da die Netzwerkkarte beim herunterfahren des Os dafür konfiguriert wird. Das hat nicht nur was mit dem Bios zu tun.
Hast Du da mal einen Link.
Alles, was ich bis jetzt gefunden habe, besagt, dass das vollkommen unabhängig vom OS ist.
Die Netzwerkkarte muß in Standby bleiben und WOL beherrschen, dann reicht eine Software, die die magic pakets sendet und der Rechner springt wieder an.

Viele Grüße

JueDan
 
richtig, die karte muss im standby bleiben. d.h. das os darf die karte beim shutdown nicht komplett abschalten und evtl. die karte so configurieren, dass sie auf z.b. magic packets reagiert (es gibt diverse wol möglichkeiten)
 
Hallo max93,

schau doch mal nach, ob der Rechner wirklich Standby ist. Meist leuchtet an der Netzwerkkarte eine LED.
Die man-page zu shutdown -p besagt:
The system is halted and the power is turned off (hardware support required) at the specified time.
. Probier mal mit acpiconf -s 5, ob es damit besser funktioniert.

Viele Grüße

JueDan
 
Hallo!

schau doch mal nach, ob der Rechner wirklich Standby ist. Meist leuchtet an der Netzwerkkarte eine LED.
Check! (Soll heißen: Lämpchen leuchtet).

Probier mal mit acpiconf -s 5, ob es damit besser funktioniert.
Ändert leider auch nichts.

Das ist echt unbefriedigend. Wieso wird das kaputt gemacht, wenn es doch schon so gut geklappt hat? Ich versuch mal den em-Treiber von 6.2 (in der if_em.c kommt ein Abschnitt über WOL vor, vielleicht hat ja dort jemand was kaputtoptimiert).

Edit: Den Treiber von 6.2 kann ich nicht probieren, die haben da ganz schön umgebaut seit 6.2 und ich habe keine Ahnung wie ich ihn dazu bringe den Kern damit zu bauen.

Danke & Ciao.
Markus Mann
];-)
 
Zuletzt bearbeitet:
Mach's dir doch einfach und fahre den Rechner mit shutdown -p now runter, sondern einfach nur mit shutdown -h now. Dann drückst du den Reset-Taster und dann die Power-Taste. Wenn der POST anläuft sollte alles reseted sein und dann solltest du auch WOL haben.

Und dann einen PR schreiben oder vll. auch ne Mail direkt an Jack Vogel (der em(4)-Treiberentwickler bei Intel).

Übrigens wird diese Funktion, die NIC beim runterfahren des Rechners wahlweise richtig schlafen zu legen oder auf WOL aktiv warten zu lassen von Intel im Windows-Treiber sogar "verkauft". Nämlich als Stromsparmodus. Was imho auch verständlich ist. Wer möchte schon, dass die Netzwerkkarte im Notebook langsam aber sicher den Akku leersaugt (auch wenn's nur wenig Energiebedarf ist). Unter FreeBSD wäre es natürlich schön, wenn man über ein sysctl das Verhalten ebenfalls steuern könnte...
 
Hallo,

bei den Intel-Karten gibt's ein DOS-Konfigurationswerkzeug (mindestens bei den fxp(4)), mit dem kann man "legacy wakup" konfigurieren.
So funktioniert WoL oft, wenn der Betriebssystem-Treiber dieses Feature danach in Ruhe lässt.

Ich hatte nach einem FreeBSD-Upgrade auch schon mal ein ähnliches Problem, jedoch lag das am aufgeweckenden PC und nicht an dem PC, der aufgeweckt werden sollte.
Eine Änderung im bge(4) hatte damals dazu geführt, dass keine WoL-Pakete mehr verschickt werden konnte. Hier tippe ich auf die Checksum-Offload.
Testweise kann man das mal abschalten.
 
Hallo,

gerade habe ich mir das noch angeschaut, da meine em(4) auch nicht erwachen wollen unter 6.3.

Normalerweise kommt man mit Strg-S in das Setup der Karte beim Booten (Post).

Hier kann man Legacy-Wakeup einschalten:
cnfsetup.gif


Bei meiner Karte war dieser Menüpunkt jedoch auch nicht nach einem Firmware-Update vorhanden. Früher habe ich das in jedem Fall mal so gemacht.
 
Hallo!

Das mit dem Legacy-Wakeup wäre die eleganteste Lösung, muss ich mal gucken, ob das bei meiner geht (ist ein Onboard 8xxxx irgendwas Chip). Die Lösung mit Reset-Knopf und dann per Power-Knopf abschalten ist da etwas unbequem und außerdem kann ich mich erinnern, dass der Rechner noch nie per WoL aufgewacht ist, wenn ich ihn mit dem Powerknopf ausgeschaltet hab.

Ich kann da am Wochenende sicherlich mal alles ausprobieren und dann melde ich mich wieder.

Danke!
Markus Mann
];-)
 
Hallo zusammen,

da es mehrere Threads zu WOL gibt, habe ich einfach mal den genommen, mit dem neustem Post.
Ich habe also das gleiche Problem: Meine Server wird nicht wach :mad:

Technisch klappt das WOL auf der Maschine einwandfrei, zumindest wenn Windows den PC heruntergefahren hat. Nach einem shutdown vom FreeNAS muss ich den Knopf drücken. Ist ziemlich doof, da dieser Server im Keller steht.

Dass die Funktion herausgenommen wurde, bzw nicht supportet wird, habe ich gelesen.

Aber wie ist der aktuelle Stand der Dinge? Läuft es in der 7er wieder?
 
Mein Notebook wacht auf, allerdings nur wenn es an einem Netzteil hängt. Man erkennt das gut daran, dass die LED am RJ-45 Stecker leuchtet obwohl das Gerät ausgeschaltet ist.
 
Ich haben meinen Computer erst vor ein paar Wochen auf 6.3 aktualisiert und habe nun das selbe Problem. Scheint noch immer keine Lösung dafür zu geben oder?
 
An der Stelle muss man mal zwei Probleme klar unterscheiden:

  1. Ein FreeBSD-PC wird nicht durch ein WoL-Paket aufgeweckt
  2. Man kann mit einem FreeBSD-Rechner keine anderen Rechner aufwecken


Zum 1. Problem:
Damit der Rechner aufgeweckt werden kann, müssen einige Teile mitspielen
  • Die Netzwekkarte muss entweder per Käbelchen verbunden sein oder das Aufwecken via PCI 2.2
  • Das Mainboard muss mitspielen, d.h. dessen Hardware muss mitspielen und im BIOS-Setup muss dies aktiviert sein
  • Das Betriebssystem muss die Netzwerkkarte beim Abschalten in einem bestimmten Zustand lassen bzw. diesen initialisieren. Dieser ist mindestens je nach verwendeter Technik (WoL-Kabel oder PCI 2.2) unterschiedlich.

Der letzte Punkt ist bei FreeBSD genau das Problem. FreeBSD interessiert sich nicht für WoL und hinterlässt die Netzwerkkarten auch nicht in einem dafür sinnvollen Zustand.
Hierfür ist gerade ein Framework in der Entwicklung/Erprobung: http://stsp.name/wol/

Bei Intel Pro/100 Chips fxp(4) kann man sich aber auch damit behelfen, dass man den "Legacy Wakeup Mode" in deren BIOS-Setup (Strg-S) aktiviert. Hierdurch sind die hart auf WoL eingestellt und bedürfen keines Eingriffes mehr durch das Betriebssystem. Dieser Trick funktioniert aber nur, wenn das Mainboard via PCI 2.2-Verfahren und nicht per WoL-Kabel.

Zum 2. Problem:
Seit FreeBSD 6.3 (oder früheren RELENG_6?) kann man unter FreeBSD keine WoL-Packages mehr senden.
Die von einem Wake-On-LAN-Tool erzeugten speziellen Pakete kommen am Ende nicht auf's Kabel.
Ich tippe darauf, dass hier irgendwie das Hardware-Offloading diese Pakete verwirft.

Im Einsatz mit FreeBSD habe ich em, bge, ti, fxp alle negativ getestet, wobei diese auch alle Hardware-Offloading verwenden.

Lediglich bei m0n0wall funktioniert das Senden von WoL-Paketen, obwohl die auch FreeBSD 6.x einsetzen (m0n0wall 1.3x). Ich gehe davon aus, dass die sis(4) Netzwerkkarten der Grund sind, welche kein Offloading beherrschen ... oder es gibt einen Unterschied im Kernel.
 
Zuletzt bearbeitet:
Zurück
Oben