WOL unable to send magic packet network unreachable

English Network/Internet
21

On 2014-12-21 18:16, arvidjaar wrote:
>
> robin_listas;2684376 Wrote:
>>
>> I understand that the network can not be automatically restored till the
>> server is up and responds (because it has the dhcpd). And to awake the
>> server he needs to send it a wol packet.
>
> Do you mean you are trying to send WOL packet back to the same system?
> I.e. host A sends WOL to host A?

No, no :slight_smile:

Ok, he has a server machine, and it runs the dhcpd daemon for the
network (and other things, I assume). This server is configured to go to
sleep on no activity, somehow automatically.

He basically wants the clients to sent WOL packets to the server to
awake it and get service, automatically, when the clients awake from
suspend/hibernation (or get powered up, I assume).

If this happens within an interval, the IP of the client is still valid,
its network is up, it can send the WOL packet, and wake up the server
nicely.

However, after that interval, the IP of the client is lost, and the
‘wol’ program refuses to run (in the client).

So the process is starting the network on a fixed IP instead of dhcp (on
client machine), send the WOL to the server, confirm that it is up, then
destroy that interface, and restart netowrk manager so that it gets the
normal dhcp address.

Which is an interesting project :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

22

What is really needed is for a WOL client to be built in to NetworkManager. That would remove the need for any of these workarounds. Perhaps worth submitting such a feature request. In the past, NM had a ‘pre-up’ event trigger, that could be used for this type of use case. It would have been capable of triggering on the presence of a network interface, and brought up that interface with a temproary fixed address, then dropped the interface after the magic packet had been sent. (Which is what I was attempting to illustrate in my last post.)

I’ve dug up discussions which show that it was removed upstream (a long time ago), and annoyed a few doing so:

Anyway, it should still be possible to write a custom systemd service, which runs at the right time (ahead of the NetworkManager.service) and does the necessary.

There is a network-pre.target as part of systemd > 213 (opensUSE 13.1 uses 210)

network-pre.target
This passive target unit may be pulled in by services that want
to run before any network is set up, for example for the purpose
of setting up a firewall. All network management software orders
itself after this target, but does not pull it in.

It has been discussed in this opensuse bug report as it happens. (It would be useful for creating a WOL client service IMO.)

23

@seuchato: I assume your client machines are connected via a common router? If so, you could have this facilitate the DHCP server (rather than your PC server), then all that is needed is to send the magic packet via a dispatcher script once the interface ‘up’ event is triggered.

24

Yep, I was blind, the script runs if the ']'brackets are changed to double ‘]]’ brackets. Guess I need to brush the rust away from my scripting knowledge :slight_smile:

cat wolserver 
#!/bin/bash
interface=$1 status=$2
case $status in
  up)
    if  "$interface" = "enp0s25" ]]; then
        ifconfig enp0s25 192.168.10.1 up
        /usr/bin/wol 00:22:4D:B1:E7:D0 -h 192.168.10.255
        ifconfig enp0s25 down
        #systemctl restart network
    fi
    ;;
 esac

I get even a part success: When booting this morning, I did not recall the server being shut down. I was quite a bit surprised when all of a sudden the server booted. I could ge used to that though :-).

But there is another problem to solve now:
As you might note, the line with “#systemctl restart network” is commented out. I guess it creates a kind of a infinet loop. If the client is put into suspend, it does not really resume anymore. Strange enough, it boots though. But it is obvious, the loop must be avoided. My bet bet would be to set up a second fixed IP for enp0s25. That second IP could be set and stay there forever just to be used to pass the magic packet.

If this resolves it, one would have to teach NM to st the second fix IP while asking an IP through dhcp on the first. I am off to dig this up.

greez

chris

25

This might get a bit a long reply :slight_smile:

…

Yes, I am aware of that. I tried 00 49 and 99. Will check again with 05 and 95. My observation was that the script was killed as soon as pm-suspend.log was closed. It did not eve compete a single loop when run as 00serverwakeupcall. And yes, I moved “serverwakeup” on dir up and it did not get call a second time.

Need to check that later, but that is just to verify in the script that the server is up by tis method, which I can confirm is unfortunately not the case.

Keep them coming, and please do not spare the really wild ones :slight_smile:

A very good summary

Oh, the solution of my dreams gets named, Is ther a place wher I can subscribe to this?

Deano, yes, I have a router that could provide dhcp. However I am a bit paranoid and thus I have that behind the firwall on my server. I would really like to keep it that way. Also there is a SOC sniffing traffic in between router and server, in order to trigger an intruder alert. That would be rendered obsolete. Else, that would be a simple and very nice idea.

greez

chris

26

Yes, I’m rusty too, but nothing that can’t be polished when necessary.

I get even a part success: When booting this morning, I did not recall the server being shut down. I was quite a bit surprised when all of a sudden the server booted. I could ge used to that though :-).

Progress huh? :slight_smile:

But there is another problem to solve now:
As you might note, the line with “#systemctl restart network” is commented out. I guess it creates a kind of a infinet loop. If the client is put into suspend, it does not really resume anymore. Strange enough, it boots though. But it is obvious, the loop must be avoided. My bet bet would be to set up a second fixed IP for enp0s25. That second IP could be set and stay there forever just to be used to pass the magic packet.

Why did you think that ‘systemctl restart network’ was needed? I can see that this would cause problems here. :slight_smile:

I wonder if you could set the DHCP connection (from within the script) with something like

nmcli connection up id <name of primary connection>

For example, I have a wired ethernet connection defined as ‘DHCP’, so I can do

nmcli connection up id DHCP

to activate it.

27

Hi all

Was too busy yesterday to follow up here.

Regarding the success to wakeup the server while booting, I should point out that I added the following:

/etc/init.d # cat boot.local 
#! /bin/sh
#
# Copyright (c) 2002 SuSE Linux AG Nuernberg, Germany.  All rights reserved.
#
# Author: Werner Fink, 1996
#         Burchard Steinbild, 1996
#
# /etc/init.d/boot.local
#
# script with local commands to be executed from init on system startup
#
# Here you should add things, that should happen directly after booting
# before we're going to the first run level.
#

################################################################################
# send magic packet to server(s)
# brutus 00:22:4D:B1:E7:D0
################################################################################

ifconfig enp0s25 192.168.10.1 up
/usr/bin/wol 00:22:4D:B1:E7:D0 -h 192.168.10.255
ifconfig enp0s25 192.168.10.1 down

That did te trick to wake up the server, but creates another woe: the client’s interface is now stuck at 192.168.10.1, meaning when I log in, no access to the server. So I guess the way to get around all this is probably just to set up aliases to the network interface , one for server connections and another one to be used by wol alone. That would resolve the problems with one single strike. But how can I set up the nic for wol with a fixe IP and the otherone for day to day use by dhcp?
Clicked on nm tray symbol, then the wrench symbol. This opened the “Verbindungs-Editor” (sorry Carlos, LANG=en defunct for this https://forums.opensuse.org/images/icons/icon11.png), guess in English tat would be the “Connection-Editor”. I clicked on the green “+ Hinzufügen” ("+ Add" I guess) symbol and clicked on “VLAN”. I gave the connection the name “VLAN for WOL”, in the tab “VLAN”, I let the supperior NIC field empty, let VLAN ID at “0” (for the time being) and gave the interface the name woleth.

changed the NM dispatcher script as follows:

/etc/NetworkManager/dispatcher.d # cat wakeupserver 
#!/bin/bash
interface=$1 status=$2
case $status in
  up)
    if  "$interface" = "woleth" ]]; then
        /usr/bin/wol 00:22:4D:B1:E7:D0 -h 192.168.10.255
    fi
    ;;
 esac

Gave it a try, STR the client and server, open lid of client again and : Tadaa the server get’s woken up, too early for a beer though not only because it is still before noon :-), still need to check if all that remains persistent and the whole thing really works during boot as well.
As we should hav woleth prsistent the boot.local script gets changed as follows

/etc/init.d # cat boot.local 
#! /bin/sh
#
# Copyright (c) 2002 SuSE Linux AG Nuernberg, Germany.  All rights reserved.
#
# Author: Werner Fink, 1996
#         Burchard Steinbild, 1996
#
# /etc/init.d/boot.local
#
# script with local commands to be executed from init on system startup
#
# Here you should add things, that should happen directly after booting
# before we're going to the first run level.
#

################################################################################
# send magic packet to server(s)
# brutus 00:22:4D:B1:E7:D0
################################################################################

/usr/bin/wol 00:22:4D:B1:E7:D0 -h 192.168.10.255

shutdown and reboot, no joy at all, instead more troubles. Now enp0s25 has a fixd IP of 192.168.10.1. Why that?

So I tried to turn every stone in /etc/ and /usr/lib/systemd, but I just cannot seem to fin where NM got the d*&% information from to set enp0s25 to the fixed IP 192.168.10.1. I need support here.

Go the client up working only when switching from NM to wicked. A solution acceptable only for debugging this 'cause as mentioned wicked has no applet for airplane mode.

Greez

chris

28

Hi all

some progress, new problem.

Progress like this:
in NM set enp0s25 to fixed IP. Does not matter what you use, as long as it is within a private range.

/etc/NetworkManager/dispatcher.d # cat wakeupserver 
#!/bin/bash
interface=$1 status=$2
case $status in
  up)
    if  "$interface" = "enp0s25" ]]; then
        /usr/bin/wol 00:22:4D:B1:E7:D0 -h 192.168.10.255
    fi
    ;;
 esac

Now, everytime I send Client and server to STR and subsequently wake up the client again, the server sure gets its wake up call and resumes. Perfect, but ubfortunately there is a but:

New problem:
As I have the clients NI enp0s25 with afixed IP outside the LAN scope, I do have no LAN connection to the server anymore. No file sharing, No internet, no whatsoever. Ok I thought, that should be manageable by setting up a virtual interface with NM. Done so, got enp0s25.0 with master (I hope these terms meet NM speak) enp0s25, tagged VLAN 0, named the connection ‘LAN dhcp’ and gave everyone the possibility to connect through this connection. saved it and went to connect. Server gets a dhcprequest and snds a dhcpoffer, but the interface is not activated. As soon as dhcp requests en ifconfig stops showing enp0s25.0.

So, how do I set up such a second virtual lan?

Hope someone could help, friend google is really quiet here.

greez and merry christmas

chris

29

First, VLAN 0 means “no VLAN”. Then, tagged VLANs must be supported on both sides of physical link - your switch where you are connected must be setup to know about this VLAN and process traffic accordingly. You cannot simply create VLANs on one side.

Why do you need special IP range? Just use broadcast address for your “normal” network you use. IP address itself does not matter - it is used by wol to select interface to use, so it should match one of your interfaces, that’s all.

30

arvidjaar

Changed the vlan tag to 23, no change and no wonder, there is one dumb switch that thas not support vlans. However, dhcp request still comes through though, only servers reply is not seen the vlan on the client, why this? I might consider the view switches in our lan to be replaced though. Guess I need to get more knowledge about vlans still.

But your comment brought me to the ieda of just as a proof of concept set enp0s25 to two ip’s, one to bring the magic packts through and the other or standard lan too. Sure, as you argued, one fixed IP would do the trick, but fiddling around with fixed IP’s feels to me like in the old age, when water and coal whree needed to get something moving. My idea is to clearly isolate where the remaining problem lies. So, enps0s25 does have two fixe IP’s for now:

  • 192.168.10.1 to blow the magic packet through, this could stay forever
  • 192.168.23.150 to get all lan traffic, internet and so on through. This should later be somehow set to dhcp, maybe not on enp0s25, but on something else, prefferably not being a seon NIC

OK, here we go, close lid of client, send server to STR, get a coffee, open lid of client and server wakes up too (should have been an irish coffee thus, but too early yet:-)).

I take this as aproof of concept, It can be done. What is still required, is to get the Lan traffic part set up by using dhcp. Tat’s hwere it hurts for now an any help in this (hopefully) last issue is greatly appreciated.

greez

chris