Not corrupted in a strict sense, but I had one slave that I turned IPv6 off on it (I don’t use IPv6 addresses at my studio).
The problem was that the slave info wasn’t able to fetch the correct IPv6 address and also the MAC address. It wrote FF:FF:FF:FF:FF instead.
So, as you can imagine, PowerManagement wasn’t able to wake the machine up. I had to turn the machine on manually and enable IPv6 on it. That was it. Slave info got updated correctly and now all seems working again.
Thanks for reporting this. Deadline uses FF:FF:FF:FF:FF:FF as a “dummy” MAC address when it is unable to collect it for the IP address that is being used. We have a bunch of IPv6 capable machines here, so we’ll try to reproduce it and see what we can figure out.
The strangest thing is, I disabled IPv6 even on the server, so, it should not be used on any of the machines. But when it was off, Deadline wasn’t able to update the slave info properly and used the dummy MAC address instead. Which caused the problem with Power Management WOL broadcast.
In my limited experience of IPv6 (we too turned this OFF internally), this sounds vaguely familiar and I kind of have a hazy memory of having to delete the slaves out of the queue and let them re-create their info files to fix the issue…
Might be wrong on this tho…
Mike
Got the same issue here, no proper MAC without IP6, but we got some old machines with windows xp, and they work fine with just the default windows ip/tcp setup.
Seems like the same issue reported here. Just enabling IPv6 on the slave does cause the Slave Info panel to show the right MAC address, but then it also shows a v6 IP address, which we are not actually using.
Though I would have thought as long as the .slaveinfo file has the right MAC address, then wake-on-LAN would work, but that doesn’t seem to be true in my case, at least via the “Start Machine” option in Monitor. I can wake-on-lan using a test utility (port 9) so I’m confident the node machine is properly configured.