WO2021079161A1

WO2021079161A1 - Method and device for the remote boot of devices that support wake-on-lan technology

Info

Publication number: WO2021079161A1
Application number: PCT/GR2020/000051
Authority: WO
Inventors: Nikolaos SFETSIOS
Original assignee: Sfetsios Nikolaos
Priority date: 2019-10-22
Filing date: 2020-10-21
Publication date: 2021-04-29
Also published as: GR1009900B

Abstract

The invention relates to a method for remotely booting devices that support wake-on-lan technology, as well as to the device implementing the method. The device, referred to as the actuator (4), has at least one local area network interface (7), through which it communicates with a target-device (1), to send a wake-on-lan packet when receiving the relevant command from a command device (5). The command device (5) and the actuator (4) communicate with each other exclusively at the application layer (layer 7) of the Open Systems Interconnection reference model. The target device (1), the actuator (4) and the command device (5) may participate in the same local area network (3) or communicate via a wider private or public network (10). Local area networks (3) which target devices (1), command devices (4) and actuators (5) are connected to may be located behind firewalls (2).

Description

DESCRIPTION

METHOD AND DEVICE FOR THE REMOTE BOOT OF DEVICES THAT SUPPORT WAKE-ON-LAN TECHNOLOGY

FIELD OF ART

The invention relates to the field of electronic art and specifically to the field of electronic communication and more specifically to transmission of digital information and even more specifically to data switch networks and in general to the interconnection or transfer of signals, commands and files between memories, input/output devices or central processing units. In particular, the invention relates to a method for remotely booting devices that support wake-on-lan technology, as well as to a device implementing the method.

BACKGROUND OF THE INVENTION

The method and device disclosed in the present invention for remotely booting devices that support wake-on-lan technology have not been disclosed in the prior art.

Nowadays it is a common situation that one needs to use remotely an electronic device that processes data and is connected to a local packet switching network. If the network device is in a state of sleep or shutdown, the device must boot before use. This is often a problem, as one may not be physically present at the site to proceed with booting. The solution to the problem is essentially given through the local area network wake technology, also known as Wake-On-Lan (WOL). This technology enables the boot of a network target-device, sending special packets to all stations participating in the same network, at layer 2 (data link layer) of the Open Systems Interconnection reference model, with the target-device (e.g. ethemet LAN). Because WOL technology is implemented at the data link layer, it cannot be used by someone connected on another network, who can access the local network through a complex packet switching network, such as the Internet. For example, if the target-device is a personal computer connected to a local area network, on which the user has installed a popular software for remote access through Internet, the user can not directly use WOL technology to boot his computer.

Thus, users who want to use network devices by accessing them through complex public or private packet switching networks follow various approaches, among which is to keep the target device always on. In addition, if the target- devices use power saving logic for reducing power consumption when not in use and automatically go into inactivity, users take special measures to cancel these power saving functions. Another approach involves "opening a hole" in the firewall, which protects the local network from layer 3 and 4 of the Open Systems Interconnection reference model attacks. Through these "holes", they redirect all incoming magic WOL packets arriving at the router of the local network router from the external packet switching network, to the network adapter of the target- device.

A further option may be the presence of an auxiliary network device, in the same local area network as the target-device, which is permanently in full operation and may have a special software, which performs an outgoing call (connection request) and achieves a permanent connection to a specific server, located on a public or private packet switching network, to which the local network where the target-device and the auxiliary device are located is connected. Thus, when the user wants to boot the target-device, he temporarily connects to the servers to which the auxiliary device is connected and through them, commands the auxiliary device to boot the target-device with WOL technology or otherwise. Examples include specific programs for remote access, which are connected to their manufacturer's servers, or virtual private network gateways that are connected to virtual private network service providers' servers. Alternatively, special software can be run by an auxiliary network device, enabling the target-device to connect to the local network via a wider public or private packet switching network to which the local network is connected, allowing incoming connection requests from the wider network and directed to the local network. In order for the device to perform its function, "holes are opened" in the firewall that protects the target-device's local network from attacks, so that the auxiliary device can receive incoming connection requests. In this case, the user connects to the auxiliary device or through it to another network device of the target-device local network and then boots the target-device using WOL technology or otherwise. This mode is used when the auxiliary device is a virtual private network gateway that serves incoming requests for direct connection to the local network it serves. Finally solutions include combinations of the above, as is the case in complex Network Management Systems.

All of the above solutions, although they serve the ultimate purpose, introduce a number of issues, as they have a number of disadvantages particularly important in terms of security. For example, solutions that require the user to connect anyway to the LAN target introduce security issues, because if a malicious user can intervene in this communication, he will have full or very wide access to the internal network after gaining access to a real connection to at least one device on that network.

In addition solutions that require incoming connections to the local network, by default introduce vulnerabilities for attacks from external networks to the interior. The exposure level of the internal network may be small to unacceptable, as is the case of "hole opening" in the firewall for redirecting incoming WOL magic packets directly into the internal network. Furthermore, solutions that require constant, direct connection to external servers expose the internal network to risk, because if the external servers are taken over by malicious users, the malicious users will have access to the internal network. Indeed, because these external servers should be specific and publicly known, they are also permanent, well- known targets.

In addition to the above security issues, solutions that require the presence of an auxiliary network device, which is a normal computer, are costly in terms of energy and therefore environmentally unfriendly. Finally, it should be noted that the solutions that require a central controller are vulnerable in the event of the central controller failure, as this is a single point of failure for the entire remote boot system.

Well-known documents from the state of the art are the US2008/0229091 A1 application, which refers to a remote wake computer device, the US2007/0067445 A1 one, which refers to a remote wake computer method for network applications, and the EP2229751 B1 one, which refers to a remote wake method and device connected to a network.

It is thus an object of the present invention to advantageously address the aforementioned disadvantages and shortcomings of the prior art by proposing a method for the remote boot of devices that support wake-on-lan technology, as well as an apparatus for implementing this method.

It is a further object of the present invention to provide a method for the remote boot of devices, which support WOL technology, utilizing communication only at the application layer, i.e. layer 7 of the Open Systems Reference Model, without requiring communication to any of the lower levels between the devices involved in the process of booting a target-device.

A further advantage of the present invention is that it maintains the security level of a network without requiring any intervention therein, to facilitate remote boot of the target-devices.

A further advantage of the invention of the proposed method is the lack of a central point of failure, since there is not a central controller, but peer nodes, the more nodes being added to a domain, the higher the domain services’ availability. This therefore implies high availability, with low cost and low complexity.

A further advantage of the invention is the energy saving, because the actuator consumes minimal energy and since no other active devices are required, which would consume large amounts of energy, the total amount of energy consumed remains minimal.

Another object of the invention is to provide a system, which may have more than one actuator, thus ensuring uninterrupted operation, even in the event of failure of one of them.

Another advantage of the present invention is that the awakening of a target- device does not require any kind of incoming connection to the device's local network from external networks, which by default would reduce the level of security of the target-device local network. These and other objects, features and advantages of the invention will become apparent in the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will become apparent to those skilled in the art with reference to the accompanying drawings in which it is illustrated in a non-limiting manner.

Figures l(a)-(c) show illustrative variants of the activating device described in the present invention.

Figure 2 schematically shows a communication system, comprising the actuator, according to the invention, as well as the target-device, in a network protected by a firewall.

Figure 3 shows a schematic representation of a domain with nodes in local packet switching networks connected to a wider packet switching network. Among other things, a local network is presented with two actuator nodes, in parallel operation as well as nodes connected directly to the wider packet switching network.

Figure 4 shows a schematic representation of the communication between command device and actuator, at application layer, in order to achieve activation of the target-device.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

Referring now to the accompanying drawings, we will describe illustrative embodiments of the method for the remote boot of devices that support WOL technology. At the same time, a device will be presented for the implementation of the specific method.

The object of the invention is to boot a target-device (1), Fig. 2, which supports the WOL technology, connected to a local packet switching network that may be protected by a firewall (2), by means of an information processing device, which executes commands from other devices with which it participates in a file synchronization peer-to-peer network, without a central controller. The set of devices involved in the process for booting a target-device using WOL technology consist a boot domain. A domain consists of one or more target- devices and two or more nodes, of which at least one must be the command device and at least one must be the actuator, as described below.

The target-device (1) is an electronic information processing device, such as, but not limited to, a computer, a network printer, a central or peripheral industrial control unit connected to a local packet switching network, wired or wireless, that supports wake-on-lan technology, to boot or return to full operation from sleep mode.

A node is either an actuator (4) or a command device (5), Fig. 3.

An actuator (4) is the device used for the application of the remote boot method to devices that support wake-on-lan technology. It is a low energy consuming electronic device for processing information. It has a central processor, a random access memory, a permanent data storage space organized in a file system, one or more external device connection interfaces, such as a single serial bus (6), Fig. lb, known as USB, one or more packet switching network interfaces (7), Fig. la, which may be wired or wireless. It may additionally have control/programming keys (8), Fig. lc, and an information display screen (9). The actuator (4) can transmit wake-on-LAN magic packets over a local area network to target-devices (1) connected to the same local packet switching network (3).

The command device (5) is an electronic information processing device, such as a personal computer, a tablet computer, a mobile phone, or an automatic control system central unit, which gives command for booting a target-device (1) without being necessarily in the same local packet switching network as the target- device (1), nor in the same local packet switching network as the actuator (4) that will perform the awaking operation via the local network.

According to a method embodiment, the nodes and target-devices (1) of a domain can be located in the same local network (3), without this being limiting. The nodes of a domain may therefore be connected to different local area networks (3), Fig. 3, which are connected to a wider public or private packet switching network (10) and a firewall (2) may be inserted between each local area network (3) and the wider network (10), where the wall (2) rejects any incoming connection to the local network (3) it protects, at layers lower than layer 7 of the Open Systems Interconnection reference model. In a different embodiment some nodes of a domain may be connected to different local area networks (3), which are connected to a wider public or private network (10) and some nodes of the domain, i.e. actuators (4) or command devices (5), may be directly connected to the wider public or private network (10).

The nodes of a boot domain, i.e. actuators (4) and command devices (5) are organized in a file synchronization peer-to-peer network without a central controller. The file structure that is synchronized across all nodes in a domain is called the domain’s bus and can be either hierarchical or flat. Thus, each domain node has a local copy of the bus, which automatically synchronizes with all local copies held on the other nodes in the domain, as they all participate in the same file synchronization peer-to-peer network without a central controller.

In an implementation of the method where the bus is a hierarchical file structure, the bus contains folders (11), Fig. 4, each one supporting specific domain functions or storing domain-specific information. Each node creates and deletes files on the bus, according to the actions it executes (e.g. remote target-device (1) boot command, notification that a wake command was sent over a local network to a specific device, etc.). File creations and deletions propagate to the rest of the nodes thanks to file synchronization without a central controller, thus the bus facilitates data flow in the domain, without using a central controller that controls the nodes. Each node is checking the copy of the bus stored in its local file system, for events of file creation and deletion. Check is performed either at regular intervals, or in real time, utilizing subsystems of the node operating system, which provide immediate notification for events in the file system when they occur. Each node responds to the creation or deletion of a file, depending on the file type created or deleted and the type of node, i.e. whether it is an actuator (4) or a command device (5).

An indicative implementation of the method, wherein the bus consists of only two folders, the command folder where the target-device boot commands are stored and the event folder, where reports are recorded when a significant event occurs in the domain, is performed as follows. A command device (5) gives instructions for the boot of a target-device (1) by placing in the bus, and in particular in the command folder, a file containing the MAC address of the target- device (1) or other information from which the actuators (4) can infer this address. The actuators (4) monitor the command folder on the bus, using the appropriate subsystem of their operating system and as soon as a file creation event is detected, boot software is executed with command-line parameter the full name of the file created in the command folder. The boot software reads the contents of the file it received as parameter, and sends to the local network (3) a wake-on-LAN magic packet that refers to the MAC address it read or inferred from the file and finally deletes the file it read, after a period of time that ensures that the automatic file synchronization system will be able to synchronize the file to all nodes before it is deleted from the first node that received it.

Assuming that in the example of Fig. 4, a COM1 command device is located in a local network Nl, which is protected by a firewall Wl. This command device wants to boot a T2 target-device, located behind a W2 firewall, on a N2 local network. An ACT1 actuator is in the network N2. The target-device T2 has a MAC2 address, while the two networks are disconnected, but both being connected to the Internet. The COM1 device creates two files: one file in the command folder containing the MAC2 address of the target-device T2 and a file in the event folder whose content describes that a boot command was created by the COM1 for the device with the MAC2 address. The bus is automatically synchronized, so both files show up in the local copy of the bus on ACT1 actuator. When the command file creation is detected by the ACT1 actuator operating system, the ACT1 actuator reads it and then transmits a wake-on-LAN magic packet to the local network N2 through the local network referred to in MAC2, which corresponds to the target- device T2. At the same time, the ACT1 actuator creates a file in the event folder reporting that the WOL magic packet was sent from ACT1 actuator to MAC2 address. The command file is then deleted from ACT1 actuator. As the bus is automatically synchronized, the event file created by actuator ACT1 is also copied to the event folder in the local copy of the bus in command device COM1, while the command file is deleted from the command folder in the local copy of the bus in COM1.

As an alternative to using a hierarchical file structure where each folder is assigned a specific function, a flat file structure can be used, where the name of each file specifies its contents and how it should be treated by the domain nodes. In an example of a flat file structure application, files whose name has a .com extension contain boot commands, while files whose name has a .log extension contain event logs.

In alternative embodiments of the invention it becomes apparent that both the target-device (1) and the actuators (4) and command devices (5) may be connected to the same local packet switching network.

In further alternative embodiments of the invention it is possible to send a boot command from devices outside the domain. For example, if someone wants to give a boot command from a public computer, he can access a command device, which acts as a gateway for the domain to the Internet. The user, who may be a human or even a software, when he wants to send a boot command, is authenticated to a command device, which acts as an gateway, for example by using credentials that may include a username and a password and generates the boot command.

In a further alternative embodiment of the method, one or more actuators (4) may be connected to a local packet switching network (3), where one or more target-devices (1) may be located. When more than one actuator (4) is connected to the same local packet switching network (3), they work in parallel, performing exactly the same functions, thus increasing the domain availability: if an actuator (4) fails, it is certain that the functions will be executed by another.

In another alternative embodiment of the device, according to the invention, the actuator may have suitable connection ports (12) to which any input/output devices, such as a microphone, a camera or an audio output, can be connected.

It should be noted at this point that the description of the invention has been made with reference to illustrative embodiments, but not limited to. Therefore, any change or modification in anything concerning the shape, dimensions, components of construction and assembly, as well as the basic steps of the method, insofar they are not a new inventive step and do not contribute to the technical development of the already known, are considered contained in the purposes and aspects of the present invention, as summarized in the following claims.

Claims

1. A method for the remote boot of devices supporting wake-on-LAN technology, wherein at least one target-device (1) is connected to a local packet switching network (3), to which network at least one actuator (4) is connected and the actuator is organized in an automatic fde synchronization peer-to-peer network without a central controller, with at least one command device (5), characterized in that the command device (5) orders the boot of the target device (1) on all devices with which it is organized in a peer-to-peer network, communicating with them only at layer 7 of the Open Systems Interconnection reference model by creating a file from which the MAC address of the target device (1) is inferred, which is synchronized to the local copies of the automatically synchronized file structure across all peer nodes and in that when an actuator (4) detects a local copy of that file, sends a WOL magic packet, which refers to the MAC address of the target device (1) that identifies the file created by the command device (5) and then deletes that file..

2. A method for the remote boot of devices that support wake-on-LAN technology according to claim 1 , characterized in that the command device (5) is located on the same local data network (3) as the actuator (4).

3. A method for the remote boot of devices supporting wake-on-LAN technology according to claim 1, characterized in that the actuator (4) and the target device (1) are located behind a firewall (2).

4. A method for the remote boot of devices that support wake-on-LAN technology according to claim 1, characterized in that the command device (5) is located behind a firewall (2).

5. A method for the remote boot of devices that support wake-on-LAN technology according to claim 1, characterized in that the target-device (1), the actuator (4) and the command device (5) are connected to a wider private or public network (10).

6. A device for the remote boot of devices that support wake-on-LAN technology, defined as actuator (4), connected to a local data network (3) via a local area network interface (7), to which the target device (1) is connected, and which communicates with an information processing device, defined as command device (5), which orders booting the target device (1), characterized in that it consists of means of sending and receiving files and means of sending wake-on-LAN magic packets transmitted to the local network where it is connected.

7. A system for the remote boot of devices that support wake-on-LAN technology, consisting of at least one actuator (4) and at least one command device (5), characterized in that the actuator (4) and the command device (5) are organized in a file synchronization peer-to-peer network, without a central controller and communicate exclusively at layer 7 of the Open Systems Interconnection reference model.