wakeonlan in ein anderes VLAN - Unifi Dream Machine Pro

darkiop

Lt. Junior Grade
Registriert
Juli 2001
Beiträge
385
Hallo zusammen,
mit dem Unifi USG hatte ich um die Magic Packets für WoL in VLANs zu senden folgende Einträge in der ARP Tabelle hinterlegen müssen - danach konnte Ich zuverlässig wakeonlan benutzen.

Dazu war folgende config.json erforderlich:

1598108808931.png


In der ARP Tabelle der UDM-P finde ich (dauerhaft) den Eintrag für den Client welchen ich per wakeonlan starten möchte:

Code:
# cat /proc/net/arp | grep 10.1.1.2
10.1.1.2         0x1         0x0         0c:9d:92:84:86:49     *        br100

Lasse ich das WoL Paket los, kann ich dieses auf der UDM-P per tcpdump auch sehen.

Start des WoL Packets aus einem Docker Container (hat fixe IP 192.168.1.82) mit wakeonlan

Code:
/usr/bin/wakeonlan -i 10.1.1.2 0c:9d:92:84:86:49
Sending magic packet to 10.1.1.2:9 with 0c:9d:92:84:86:49

Start des WoL Paket von einem Win10 Client mit wol.exe

1601195185422.png


tcpdump auf der UDM-P

Lausche ich auf der UDM-P auf 192.168.1.1/24 Port 9 sehe ich das Paket:

br0 = 192.168.1.1/24

Code:
# tcpdump -ni br0 port 9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:17:21.716893 IP 192.168.1.82.57703 > 10.1.1.2.9: UDP, length 102

Weiter zum 10.1.1.1/24 Port 9 geht es allerdings nicht:

br100 = 10.1.1.1/24

Code:
# tcpdump -ni br100 port 9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br100, link-type EN10MB (Ethernet), capture size 262144 bytes


Hat jemand eine Idee was man noch machen könnte, damit das WoL Paket über die UDM-P auch an den Client richtig geroutet wird?

Ergänzung:

Wenn der Client 10.1.1.2 manuell eingeschaltet und direkt wieder heruntergefahren wird, kann das WoL Paket danach an Ihn durchgestellt werden. Die Frage lautet also, wie mache ich auf der UDM-P dauerhaft den Client 10.1.1.2 bekannt, damit das WoL Paket auch ankommen kann?

Code:
# tcpdump -ni br100 port 9
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br100, link-type EN10MB (Ethernet), capture size 262144 bytes
10:45:44.752319 IP 192.168.1.82.60504 > 10.1.1.2.9: UDP, length 102
 
Zuletzt bearbeitet:
es gibt switche mit udp broadcast helpern, die sind recht teuer mit den Features,
da könnte man sowas versuchen ansonsten sehe ich dein Vorhaben uber Vlan WoL Broadcast zu senden als nicht praktikabel.

PS
ach ja man könnte noch ARP proxy dazu versuchen.
 
ARP-Proxy kenn ich noch nicht, werd ich mal danach suchen.

Mit der USG lief WoL über die VLANs nach Anpassung der ARP Tabelle zu 100% zuverlässig.
 
es gibt ja auch L2 Vlan also private und L3 Vlan also Routed, bei L2 sehe ich weniger probleme beim Routed Vlan werden Broadcasts eigentlich verworfen, bzw nicht geroutet.
 
Ichtiander schrieb:
es gibt ja auch L2 Vlan also private und L3 Vlan also Routed

Könntest du das bitte weiter ausführen? Sprichst du noch von IEEE 802.1Q?

darkiop schrieb:
Wenn der Client 10.1.1.2 manuell eingeschaltet und direkt wieder heruntergefahren wird, kann das WoL Paket danach an Ihn durchgestellt werden. Die Frage lautet also, wie mache ich auf der UDM-P dauerhaft den Client 10.1.1.2 bekannt, damit das WoL Paket auch ankommen kann?

Verstehe ich das richtig, dass du versuchst ein Gerät nach einem PowerLoss (Stecker gezogen) mit WoL zu starten?

Also nach einem normalen Shutdown funktioniert es, jedoch nicht nach einem Shutdown mit anschließendem Powerloss?

Viele Grüße
Kiso
 
Kiso schrieb:
Könntest du das bitte weiter ausführen? Sprichst du noch von IEEE 802.1Q?

https://en.wikipedia.org/wiki/Private_VLAN

Routed Vlan ist wenn der IEEE 802.1Q conforme über ein L3 Router Interface erreichbar ist.

Beispiel:
Vlan1 192.168.0.0/24 Vlan Interface/Router 192.168.0.1
Vlan2 172.16.0.0/24 Vlan Interface/Router 172.16.0.1

so können beide miteinander schwätzen.
 
Kiso schrieb:
Verstehe ich das richtig, dass du versuchst ein Gerät nach einem PowerLoss (Stecker gezogen) mit WoL zu starten?

Also nach einem normalen Shutdown funktioniert es, jedoch nicht nach einem Shutdown mit anschließendem Powerloss?

Viele Grüße
Kiso

Nein, der Stromstecker ist nicht abgezogen - das spielt in meinem Szenario keine Rolle - Strom ist zu jeder Zeit aufg der Leitung.

Das WoL Paket kann nur dann von der UDM-P geroutet werden, wenn der einzuschaltende Client kurz zuvor eingeschaltet war. Dann kommt auch das WoL Paket an. Ist er eine weile aus, wird es auf der UMD-P zwischen den beiden LANs (1x Management LAN (192.168.1.0/24) + 1x VLAN 100 (10.1.1.0/24) verworfen. Diesen Zustand hatte ich auf der USG ebenfalls, konnte mir aber mit dem permanenten Eintrag in der ARP Tabelle (siehe config.json im Post #1) helfen.
 
Ichtiander schrieb:
Routed Vlan ist wenn der IEEE 802.1Q conforme über ein L3 Router Interface erreichbar ist.
Ich denke du willst mir das richtige sagen, aber kannst es schlichtweg nicht richtig ausdrücken. Dein verlinkter Artikel hat damit jedenfalls nichts zu tun und am OSI Modell bist du auch etwas vorbei.

Was du als L3 VLAN bezeichnest ist Inter VLAN Routing, was für gewöhnlich über Router/Firewalls/L3-Switches abläuft, welche über diese VLAN Interfaces mit dem entsprechenden logischen Teilnetz verbunden sind. Dennoch ist 802.1Q eine Erweiterung des Ethernet Protokolls und damit L2. :)

@darkiop
Ich hab mir deinen Beitrag nochmal genau durchgelesen und nun dein Problem verstanden. Stecken jede Menge guter Informationen drin. :daumen:

Könntest du ein dump von beiden Interfaces hochladen, wenn das Paket durch geht und wenn nicht? Ich würde mir das gerne mal im Wireshark anschauen.

Ich kenne mich nicht mit den Unifi Geräten im speziellen aus. Aber die kochen ja eigentlich auch nur mit Wasser.

Irgendwo im Firewalllog müsste ja stehen, was genau mit diesem Frame passiert und vor allem warum. Wie ausführlich ist Ubiquiti denn da?
 
@Kiso
du hast Recht wir reden dasselbe aneinander vorbei.
ich habe nie behauptet das 802.3q layer3 ist.
Ich habe lediglich angemerkt das zb Port isolation oder Private Vlan nur auf Layer 2 (Mac) ist und sobald IP im spiel ist läuft der Vlan im Layer 3... getaggt wird natürlich im L2.
 
Kiso schrieb:
Könntest du ein dump von beiden Interfaces hochladen, wenn das Paket durch geht und wenn nicht? Ich würde mir das gerne mal im Wireshark anschauen.

Gerne, hab mir Mühe gegeben selbst in die Analyse zu gehen :D

Du meinest einen Dump mittels tcpdump -i <interface> -w file oder?
 
Das macht keinen Unterschied. Ich schau aber gleich nochmal danach.

Der Dump für Wireshark - ohne weiteren Parameter (Port, Host, ...) ?
 
Alles klar, ich schicke dir dann eine PM mit den dumps.

Trifft sich gut, hab die letzten Tage auch mal damit begonnen mich mit Wireshark zu beschäftigen - wäre super wenn du mir ggf, dann kurz sagen könntest was du in Wireshark gefilter hast ;)
 
Ich hab mir die Dumps mal angeschaut.

Im Positivfall nimmt der die Destination Address auf Layer 2 aus dem Cache.

Im Negativfall erfolgt ein ARP Request. Also ganz klares Zeichen, dass deine oben genannte Einstellung nicht funktioniert.

1601226394817.png


Darauf antwortet natürlich niemand und damit wird das Paket gedroppt.


Kannst du den ARP Eintrag temporär statisch setzen mit:

set protocols static arp X.X.X.X hwaddr 00:00:00:00:00:00
 
Kiso schrieb:
Im Positivfall nimmt der die Destination Address auf Layer 2 aus dem Cache.

Und das bedeutet, das die UDM-P den Cache leert sobald ein Gerät offline geht. Jetzt ist die Frage wie ich das unterbinden kann - auf der USG konnte man das ja.

Könntest du mir noch kurz deine Filter innerhalb Wireshark zeigen?
 
Kannst du den ARP Eintrag temporär statisch setzen mit:

set protocols static arp X.X.X.X hwaddr 00:00:00:00:00:00

(Auch nur per Google gefunden.)


Wenn ich was gefiltert hab, dann mit udp.port==9

Anhand dessen wusste ich dann die Paketnummer und hab mir dann ohne Filter noch einen kurzen Zeitraum davor angeschaut. In den Negativfällen waren es ja nur eine Handvoll Pakete. Da gehts ganz ohne.


Du kannst aber sehr schön Filtern indem du bspw. Rechtsklick auf das zu filternde machst und dann auswählst:
1601226889778.png


So sind auch einfache and, or etc. Verknüpfungen möglich.

Edit:

Und im Negativfall mal den ARP Cache abrufen.

arp -a

-> Ist zumindest der Befehl unter Linux. Müsste ja aber funktionieren.
Ergänzung ()

Well. Ich muss dich wohl enttäuschen.

The UDM does not have this feature. There is no config.gateway.json file or equivalent for UDM. Please make detailed feature requests on what you’re lacking in the GUI. This is the new way forward.

Quelle:
https://community.ui.com/questions/...-Machine/4b14927a-425b-4faa-a387-c01d7caf3b46
https://community.ui.com/questions/...possible/b451feeb-9e67-4cc4-8344-b2c8759c8bd7
 
Zuletzt bearbeitet:
Danke dir. Das mit der config.json wusste ich - leider geht das unter dem Unifi OS auf dem UDM-P nicht mehr.

Mit arp -a findet man folgenden eintrag (wenn Client offline):

Code:
example.com (10.1.1.2) at <incomplete>  on br100

Mit set protocols static arp hatte ich keinen Erfolg - allerdings mit:

Code:
arp -s 10.1.1.2 0c:9d:xx:xx:xx:xx

Danach findet man mit arp -a folgenden Eintrag vor:

Code:
example.com (10.1.1.2) at 0c:9d:xx:xx:xx:xx [ether] PERM on br100

Das Magic Paket geht dann auf br100 auf der UDM-P auch durch. :schluck:

Jetzt muss ich nur noch schauen wie ich das dauerhaft auf der UDM-P eingebunden bekomme.
Evtl. hiermit: https://github.com/boostchicken/udm-utilities
 
Ja super.

Vielleicht die rustikale Variante mit Cronjob beim Boot?

Grüße
 
  • Gefällt mir
Reaktionen: darkiop
Die hab ich Hinterkopf :D

Mit

Code:
unifi-os shell

kommt man aufs Debian - darin sollte dann was machbar sein :)
 
  • Gefällt mir
Reaktionen: Kiso
Zurück
Oben