[Erledigt] Nach Firmware-Update 7170 Probleme mit ether-wake

[krakel]

Hallo,
nachdem ich letztens ein Firmware-Update (Labor-Version 29.04.31-5938) auf meiner 7170 gemacht habe, läuft das ursprüngliche "etherwake" von tecchannel nicht mehr, da wohl die neue BusyBox Kernel 2.6 basiert ist? Dachte mir, macht ja nichts - es gibt ja jetzt in der neuen Busybox ein "ether-wake". Nur verhält es sich offensichtlich anders als das alte, meinen EPIA-LINUX-Rechner kann ich nicht mehr aufwecken. Ich habe mal zum Vergleich die Traces von einem "ether-wake", womit es funktioniert und das von der FritzBox!:

Dachte mir, macht ja nichts - es gibt ja jetzt in der neuen Busybox ein "ether-wake". Nur verhält es sich offensichtlich anders als das alte, meinen EPIA-LINUX-Rechner kann ich nicht mehr aufwecken. Ich habe hier mal zum Vergleich die Traces (mit Wireshark)von einem "ether-wake", womit es funktioniert und das von der FritzBox!:

Hiermit funktioniert - man sieht auch, dass die Destination-Adresse angegeben ist - das wird der Grund sein!

Ethernet II, Src: Intel_8b:c7:a1 (00:03:47:8b:c7:a1), Dst: Asiarock_78:aa:45 (00:13:8f:78:aa:45)
Destination: Asiarock_78:aa:45 (00:13:8f:78:aa:45)
Destination: Asiarock_78:aa:45 (00:13:8f:78:aa:45)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Intel_8b:c7:a1 (00:03:47:8b:c7:a1)
Address: Intel_8b:c7:a1 (00:03:47:8b:c7:a1)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: Unknown (0x0842)

******************************

Hiermit funktioniert es nicht, da ist ja auch keine konkrete Destination, sondern nur "Broadcast" angegeben. Warum macht etherwake dieses auf der Fritzbox?

Ethernet II, Src: Avm_3b:e4:89 (00:15:0c:3b:e4:89), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Destination: Broadcast (ff:ff:ff:ff:ff:ff)
Address: Broadcast (ff:ff:ff:ff:ff:ff)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
.... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
Source: Avm_3b:e4:89 (00:15:0c:3b:e4:89)
Address: Avm_3b:e4:89 (00:15:0c:3b:e4:89)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: Unknown (0x0842)

Ich würde mich freuen, wenn einem von Euch etwas dazu einfällt!
Selbstverständlich habe ich auf besagtem Linux-rechner bereits "ethtool -s eth0 wol g" und auch all die anderen Optionen eingestellt, funktionierte ja auch bisher, nur eben nach dem Firmware-Update nicht mehr!
Vielen Dank im voraus für Eure Hilfe.

Viele Grüße
krakel

 

[krakel]

Problem gelöst

Hallo,
der Vollständigkeit halber möchte ich Euch mitteilen, daß ich das Problem inzwischen gelöst habe. Meiner Meinung nach ist die ether-wake fehlerhaft. Daher habe ich die Source entsprechend angepaßt und mir eine neue Busybox gebaut. Bei der Gelegenheit habe ich gleich alle verfügbaren Funktionen in die Busybox mit reingenommen. Das Binary ist zwar über 600K, aber funktioniert prima und kann jede Menge mehr als die Original-Busybox.
Der Fehler lag tatsächlich daran, daß die Destination-Adresse nicht übertragen wurde. Die internen LAN-Chips auf den EPIA-Boards sind an der Stelle wohl etwas pingelig, denn bei anderen On-Board-Chips, z.B. ASRock-Mainboards, funktioniert das Original-Etherwake problemlos.

Viele Grüße
krakel

 

[olistudent]

Hi.
Kannst du einen Diff von deinen Änderungen posten? Das würde ich mir gerne mal anschauen.

MfG Oliver

 

[krakel]

Hallo olistudent,
gerne werde ich meine Überlegungen hier zum Besten geben:

Aus den Kommentaren in ../libbb/getopt32.c kann man folgendes entnehmen:

flags = getopt32(argc, argv, "rnug");

"r" will add 1 (bit 0)
"n" will add 2 (bit 1)
"u will add 4 (bit 2)
"g" will add 8 (bit 3)

and so on. You can also look at the return value as a bit
field and each option sets one bit.

In .../networking/ether-wake.c wird der Funktion getopt32 als Option-String "bi:" mitgegeben.

Da in der neuen Firmware der Fritzbox das Standard-Lan-Interface nicht mehr "eth0", sondern "lan" heißt, muß ich ether-wake mit der Option "-i lan" aufrufen. Daher setzt also getopt32 den Wert für "flags" auf 2. "flags" werden in ether-wake.c der Funktion get_fill übergeben und jetzt kommt der entscheidende Punkt:

static inline int get_fill(unsigned char *pkt, struct ether_addr *eaddr, int broadcast)
{
int offset, i;
unsigned char *station_addr = eaddr->ether_addr_octet;

if (broadcast)
memset(pkt+0, 0xff, 6);
else
memcpy(pkt, station_addr, 6);

"broadcast" ist der Wert für "flags", also in meinem Fall 2, da ich ja "-i lan" gesetzt hatte. Eigentlich wird aber hier abgefragt, ob das BROADCAST-Flag (also "-b") gesetzt wurde, was ja eigentlich "flags" = 1 bedeuten würde. Diese Unterscheidung wird aber nicht gemacht, so daß also immer, wenn ether-wake mit einer Option aufgerufen wird, die Destination-Adresse ff:ff:ff:ff:ff:ff ist, also implizit von einem Broadcast ausgegangen wird. Die NIC auf meinem EPIA-Board wertet aber offensichtlich auch diese Destination-Adresse aus und fühlt sich in diesem Fall nicht angesprochen, während andere NICs da nicht so genau sind.

Die Änderung, die ich nun vorgenommen habe, ist denkbar einfach:

static inline int get_fill(unsigned char *pkt, struct ether_addr *eaddr, int broadcast)
{
int offset, i;
unsigned char *station_addr = eaddr->ether_addr_octet;

if (broadcast==1) /* Nur wenn "flags" = 1, also "-b"-Option */
memset(pkt+0, 0xff, 6);
else
memcpy(pkt, station_addr, 6);

Bitte korrigiere mich, falls ich einen Denkfehler habe. Aber mit dieser kleinen Änderung läßt sich nun auch WOL mit geändertem Netz-Interface für meinen EPIA-Rechner durchführen.

Viele Grüße
krakel

 

[olistudent]

Danke für die ausführliche Antwort. Aber irgendwie werd ich aus den Kommentaren in der Datei nicht schlau. Da steht doch was von OPT_BROADCAST. Ist nur auskommentiert...
Mein Vorschlag für einen Patch befindet sich im Anhang.

MfG Oliver

 

[krakel]

Hallo olistudent,
habe auch noch einmal nach diese komischen Konstanten OPT_BROADCAST in den Sourcen geschaut, aber nichts gefunden. Dein Änderungsvorschlag sieht mir sehr vernünftig aus. Ich bin eben mehr Praktiker, habe einfach den Quien-McClusky angewendet und die logische UND-Verknüpfung schon vorweggenommen Nein, im Ernst - so wie Du es vorschlägst, sieht es gut aus und ist auch flexibel für weitere Abfragen bezüglich "flags".

By the way: Bist Du schon weitgekommen bei nfsd mit Kernel 2.6?

Nochmals vielen Dank für die konstruktive Hilfe und für Deine vielen Tips hier im Forum!

Viele Grüße
krakel

 

[olistudent]

Nein, ich hab nicht mehr danach geschaut.

MfG Oliver