7
Wake on LAN bei Geräten die hinter Telefonen angeschlossen sind
Gute Morgen
hoffentlich sind alle gut erholt aus dem Wochenende gekommen
.
Wir haben hier ein Problem mit der Wake on LAN Funktion von Client-Rechnern die "hinter" einem Telefon angeschlossen sind, diese erhalten das "Magic Paket" nicht und fahren bei einer Anforderung nicht hoch.
Wir haben bei uns stellenweise die Telefone (Siemens HFA 15/20/40) so konfiguriert, dass an man einen Client an dem LAN Port des Telefons anschließen kann (das funktioniert auch Tadellos) - allerdings verhält sich das Telefon wohl scheinbar nicht wie ein Switch, die MAC Adresse des Clients erkennt der Switch nicht direkt (wenn ich dort den Client via "show mac-address xyz" suche, findet er diesen nicht) und ich denke auch das daher das Problem auftritt.
Was wir bereits getestet haben, das man das WOL Signal an das Telefon absetzt (hat natürlich nicht funktioniert), gibt es dafür evtl. Lösungen oder wie habt Ihr solche Sachen gelöst - oder ist es evtl. nur ein Bug der Telefone?
hoffentlich sind alle gut erholt aus dem Wochenende gekommen
.Wir haben hier ein Problem mit der Wake on LAN Funktion von Client-Rechnern die "hinter" einem Telefon angeschlossen sind, diese erhalten das "Magic Paket" nicht und fahren bei einer Anforderung nicht hoch.
Wir haben bei uns stellenweise die Telefone (Siemens HFA 15/20/40) so konfiguriert, dass an man einen Client an dem LAN Port des Telefons anschließen kann (das funktioniert auch Tadellos) - allerdings verhält sich das Telefon wohl scheinbar nicht wie ein Switch, die MAC Adresse des Clients erkennt der Switch nicht direkt (wenn ich dort den Client via "show mac-address xyz" suche, findet er diesen nicht) und ich denke auch das daher das Problem auftritt.
Was wir bereits getestet haben, das man das WOL Signal an das Telefon absetzt (hat natürlich nicht funktioniert), gibt es dafür evtl. Lösungen oder wie habt Ihr solche Sachen gelöst - oder ist es evtl. nur ein Bug der Telefone?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 219942
Url: https://administrator.de/contentid/219942
Ausgedruckt am: 23.11.2024 um 11:11 Uhr
7 Kommentare
Neuester Kommentar
Hi,
muss dann an den Siemens-Teilen liegen. Ich habe in der Praxis Auerswald-VOIP-Systemtelefone, die ebenfalls fast ethernet durchreichen und bei denen WOL auf den angeswitchten Client funktioniert.
LG, Thomas
muss dann an den Siemens-Teilen liegen. Ich habe in der Praxis Auerswald-VOIP-Systemtelefone, die ebenfalls fast ethernet durchreichen und bei denen WOL auf den angeswitchten Client funktioniert.
LG, Thomas
Wenn dem wirklich so wäre wie du schilderst, dann wäre das kein Switch sondern ein simpler Hub im Telefon.
Das wäre sehr ungewöhnlich, weil in der Regel diese Telefone immer einen kleinen 2 oder mehr Port Switch integriert haben.
Das muss auch so sein, denn wenn das Telefon mit Layer 2 Priorisierung (CoS), sprich also 802.1p der Sprachdaten arbeitet, der integrierte Switch das Voice VLAN taggen muss. 802.1q ist Teil des 802.1q Tags.
Das Tagging erzwingt dann technisch einen Switch und keinen Hub im Telefon, klar !
Leider teilst du uns hier zu der detailierten Konfig nichts mit, so das eine zielführende Antwort nicht möglich ist.
Fakt ist aber das die WoL Pakete Broadcasts oder mindestens Unicasts sind an die spezifische Mac Adresse des Endgerätes. Solche Pakete sind reine Layer 2 Pakete die der interne Telefonswitch zwingend forwarden muss !
Interessant wäre mal auf dem betroffenen PC wo WoL ankommen soll einen freien Paket Sniffer wie den Wireshark oder MS NetMonitor zu installieren und einfach mal zu messen ob diese Pakete dort wirklich physisch nicht ankommen oder ob ggf. der Switch davor diese schon filtert ??
Status Anzeigen im telefon solltest du per se erstmal misstrauen. Was zählt ist das was direkt auf dem Draht passiert.
Also einnmal den PC ohne und einmal mit Telefon im besagten VLAN (sofern du mit VLANs arbeitetst was aber wohl anzunehmen ist bei Voice ?!) wo WoL PC und WoL Sender in einem gemeinsamen Layer 2 VLAN / LAN sind und man dann mal mit wol.exe http://www.heise.de/download/wol.exe.html ein entsprechends Paket senden und checken obs ankommt.
Das wäre sehr ungewöhnlich, weil in der Regel diese Telefone immer einen kleinen 2 oder mehr Port Switch integriert haben.
Das muss auch so sein, denn wenn das Telefon mit Layer 2 Priorisierung (CoS), sprich also 802.1p der Sprachdaten arbeitet, der integrierte Switch das Voice VLAN taggen muss. 802.1q ist Teil des 802.1q Tags.
Das Tagging erzwingt dann technisch einen Switch und keinen Hub im Telefon, klar !
Leider teilst du uns hier zu der detailierten Konfig nichts mit, so das eine zielführende Antwort nicht möglich ist.
Fakt ist aber das die WoL Pakete Broadcasts oder mindestens Unicasts sind an die spezifische Mac Adresse des Endgerätes. Solche Pakete sind reine Layer 2 Pakete die der interne Telefonswitch zwingend forwarden muss !
Interessant wäre mal auf dem betroffenen PC wo WoL ankommen soll einen freien Paket Sniffer wie den Wireshark oder MS NetMonitor zu installieren und einfach mal zu messen ob diese Pakete dort wirklich physisch nicht ankommen oder ob ggf. der Switch davor diese schon filtert ??
Status Anzeigen im telefon solltest du per se erstmal misstrauen. Was zählt ist das was direkt auf dem Draht passiert.
Also einnmal den PC ohne und einmal mit Telefon im besagten VLAN (sofern du mit VLANs arbeitetst was aber wohl anzunehmen ist bei Voice ?!) wo WoL PC und WoL Sender in einem gemeinsamen Layer 2 VLAN / LAN sind und man dann mal mit wol.exe http://www.heise.de/download/wol.exe.html ein entsprechends Paket senden und checken obs ankommt.
Hi
Wenn ich den Client direkt an dem Switch anschließe ohne das Telefon dazwischen zu schalten funktioniert es tadellos. Das WOL Paket lässt den Client starten.
Was nun interessant ist, wenn ich den Client hinter an das Telefon anschließe und aus dem gleichen Subnetz ein WOL Paket absetze funktioniert es :|. Was mich jetzt allerdings ein wenig Stutzig macht, wenn der Client direkt am Switch angeschlossen ist, dann funktioniert das auch aus einem anderem Subnetz heraus, wenn der Client am Telefon angeschlossen ist nicht - dann nur aus dem gleichen Subnetz.
Wenn ich den Client direkt an dem Switch anschließe ohne das Telefon dazwischen zu schalten funktioniert es tadellos. Das WOL Paket lässt den Client starten.
Was nun interessant ist, wenn ich den Client hinter an das Telefon anschließe und aus dem gleichen Subnetz ein WOL Paket absetze funktioniert es :|. Was mich jetzt allerdings ein wenig Stutzig macht, wenn der Client direkt am Switch angeschlossen ist, dann funktioniert das auch aus einem anderem Subnetz heraus, wenn der Client am Telefon angeschlossen ist nicht - dann nur aus dem gleichen Subnetz.
So, Problem gefunden wie es scheint 
wir haben ein Subnetz (192.168.8.0/22) das sich über mehr wie einem /24 erstreckt - die Broadcast Adresse ist in diesem Fall ja die 192.168.11.255 - diese wurde auch in die IP Helper Adresse am Router Interface eingetragen - jetzt haben ich von "jedem Netz" (192.168.8.0 / 192.168.9.0 / 192.168.10.0 / 192.168.11.0) die entsprechende Broadcastadresse des Netzes eingetragen (x.x.x.255) und damit rennt es nun :/
Eckdaten zu Config:
WOL Server -> VLAN 50 IP 192.168.50.202
WOL Paket über UDP Port 5
Clients -> VLAN 1,70,149,150,151,152,153,154,155
VLAN -> 192.168.8.0/22 alle anderen VLANs sind /24
Folgende Zeilen in der Router-Config waren dafür "in Summe" notwendig, dass die WOL Pakete durch alle VLANs geroutet werden
Der Befehlt "ip forward-protocoll udp echo" muss an allen Routern eingetragen werden worüber das Paket gesendet wird.
Danke an @auqi und @kein-ahnung - das mit dem direkten Testen aus dem gleichen IP Segment hatte ich nicht getestet
.
wir haben ein Subnetz (192.168.8.0/22) das sich über mehr wie einem /24 erstreckt - die Broadcast Adresse ist in diesem Fall ja die 192.168.11.255 - diese wurde auch in die IP Helper Adresse am Router Interface eingetragen - jetzt haben ich von "jedem Netz" (192.168.8.0 / 192.168.9.0 / 192.168.10.0 / 192.168.11.0) die entsprechende Broadcastadresse des Netzes eingetragen (x.x.x.255) und damit rennt es nun :/
Eckdaten zu Config:
WOL Server -> VLAN 50 IP 192.168.50.202
WOL Paket über UDP Port 5
Clients -> VLAN 1,70,149,150,151,152,153,154,155
VLAN -> 192.168.8.0/22 alle anderen VLANs sind /24
Folgende Zeilen in der Router-Config waren dafür "in Summe" notwendig, dass die WOL Pakete durch alle VLANs geroutet werden
router ospf
..area 0.0.0.0
ip forward-protocoll udp echo
interface ve 50
..ip address 192.168.50.30/24
..ip ospf area 0.0.0.0
..ip helper address 1 192.168.8.255
..ip helper address 2 192.168.9.255
..ip helper address 3 192.168.10.255
..ip helper address 4 192.168.11.255
..ip helper address 4 192.168.70.255
..ip helper address 5 192.168.149.255
..ip helper address 6 192.168.150.255
..ip helper address 7 192.168.151.255
..ip helper address 8 192.168.152.255
..ip helper address 9 192.168.153.255
..ip helper address 10 192.168.154.255
..ip helper address 11 192.168.155.255Der Befehlt "ip forward-protocoll udp echo" muss an allen Routern eingetragen werden worüber das Paket gesendet wird.
Danke an @auqi und @kein-ahnung - das mit dem direkten Testen aus dem gleichen IP Segment hatte ich nicht getestet
.
Die .8.255, .9.255 und die .10.255 sind eigentlich falsch, denn sie gehören ja zum 192.168.8.0 /22 Subnetz. Diese "Broadcast Adressen" sind gar keine laut Subnetz Maske, denn das ist einzig die .11.255 !!
Die müsste man so nicht eintragen, denn das sollte alles mit der .11.255 erledigt sein, denn das ist logischerweise die zentrale Broadcast Adresse im .8.0 /22er Subnetz !
Andernfalls ist das ein klarer Bug in der Switch Firmware !
Der UDP Port 5 ist auch kein Echo Port oder sowas !:
http://de.wikipedia.org/wiki/Liste_der_standardisierten_Ports
Auch ist er für WoL Pakte sehr ungewöhnlich, denn diese benutzen in der Regel UDP 9 (Discard). Siehe auch hier:
http://www.heise.de/netze/artikel/Port-Forwarding-224180.html
im Kapitel "Aufwachen bitte !"
Das ist schon etwas merkwürdig bei dir und ganz kann das alles so nicht stimmen ?!
Aber wenns denn geht....?!
Die müsste man so nicht eintragen, denn das sollte alles mit der .11.255 erledigt sein, denn das ist logischerweise die zentrale Broadcast Adresse im .8.0 /22er Subnetz !
Andernfalls ist das ein klarer Bug in der Switch Firmware !
Der UDP Port 5 ist auch kein Echo Port oder sowas !:
http://de.wikipedia.org/wiki/Liste_der_standardisierten_Ports
Auch ist er für WoL Pakte sehr ungewöhnlich, denn diese benutzen in der Regel UDP 9 (Discard). Siehe auch hier:
http://www.heise.de/netze/artikel/Port-Forwarding-224180.html
im Kapitel "Aufwachen bitte !"
Das ist schon etwas merkwürdig bei dir und ganz kann das alles so nicht stimmen ?!
Aber wenns denn geht....?!
Hallo Aqui
Lt. der Softwareverteilung ist Echo mit Port 7 allerdings korrekt, auch der Solarwind-WOL "Server" sendet über Port 7, ich habe das ganze anhand eines HowTo`s von Brocade eingerichtet (http://community.brocade.com/docs/DOC-1979).
Unsere Softwareverteilung ist wohl eher das Problem (http://www.kace.com/de/support/resources/kb/article/how-does-the-k1000- ..).
Wobei auch hier eigentlich die 22er Maske als erstes greifen sollte :| komisch ist das schon...
Lt. der Softwareverteilung ist Echo mit Port 7 allerdings korrekt, auch der Solarwind-WOL "Server" sendet über Port 7, ich habe das ganze anhand eines HowTo`s von Brocade eingerichtet (http://community.brocade.com/docs/DOC-1979).
Unsere Softwareverteilung ist wohl eher das Problem (http://www.kace.com/de/support/resources/kb/article/how-does-the-k1000- ..).
The K1000 appliance implementation encapsulates the wake-up frame in a UDP packet sent to port 7 on a number of broadcast addresses. We use the device's last known IP address and loop over the possible subnets from */16 to */32, sending a packet to the broadcast address for each subnet. A lot of these packets will "miss" because they're not correct. The K1000 appliance does it this way to avoid requiring the user to enter the subnet for each address. Note that when we send to the /32 subnet, we're directly addressing the device.
Wobei auch hier eigentlich die 22er Maske als erstes greifen sollte :| komisch ist das schon...
OK, wenn Solar Winds da UDP 7 (echo) verwendet ist das im Brocade Dokument ja dann auch OK und richtig so. Es gibt da eben ziemlich viel Wildwuchs im WoL bereich, denn die meisten freien Tools wie z.B. wol.exe http://www.heise.de/download/wol.exe.html oder Mac WoL: http://www.readpixel.com/wakeonlan/index.html nutzen UDP 9 (discard) für sowas.
Müsste man mal genau sniffern...
Na ja wenns nun mit Umwegen klappt ist ja alles OK
Müsste man mal genau sniffern...
Na ja wenns nun mit Umwegen klappt ist ja alles OK
