Wake on lan from web interface send with server or host ?

[Florent]

Hi,
I have weird behavior with wake on lan with the web interface (basic tasks -> advanced -> wake-up)

This work only if i launch the task on the web interface from host in the same vlan.
If i test from host in other vlan (always with web interface), it’s not work.

I test from FOG server (who is in other vlan) : /usr/bin/wakeonlan 00:11:22:xx and it’s works

When we launch wake-up from web interface is it the server who send wakeonlan command or the host from which clic on the web interface ?

Regards

[Wayne Workman]

@florent said in Wake on lan from web interface send with server or host ?:

is it the server who send wakeonlan command or the host from which clic on the web interface ?

It’s done via PHP on the server-side.

[Florent]

I think found the problem but don’t know how to resolve this.

If i launch task on the web interface with HTTPS it’s not work.
But if i launch web interface with HTTP unsecure it’s work.

Ideas ?

[Sebastian Roth]

@Florent Which version of FOG do you have. Are you sure you can replicate the issue when creating the wake task over a HTTPS connection?

[Florent]

@sebastian-roth
Hi,
I use FOG 1.5.4
I have just done a new test and work on http but not https.
I use Firefox 61.0.1 64 bits without extensions.

I use on the host : Basic Task -> Advanced -> Wake-up

See my virtualhost conf for https :

<VirtualHost *:443>
    KeepAlive Off

    ServerName fog.mydomain
    ServerAlias fog.mydomain

    #<FilesMatch "\.php$">
    #    SetHandler "proxy:fcgi://127.0.0.1:9000/"
    #</FilesMatch>

    DocumentRoot /var/www/fog
    <Directory /var/www/fog/>
        DirectoryIndex index.php index.html index.htm
    Require all granted
    </Directory>

    RewriteEngine On
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
    RewriteRule ^/(.*)$ /fog/api/index.php [QSA,L]

    # -------------------------------------------------------------------------
    # SSL
    #Header always set X-Frame-Options SAMEORIGIN
    #Header always unset X-Frame-Options
    SSLEngine on
    SSLCertificateFile      /etc/apache2/certs/XXX.pem
    SSLCertificateKeyFile   /etc/apache2/certs/private/XXX.key

    SSLVerifyClient none
    SSLVerifyDepth 3
  BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

    # -------------------------------------------------------------------------
    # Logs 
    LogLevel warn
    ErrorLog  ${APACHE_LOG_DIR}/fog-ssl-error.log
    LogFormat "TO %v:%p FROM %h VIA %{X-Forwarded-For}i %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\" \"%{Content-Type}o\" %T %D" logstash
    CustomLog ${APACHE_LOG_DIR}/fog-ssl-access.log logstash

</VirtualHost>

[Sebastian Roth]

@Florent Sorry for the very long delay. Just couldn’t find the time to setup a test system and get into it.

I just installed a clean test machine using Debian 9 and FOG 1.5.4. Installed with --force-https parameter and tried to schedule a WOL task for one of my clients. As soon as I hit the button I see four WOL packets in wireshark. Although this is a virtual machine test setup I am pretty much sure Wake-Up task is working even on a HTTPS enabled FOG install. Still I can’t think of any way HTTPS could play a role in wake on lan issues?!?

Did you schedule the Wake-Up tasks via HTTP and HTTPS from the same FOG server or is it two different servers (possibly being in a different subnet)?

[Florent]

@Sebastian-Roth ,
I do new test and same problem.
Tests are done on the same server.
Same problem with Firefox or Chromium with https://fog.mydomain.com (Hosts -> Basic Tasks -> Advanced / Wake-up -> Schedule Instant).
If i do same with http://fog.mydomain.com it’s works.
Don’t understand why, so i use http instead of https

[Sebastian Roth]

@Florent Did you install FOG with --force-https parameter or manually configured HTTPS?

Please try the following: Install tcpdump package on your FOG server. Then log into the web UI via HTTPS and prepare to schedule a ware-up task for a host but don’t start it yet. On the command shell run: sudo tcpdump -i <interface> udp port 9 (you can use ip a s command to find out the interface name to put in instead of <interface> - could be eth0 or enp2s0 or something like that)

Leave that command as is, it will print the network packets it finds on screen. Not back to the web UI and hit the button to schedule the wake up task. Wait for 5 seconds, then go back to the console window and stop tcpdump (ctrl+c). Take a picture of the print out and post here.

Now you can to the same thing but using HTTP URL. As well take a picture of the packets shown by tcpdump and post here.

[Florent]

@Sebastian-Roth
ok I’ll try this as soon as I have a moment.
Don’t remember if i have use –force-https , but sure manually configured https in my virtualhost