WOL RC7 Not working

Tom Elliott

These messages have no bearing in regards to WOL. Nothing has changed for WOL since March 8, which 1.4.0-RC-1 was released and proven to have been working (was released 24-MAR-2017).

Tom Elliott

To fix the streaming issue,

run chown -R fog:www-data /var/log/apache2; chmod -R 755 /var/log/apache2 and you should have your logs available until the next time logrotate runs.

UWPVIOLATOR

@Tom-Elliott

sudo chown -R fog:www-root /var/log/apache2; chmod -R 755 /var/log/apache2
chown: invalid group: ‘fog:www-root’

Also where can I look to see why WOL stopped working?

Tom Elliott

Typo’d sorry. Updated the command to use the proper thing. I don’t know. No changes. Maybe you might be able to install RC-6 see if it worked, if so i can mroe direclty figure out where a problem was introduced.

alexandh

We have the same problem, that WOL is not working

Indeed the problems do not reflect a WOL problem.

We updated from fog 0.32 to 1.3.5 . After that WOL is not working. Same with 1.4.0-RC-8.
I monitored the output on the network card with tcpdump with the result that no packets are generated. With the wakeonlan command, the packet is generated and the client wakes up…

Tom Elliott

@alexandh As I asked, can you install RC-6 and see if all works?

Mind trying:

http://fogserver/fog/index.php?sub=wakeEmUp&mac=<macofhost>

I don’t think it’s the code sending the wake on lan, rather it is missing when to send it.

Is this ALL tasks or once again ONLY the wake task?

alexandh

@Tom-Elliott
This does not work neither does any wake task or wake tasks with deploy or upload…

I tested a script imitating the code with creating the socket and that works:

<?php
$msg=sprintf(
                '%s%s',
                str_repeat(chr(255), 6),
                str_repeat("901B0ECA8977", 16)
            );

/**
         * Assume return will be true for now.
         */
        /**
         * Create our socket resource
         */
        $sock = @socket_create(
            AF_INET,
            SOCK_DGRAM,
            SOL_UDP
        );
        /**
         * If failed, immediately return.
         */
        if ($sock == false) {
            return false;
        }
        /**
         * Set our coket options
         */
        $set_opt = @socket_set_option(
            $sock,
            SOL_SOCKET,
            SO_BROADCAST,
            true
        );
        /**
         * If invalid close socket and return immediately.
         */
        if ($set_opt < 0) {
            @socket_close($sock);
            return false;
        }
        /**
         * Send our wake up packet.
         */
        $sendto = @socket_sendto(
            $sock,
            $msg,
            strlen($msg),
            0,
            "255.255.255.255",
            9
        );
        /**
         * If failed set return to false;
         */
        if (!$sendto) {
            $ret = false;
        }
        /**
         * Close the socket.
         */
        @socket_close($sock);
        /**
         * Return value
         */

?>

tcpdump says then:
IP xxx.xxx.xxx.xxx.45962 > 255.255.255.255.9: UDP, length 198

alexandh

@alexandh
This means the problem should be in the _msg code or at creating $ip…

Tom Elliott

Just tested:

These are the “dumps” I’m seeing:

tcpdump: listening on ens32, link-type EN10MB (Ethernet), capture size 262144 bytes
2017-04-24 12:15:28.199847 IP (tos 0x0, ttl 64, id 39138, offset 0, flags [DF], proto UDP (17), length 130)
    10.2.1.5.59289 > 255.255.255.255.discard: [udp sum ok] UDP, length 102
2017-04-24 12:15:28.200018 IP (tos 0x0, ttl 64, id 56882, offset 0, flags [DF], proto UDP (17), length 130)
    10.2.1.5.38950 > 10.255.255.255.discard: [udp sum ok] UDP, length 102
2017-04-24 12:15:28.200304 IP (tos 0x0, ttl 64, id 39139, offset 0, flags [DF], proto UDP (17), length 130)
    10.2.1.5.55483 > 255.255.255.255.discard: [udp sum ok] UDP, length 102
2017-04-24 12:15:28.200370 IP (tos 0x0, ttl 64, id 56883, offset 0, flags [DF], proto UDP (17), length 130)
    10.2.1.5.53237 > 10.255.255.255.discard: [udp sum ok] UDP, length 102
2017-04-24 12:15:28.379735 IP (tos 0x0, ttl 64, id 20606, offset 0, flags [DF], proto UDP (17), length 130)
    10.0.7.1.37662 > 255.255.255.255.discard: [bad udp cksum 0x1180 -> 0x92a8!] UDP, length 102
2017-04-24 12:15:28.379785 IP (tos 0x0, ttl 64, id 56505, offset 0, flags [DF], proto UDP (17), length 130)
    10.0.7.1.46809 > 10.255.255.255.discard: [bad udp cksum 0x1c7f -> 0x63ee!] UDP, length 102
2017-04-24 12:15:28.379820 IP (tos 0x0, ttl 64, id 20607, offset 0, flags [DF], proto UDP (17), length 130)
    10.0.7.1.53579 > 255.255.255.255.discard: [bad udp cksum 0x1180 -> 0x53db!] UDP, length 102
2017-04-24 12:15:28.379848 IP (tos 0x0, ttl 64, id 56506, offset 0, flags [DF], proto UDP (17), length 130)
    10.0.7.1.44467 > 10.255.255.255.discard: [bad udp cksum 0x1c7f -> 0x6c74!] UDP, length 102

Tom Elliott

So based on the information I’m seeing, there is indeed no changes to code. As to why your’s isn’t working I don’t know.

My comand for tcpdump is:

tcpdump -i ens32 -ttttvvvvnS port 9

All I’m doing is a Wake Up Task.

For what it’s worth Testing with capture and deploy to the same host (for testing purposes) appears to be working as expected as well. I’ve tested with multiple nics on one host and single nic on another host and all packets required to be sent appear to be sending.

Tom Elliott

So to further drive home all of this. I ran through RC’s 1 through 8 and tested. I have one laptop that i had not had connected to FOG at all, so I decided to make a host entry.

I also tested working branch just to ensure things were still operational in current code base.

I tested Deploy WOL, Capture WOL, and plain-jane WOL Task types. All RC’s worked from this point forward.

Just to ensure things in the automated realm were still operational I also tested Deploy/capture using FOG Scheduler to start the host as needed. Things worked properly using the current code base.

alexandh

@Tom-Elliott said in WOL RC7 Not working:

tcpdump -i ens32 -ttttvvvvnS port 9

Had to fix an issue with RC-2+ because boot.php fatal error and now fully working on 1.4.0-RC-8 : https://forums.fogproject.org/topic/9864/could-not-boot

UDP packets are now emitted!
2017-04-25 09:49:44.255319 IP (tos 0x0, ttl 64, id 49724, offset 0, flags [DF], proto UDP (17), length 130)
    xxx.xxx.xxx.xxx.49978 > 255.255.255.255.9: [bad udp cksum 0x46e7 -> 0x4499!] UDP, length 102
2017-04-25 09:49:44.255528 IP (tos 0x0, ttl 64, id 2545, offset 0, flags [DF], proto UDP (17), length 130)
    xxx.xxx.xxx.xxx.39928 > xxx.xxx.xxx.255.9: [bad udp cksum 0x8de9 -> 0x24d9!] UDP, length 102

Some clients work now.
Looks good.

Tom Elliott

@alexandh If I had to guess as to the problem of some clients working vs some clients not working, it’s related to VLAN?

UWPVIOLATOR

@Tom-Elliott @alexandh

I am lost. What needed to be fixed or what should I do to see what’s going on our end?

UWPVIOLATOR

Issue is resolved or us

Looks like our WOL Broadcast Management settings were all wiped. Adding our Broadcast IP back and it worked.

WOL RC7 Not working

198

12.0k

17.3k

155.2k