[Approved] Powerscheduler network monitoring (share + traffic) (1 Viewer)

[Seidelin]

For getting the mac adress of the server in C# there may be some usable tips here

 

[arion_p]

As mentioned in a previous post, the code to get the MAC address from the IP is already implemented in PowerScheduler. So is the code to send WOL packets to the server. It just isn't used yet (see TvEngine.PowerScheduler.WakeOnLanManager class in TvEngine\TvLibrary\Plugins\PowerScheduler\PowerScheduler.Interfaces\WakeOnLanManager.cs)

Arion

 

[JBravo]

I did some quick tests with the "WakeOnLanManager", seems that most things are in place.

What i did was to add the following to the OnResume() method in PowerScheduler.cs :

//Start the server
      Log.Info("PowerScheduler: Start {0} with WOL", RemotePowerControl.HostName);
      WakeOnLanManager wakeOnLanManager = new WakeOnLanManager();

      byte[] hwAddress = new byte[6];      
      hwAddress = wakeOnLanManager.GetHardwareAddress(RemotePowerControl.HostName);
      

      Log.Info("PowerScheduler: Hardware address: {0:x}:{1:x}:{2:x}:{3:x}:{4:x}:{5:x}", hwAddress[0], hwAddress[1], hwAddress[2], hwAddress[3], hwAddress[4], hwAddress[5]);
      Log.Info("PowerScheduler: Hardware address length: {0}", hwAddress.Length);

      if (!wakeOnLanManager.IsValidEthernetAddress(hwAddress))
      {
        Log.Info("PowerScheduler: Invalid hw address, going hardcoded");

        hwAddress = wakeOnLanManager.GetHwAddrBytes("00:22:15:05:4e:5b");
        
        Log.Info("PowerScheduler: Hardware address: {0:x}:{1:x}:{2:x}:{3:x}:{4:x}:{5:x}", hwAddress[0], hwAddress[1], hwAddress[2], hwAddress[3], hwAddress[4], hwAddress[5]);
        Log.Info("PowerScheduler: Hardware address length: {0}", hwAddress.Length);
      }
      
      wakeOnLanManager.WakeupSystem(hwAddress, IPAddress.Parse(RemotePowerControl.HostName), 10);

Some problems I found:
GetHardwareAddress(..); returns 8bytes which yields an invalid hw address. Hardcoding the MAC solves the problem.

I also received an 00:..:00 MAC address when the server was removed from the ARP cache. I seems that the MAC is removed from the cache quite quickly. An ARP request is sent in this case, but to where? At least I didn't succed to retrieve a MAC.

The BIG problem is however that MP "hangs" at startup waiting for the TV server and this is before the PS plugin has been started...

 

[arion_p]

       byte[] hwAddress = new byte[6];      
      hwAddress = wakeOnLanManager.GetHardwareAddress(RemotePowerControl.HostName);

GetHardwareAddress(...) needs an IP address not a host name. You need to resolve the hostname to an IP address.

GetHardwareAddress(..); returns 8bytes

which yields an invalid hw address.

I took a look at GetHardwareAddress(...), and it has a bug. The following (lines 193-200):

        for (int i = 0; i < addrTable.Length; i++)
        {
          byte[] addr = address.GetAddressBytes();
          if (BitConverter.ToInt32(addr, 0) == addrTable[i].dwAddr)
          {
            return addrTable[i].bPhysAddr;
          }
        }

always returns the entire bPhysAddr buffer (which is 9 bytes long). It should return the first dwPhysAddrLen bytes.

I also received an 00:..:00 MAC address when the server was removed from the ARP cache. I seems that the MAC is removed from the cache quite quickly. An ARP request is sent in this case, but to where? At least I didn't succed to retrieve a MAC.

You are right that the ARP cache clears up quickly. It is so that we can avoid stale data. GetHardwareAddress(...) should be called while the TVServer is up and running. Just after TVClient successfully connects to TVServer, is a perfect time to call GetHardwareAddress(...) and store the MAC address locally in persistent storage (e.g. MP config file) for future use.

When you need the server's MAC address to send a WOL packet you can be sure that you cannot get it using GetHardwareAddress(...) because the ARP cache is long gone and the server is not running to answer the ARP request. That is why you needed to store it previously when the server was running. Now you can retrieve it from wherever you stored it and use it to wake up the server.

The BIG problem is however that MP "hangs" at startup waiting for the TV server and this is before the PS plugin has been started...

That is why the waking up has to be done just before TVClient connects to the server and not when PS plugin starts.

I hope the above helps.

Arion

 

[JBravo]

GetHardwareAddress(...) needs an IP address not a host name. You need to resolve the hostname to an IP address.

In my case RemotePowerControl.HostName contains an IP, the IP that I entered in TV client setup. I generally try to avoid NetBios. But you are right a it could be be an hostname, if that's the case it's it's needs to be resolved to an IP.

I took a look at GetHardwareAddress(...), and it has a bug. The following (lines 193-200):

That explains the invalid hw address...

As I see it the hwaddress needs to be stored, somehow.

Hope someone can help figuring out where to send the WOL. Or change the startup sequence...not likely.

 

[tourettes]

You are right that the ARP cache clears up quickly. It is so that we can avoid stale data. GetHardwareAddress(...) should be called while the TVServer is up and running. Just after TVClient successfully connects to TVServer, is a perfect time to call GetHardwareAddress(...) and store the MAC address locally in persistent storage (e.g. MP config file) for future use.

When you need the server's MAC address to send a WOL packet you can be sure that you cannot get it using GetHardwareAddress(...) because the ARP cache is long gone and the server is not running to answer the ARP request. That is why you needed to store it previously when the server was running. Now you can retrieve it from wherever you stored it and use it to wake up the server.

I'm just wondering if there is some cases that could cause issues with this. At least changing network adapter on server side could lead into non-working WOL, but maybe that could be solved with checking for the MAC changes on client side.

Of course this could cause wrong WOL messages with old MAC to be sent as long as some manually powers up the server and then client at the same time. Not a big issue, but should be documented into WIKI.

 

[tourettes]

Hope someone can help figuring out where to send the WOL.

How about modifying the wakeOnLanManager.WakeupSystem() to be asynchronous? Not sure if it will have any side effects, but at least it wouldn't stall the loading process and the earlier you send the WOL message the better as server would be ready quicker.

 

[JBravo]

You are right that the ARP cache clears up quickly. It is so that we can avoid stale data. GetHardwareAddress(...) should be called while the TVServer is up and running. Just after TVClient successfully connects to TVServer, is a perfect time to call GetHardwareAddress(...) and store the MAC address locally in persistent storage (e.g. MP config file) for future use.

When you need the server's MAC address to send a WOL packet you can be sure that you cannot get it using GetHardwareAddress(...) because the ARP cache is long gone and the server is not running to answer the ARP request. That is why you needed to store it previously when the server was running. Now you can retrieve it from wherever you stored it and use it to wake up the server.

I'm just wondering if there is some cases that could cause issues with this. At least changing network adapter on server side could lead into non-working WOL, but maybe that could be solved with checking for the MAC changes on client side.

Of course this could cause wrong WOL messages with old MAC to be sent as long as some manually powers up the server and then client at the same time. Not a big issue, but should be documented into WIKI.

This dynamic handling will introduce some considerations. The easy way is just to let the user input the server MAC address in the configuration. At least I think this should be an option.

 

[tourettes]

This dynamic handling will introduce some considerations. The easy way is just to let the user input the server MAC address in the configuration. At least I think this should be an option.

Yes, it would be better if we have both in use. If MAC address is configured as 00:00:00:00:00:00 then we should use the automatic MAC address fetching and if it is configured to something else then use that instead. Or we could have a setting to enabled / disable the automatic MAC address lookup. Which ever is easier from the user point of view.

 

[JBravo]

Hope someone can help figuring out where to send the WOL.

How about modifying the wakeOnLanManager.WakeupSystem() to be asynchronous? Not sure if it will have any side effects, but at least it wouldn't stall the loading process and the earlier you send the WOL message the better as server would be ready quicker.

It's not the WakeupSystem call that stalls the loading process. The loading process is stalled before PS plugin is even loaded. Don't know where the loading stalls but I assume it's the TV client plugin that tries to connect to the server.

An option is to move wakeonlanmanager from PS plugin to somewhere earlier in the startup process (TV client plugin?).