Univention Bugzilla – Bug 49970
Have WoL feature when using multiple NICs and/ or VLANs
Last modified: 2021-06-03 21:55:29 CEST
In ucs@school environments it is more and more common to have more than just "Educative LAN" and "Administrative LAN". Schools separate their network traffic meanwhile due to address limitations (netmask and number of clients) , security considerations (student's mobile phones) or QoS (VoIP Phones). For classroom mode it is possible to wake up the classroom clients through UMC. But UCS here sends the magic packets just through the primary interface even if the computers are located and registered on another network. UMC should be able to wake up the clients through any local network interface and decide based on the IP (or whatever) which interface to use to send out the magic packet.
ucs-school-umc-computerroom is currently using the tool "wakeonlan". wakeonlan does not support the requested feature. We should check other tools like etherwake if they are a sufficient replacement. (Not only that the WOL packet should be sent on any interface of the UCS@school system, the WOL packet should be sent to any MAC address of the client. For some clients more than one MAC address is noted at the LDAP object)
Just as an update. Another customer has edited the file /usr/bin/wakeonlan and replaced the default broadcast src-address by it's own IP and therefore the packets get routed and customer reports the teachers can wake up all classrooms: # my $DEFAULT_IP = '255.255.255.255'; my $DEFAULT_IP = '172.14.30.5'; Getting more and more common. We should raise priority here IMHO.
(In reply to Christian Völker from comment #2) > Just as an update. > > Another customer has edited the file /usr/bin/wakeonlan and replaced the > default broadcast src-address by it's own IP and therefore the packets get > routed and customer reports the teachers can wake up all classrooms: > > # my $DEFAULT_IP = '255.255.255.255'; > my $DEFAULT_IP = '172.14.30.5'; > > > Getting more and more common. We should raise priority here IMHO. I do raised the prio already.
(In reply to Christian Völker from comment #2) > Another customer has edited the file /usr/bin/wakeonlan and replaced the > default broadcast src-address by it's own IP and therefore the packets get > routed and customer reports the teachers can wake up all classrooms: Sorry, this doesn't make any sense. > # my $DEFAULT_IP = '255.255.255.255'; > my $DEFAULT_IP = '172.14.30.5'; DEFAULT_IP is the *destination* IP address. The packet is always sent with the IP address of the sending systems as *SRC*-address. Even if the IP address 172.14.30.5 is used and routed, the last router does not know, to which system (MAC address) the packet shall be delivered to. If the system (to be waken up) is down, it does not answer ARP requests (→ no IP to MAC translation). Usually this results in an ICMP "destination host unreachable" response. (Maybe the router was configured to act as a switch and re-broadcasted the packet) Additionally: | The magic packet is sent on the data link layer (layer 2 in the OSI model) and | when sent, is broadcast to all attached devices on a given network, using the | network broadcast address; the IP-address (layer 3 in the OSI model) is not | used. and | The magic packet is a broadcast frame containing anywhere within its payload 6 | bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen | repetitions of the target computer's 48-bit MAC address, for a total of 102 | bytes. Sources: https://en.wikipedia.org/wiki/Wake-on-LAN I noticed (painfully in the past) that even if the WOL standard says that only the payload is important, some NIC firmware only accept packets that are directed to 255.255.255.255. So we will not change this default.
The sending of wake-on-LAN packages is no longer done via an extra tool but directly in python. Also the code now sends the magic packet on all known interfaces, where UCR variables can be used to define certain interfaces or interface prefixes on which the magic packets should not be sent. By default this is the interface "lo" and the interfaces with the prefixes "tun" and "docker". The interfaces/prefixes can be defined using the following UCR variables and must be specified with whitespace as delimiter: ucsschool/umc/computerroom/wakeonlan/blacklisted/interfaces="lo" ucsschool/umc/computerroom/wakeonlan/blacklisted/interface_prefixes="tun docker" For testing purposes, I unset both UCR variables and used tshark for packet capturing: root@slave213:~# tshark -i any -f "udp and port 9" Running as user "root" and group "root". This could be dangerous. Capturing on 'any' 1 0.000000000 172.17.42.1 → 255.255.255.255 WOL 146 MagicPacket for RealtekU_17:0f:5a (52:54:00:17:0f:5a) 2 0.000010795 172.17.42.1 → 255.255.255.255 WOL 146 MagicPacket for RealtekU_17:0f:5a (52:54:00:17:0f:5a) 3 0.000086208 10.200.18.213 → 255.255.255.255 WOL 146 MagicPacket for RealtekU_17:0f:5a (52:54:00:17:0f:5a) 4 0.000164348 127.0.0.1 → 255.255.255.255 WOL 146 MagicPacket for RealtekU_17:0f:5a (52:54:00:17:0f:5a) ^C root@slave213:~# [4.4] d700a839c Bug #49970: update advisory [4.4] 3d1b2cc3b Bug #49970: update manual for new UCRV for WakeOnLAN packets [4.4] 1f8d01f50 Bug #49970: add advisory [4.4] f5ec25873 Bug #49970: send wake-on-LAN packets on all interfaces (now python-based) Package: ucs-school-umc-computerroom Version: 11.0.0-12A~4.4.0.201911151745 Branch: ucs_4.4-0 Scope: ucs-school-4.4
Code review: REOP Unused import subprocess in italc.py Changelog&Advisory: OK Manual (UCRV): REOP ucsschool/umc/computerroom/wakeonlan/blacklisted/interface_prefixes liste not capitalized in german text Manual text is good, but produces three warnings http://jenkins.knut.univention.de:8080/job/UCSschool-4.4/job/Handbook/36/warnings5Result/new/ CMD-tool wakeonlan: REOP misses execution bit functional test: UCS VM on notebook with two interfaces. Checked via tshark that magic packets were send via both interfaces, checked that target notebook was woken up via the script. Checked that computerroom module sends magic packets and respects UCRV
(In reply to Ole Schwiegert from comment #6) > Code review: REOP Unused import subprocess in italc.py → FIXED > Manual (UCRV): REOP > > ucsschool/umc/computerroom/wakeonlan/blacklisted/interface_prefixes > liste not capitalized in german text → FIXED > Manual text is good, but produces three warnings > http://jenkins.knut.univention.de:8080/job/UCSschool-4.4/job/Handbook/36/ > warnings5Result/new/ → FIXED > CMD-tool wakeonlan: REOP misses execution bit → FIXED Package: ucs-school-umc-computerroom Version: 11.0.0-14A~4.4.0.201911182308 Branch: ucs_4.4-0 Scope: ucs-school-4.4 [4.4] 48bbe2b29 Bug #49970: update advisory [4.4] 32085adec Bug #49970: fix spell checker error [4.4] 914e25653 Bug #49970: add changelog entry [4.4] ce9f1158b Bug #49970: add executable flag for wakeonlan.py [4.4] d0e932e93 Bug #49970: fixed UCR variable description [4.4] 607527fae Bug #49970: remove unused import
REOP issues fixed, quick functional test reveals no further problems.
Supplement to decision making: While researching this bug I noticed that the tool "wakeonlan" does not support an explicit interface. I.e. the interface is selected automatically using the routing table, so that you have no influence there. The tool "etherwake" did not create valid magic packets in the test. Since "wakeonlan" is written in Perl and the complexity for the actual package generation is not very high, it was decided in the UCS@school-Daily to implement it directly in Python.
UCS@school 4.4 v4 has been released (errata update to the release). https://docs.software-univention.de/changelog-ucsschool-4.4v4-de.html If this error occurs again, please clone this bug.
(In reply to Sönke Schwardt-Krummrich from comment #7) > [4.4] ce9f1158b Bug #49970: add executable flag for wakeonlan.py FYI: better don't add executable flags to python modules. You can simply call them via "python -m univention.management.console.modules.computerroom.wakeonlan" instead.