Time range wake on lan question.

Viewing 9 posts - 1 through 9 (of 9 total)
  • 16th January 2020 at 10:20 am #27695


    I have a question about Scheduled wakeup.

    When wakeup node using Schedule wakeup setting, is it necessary to combine with options such as Available, Full load, and Pool Require?

    After the specified time with only the scheduled wakeup set, the Dispatcher log will show “Waking up host <HOSTNAME> (IPADDR)-Host matched time rule”, but the machine will not actually start.

    Testing Environment:
    -Dispatcher version: 9.0.13, 9.0.14-11518
    -Node version: 9.0.13, 9.0.14-11518
    -Wakeup manually from Dispatcher: Success
    -When the farm is at full load: off
    -When the client is required by a job pool: off
    -Matches wakeup rules with availability rules: off
    Day range, Mon-Fri, 10: 00-20: 00, wake up

    17th January 2020 at 12:00 pm #27749

    Hi there,

    If you get a wakeup in the log, that means the message is effectively sent. Consider that the wakeup you send manually is sent from Console, not the Dispatcher, so be sure that the dispatcher UDP connections can reach your clients

    20th January 2020 at 5:55 am #27877

    Hi Leonardo,

    Thanks for your reply.

    We have confirmed that the dispatcher server (CentOS 7) can be started from the server using Ether-Wake or a self-made script that sends WoL packets to UDP port 7 or 9.

    At the timing when the log that executed WoL by the dispatcher was output, packets could not be captured by tcpdump, and it was not possible to confirm whether or not they were being executed.

    Packet capture command
    tcpdump -UlnXi eth0 ether proto 0x0842 or udp port 9 or udp port 7

    Is it possible to check in other ways?

    As additional information,
    Two options, “When the farm is at full load” and “When the client is required by a job pool”, performed WoL and confirmed that the node started.
    However, packets cannot be captured by tcpdump.

    Best regards.

    24th January 2020 at 10:28 am #28081

    After inspecting some stuff, the manual sent WOL packet is sent on port 40000, that is the default WOL port by specs, while the automated Wakeup is sent to a random port, while this works in most circumstances because the WOL just need to have the headers regardless of the port where is sent, some machine/OS distinguish between port 40000, 7 and 9. We are packing this configurable for the next release.


    27th January 2020 at 5:37 am #28217

    Hi Leonardo,

    Thanks for your reply.

    Since it was any port of 7,9,40000 / UDP, I tried to capture with the following pattern.
    Also, taking into account the possibility of jumping to a random port, we tried to capture the entire UDP packet, rewrite the filter of tcpdump to filter only some UDP / SSH packets, and tried to capture.
    The result is as follows:
    tcpdump command:
    tcpdump -i eth0 -ne src host and udp port not \(137 or 138 or 546 or 5355 or 5353 or 1947 or 4679 \) and tcp port not 22 and not arp

    Note: ― Dispatcher IP ― Node IP

    – “When the farm is at full load” Only -> Success

    Dispatcher log: 12:50:02 Waking up host gem88( - Farm at full load
    tcpdump log: 12: 50: 03.890666 26: c6: cb: 9e: a8: 39> Broadcast, ethertype IPv4 (0x0800), length 144:> UDP, length 102

    – “When the client is required by a job pool” Only -> Success

    Dispatcher log: 13:05:10 Waking up host gem88( - required pool
    tcpdump log: 13: 05: 11.276099 26: c6: cb: 9e: a8: 39> Broadcast, ethertype IPv4 (0x0800), length 144:> UDP, length 102

    – Schedule Only -> Failure
      Day range, Mon-Fri, 10: 00-20: 00, wake up

     Dispatcher log: 12:03:55 Waking up host gem88( - Host matched time rule 
      tcpdump log: not logging

    – Schedule and Available match rule. -> Failure
    Day range, Mon-Fri, 10: 00-20: 00, wake up
     (Wake-up schedule and available schedule are at the same time.)
    tcpdump log : not logging

    Considering the possibility of our environmental problems, we set up another server,
    The result was the same as above.
    Are others working?


    27th January 2020 at 7:59 am #28222

    Yes it seems to work on most circumstances but as I said it is effectively a bug and we already patched it to be sent to port 40000 under any circumstances at the moment. For the next service release, the port will be configurable because many systems distinguish between 7 and 9. On what version are you actually ?
    We can send you an hot fix that at the moment is assured to send the WOL of port 40000. In the meanwhile we are going to check if there’s any difference when the WOL is sent by rules but I suspect there’s no difference.
    Are you on V9 LTS ?

    27th January 2020 at 8:56 am #28225

    Hi Leonardo,

    Thanks for your reply.

    Currently the main version is V9 (9.0.13),
    We will switch to V9 LTS (9.0.14-11518).
    In addition, we are testing the operation this time with V9 LTS.

    27th January 2020 at 9:30 am #28228

    Do not try 11518, it has the same problem, get in touch with me with a support ticket and I’ll send you a link to an hot fix. Please specify if you’re running Windows or Linux

    27th January 2020 at 9:46 am #28229

    Hi Leonardo,

    Ticket Created

    Thank you.

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.