Bug 49970 - Have WoL feature when using multiple NICs and/ or VLANs
Have WoL feature when using multiple NICs and/ or VLANs
Status: CLOSED FIXED
Product: UCS@school
Classification: Unclassified
Component: UMC - Computer room
UCS@school 4.4
Other Linux
: P5 normal (vote)
: UCS@school 4.4 v4-errata
Assigned To: Sönke Schwardt-Krummrich
Ole Schwiegert
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-07 12:12 CEST by Christian Völker
Modified: 2019-11-21 11:09 CET (History)
6 users (show)

See Also:
What kind of report is it?: Feature Request
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?: Yes
School Customer affected?: Yes
ISV affected?:
Waiting Support:
Flags outvoted after Product Owner Review:
Ticket number: 2019071821000371, 2019080621001006, 2019082021000491, 2019111421001226
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Völker univentionstaff 2019-08-07 12:12:47 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.
Comment 1 Sönke Schwardt-Krummrich univentionstaff 2019-08-11 22:51:24 CEST
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)
Comment 2 Christian Völker univentionstaff 2019-08-21 11:02:28 CEST
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.
Comment 3 Michel Smidt univentionstaff 2019-08-21 11:05:32 CEST
(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.
Comment 4 Sönke Schwardt-Krummrich univentionstaff 2019-11-15 16:44:45 CET
(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.
Comment 5 Sönke Schwardt-Krummrich univentionstaff 2019-11-15 17:48:54 CET
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
Comment 6 Ole Schwiegert univentionstaff 2019-11-18 13:59:56 CET
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
Comment 7 Sönke Schwardt-Krummrich univentionstaff 2019-11-18 23:24:10 CET
(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
Comment 8 Ole Schwiegert univentionstaff 2019-11-19 08:16:16 CET
REOP issues fixed,
quick functional test reveals no further problems.
Comment 9 Sönke Schwardt-Krummrich univentionstaff 2019-11-20 11:26:54 CET
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.
Comment 10 Daniel Tröder univentionstaff 2019-11-21 11:09:23 CET
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.