WAKE ON LAN - It does *not* work!

Pearl & Pearl-2 General
1

Wake-on-LAN does not work !! Sorry !

We’re getting really annoyed here …

Recently we have invested a lot of time to get the Wake-On-LAN function in the Pearl-2 and PearMini systems to work - no CHANCE !!

The WOL features announced does not work, although the devices have an active LAN interface (with 10 Mbps) after being switched off, which is also quit common for WOL in such a special stand by mode.

Since these devices are distributed around our campus here and, thanks to NDI support even now working over subnets, these encoders can now also be used remotely. So this WOL function is getting now very important here - if it would work …

Unfortunately, it doesn’t help if Epiphan keeps saying that WOL works in their Pearls (https://www.epiphan.com/forum/t/remote-power-on-off/2516)), but at the end there is no proof, that it really works ?

At the end of our test series here we have connected a (Windows) PC directly via a LAN cable (1: 1 and/or cross-over assignment) to a Pearl-Mini. If the Pearl is active, communication runs perfectly …

But if the Pearl is shut down “by software command” (Maintenance -> Power Off), the LAN-interface goes into the 10Mbps state, but that’s it … never woke up again.

@EPIPHAN … Please name any software or a program with which this scenario works in your environment !!! Then there are no “excuses” possible, that any “unknown network” might be the reason why it does not work … we now do have only a 1: 1 LAN cable connection.

Note: We also used a LAN analyzer Software (e.g. Wireshark) which shows that always correct WOL packets are sent to the Pearl interface.

We have already checked various programs here in our network laboratory at our university, … which always wake up various systems or PCs, but ust * not * any of our PEARL-2 or PEARL-Mini.

It is annoying enough that a Pearl cannot shut down time-controlled via the software (only manually via WEB interface), but then it should at least be possible to wake it up the Pearl again without having to walk across the whole campus to the respective location !!

Regards,

2

I’m really sorry to see that you and your team are continuing to face issues with WOL with the Pearl family.

I can certainly understand your frustration given that Pearl-2 or Pearl Mini are not behaving as you would expect them to. I have spoken to the manager of the QA team regarding your testing and your questions and his team will be touching base with me as soon as possible regarding testing.

WOL does work with Pearl-2 to date with all of our direct testing, however no pre-baked software applications are being used to issue these tests and commands. Rather, our QA team and Development teams utilize a basic Python script to trigger the command, which is tested on weekly cycles throughout firmware testing and development.
That being said, I brought it to the attention of the QA team that you were experiencing this WOL issue specifically regarding software shutdown from the Web UI on the maintenance page. They will be testing this specific behavior use case to see if they can reproduce it. While WOL is a BIOS level behavior that shouldn’t be affected by software or hardware shutdown, we cannot rule out the possibility that something has changed and a bug has occurred.

We appreciate the granularity of your testing, however in order for our QA and development team to make better sense of your setup, more details are needed. Please send an email to info@epiphan.com regarding this forum post. Please provide the permanent logs for your Pearl unit, as well as date/time of performed WOL attempts.
Please also provide the firmware version of your unit as well as any networking complexities in between (different subnets, VPN, etc.)

To download permanent logs, navigate to the maintenance page, click on “download permanent logs” near the top of the page.

If permanent logs were not enabled, please enable them and run the WOL tests in order to see what is registered in the permanent logs for Pearl.

3

Dear Mathieu Renaud,

First of all, thank you very much for the quick feedback regarding the former problem described here.

We now do have Pearl systems in several lecture halls here on our university campus mostly for recording lectures. But these devices are currently often unused in their locations and of course do not run 24x7h.

First of all: … it’s annoying that even after such a long time of Pearl software development it is still not possible for such devices to shut down themselves (time-controlled), e.g. at the „end of the week“, but have to be switched off remotely by hand (using the WebGUI) …

It is even more annoying that we neither can start these devices time-controlled nor can they be woken up via WOL, at least not with conventional software used in other environments.

In our teaching and training laboratory we let students experiment with WOL here, too. But none of these tools used here (e.g. [2]) do work with the Pearls - but with lots of other devices or PCs.

To verify the structure of a Magic Packet [1] we use a LAN analyzer software and it shows always the correct structure [1] of these magic packets sent to the Pearls from these WOL clients (e.g. [2]).
None of these Tools worked even in a 1:1 cable scenario.

[1] https://www.amd.com/system/files/TechDocs/20213.pdf

[2] https://oette.wordpress.com/wol2/ → +100,000 downloads

Please also provide the firmware version of your unit as well as any networking complexities in between (different subnets, VPN, etc.)

A „1: 1 LAN cable connection“ is not a structure that needs to be explained?

Thats what I described before and therefore I wonder whether it was not read. I already feared that and therefore chose the simplest structure for our testing, so that for this case it cannot be „attributed to the customer’s network" …

Please provide the permanent logs for your Pearl unit

I will do so … o.k.

Of course we do have the latest firmware installed on all of our Pearls, i.e. version 4.13.0j, but the problem is much older (see other forum entries from other customers).

BUT I think it would be much easier and more customer-friendly if EPIPHAN would simply provide any „executable tool“ or if necessary (using Linux) a (phyton) script … that definitely works in simple „1: 1 environment“ (using a simple LAN cable) ?

If this tool then doesn’t work in a more complex network for any customer - that’s some kind of “his own problem” …

Best regards,

4

Features, performance improvements and bug fixes are added in almost every firmware release. Our development teams develop features based on the feedback received from various teams within the company and from officially requested features from our customer base. I can certainly add your desired feature as a request to the list.
However it is also important to note that features are added based on the level of resources and priority available. Sometimes, features are pushed back as a result of more immediate bug fixes or substantial firmware feature necessities. I apologize that our hardware device does not meet every single desired feature or function that you require, however we cannot always meet every single desired feature requested based on the level of resources and time available.

Regarding your comment:

A „1: 1 LAN cable connection“ is not a structure that needs to be explained?
Thats what I described before and therefore I wonder whether it was not read. I already feared that and therefore chose the simplest structure for our testing, so that for this case it cannot be „attributed to the customer’s network" …

I apologize for my lack of clarity. This was a query made by the QA manager, not about the direct 1:1 connection of LAN to Pearl, but about about you precise desired configuration in a more complex network environment. You mentioned the need of “walking across campus” to access these devices.

The Pearl family of products can also simply be left running 24/7 if desired. As an example, other than performing a firmware update upon new releases, all of our company Pearl units including all Pearl units for our demo studios and test labs have been left powered on since their installations in 2017 (Pearl-2) and 2019(Pearl Mini). We also have many customers that leave their Pearl units running in the same manner.

In order to reduce the need to walk across a camps to access a unit, Epiphan Cloud is a service which also allows you to manage a fleet of Pearl units remotely from a single point, remotely access each Web UI, monitor device health, see error reporting in real time, among other features. You can learn more about Epiphan Cloud here

We look forward to your support ticket submission so that our QA and development team can continue to assist in investigating the issue.

5

Hello Mathieu Renaud,

Thank you very much for your patience, but I think MANY CUSTOMER will have this problem,
even if there is not much to read about it in the EPIPHAN forum … but overall it is also very “quiet” here.

Now I was just checking the situation once again, this time using „well known wake-on-lan client“ … no change.
This WOL test is now done with/from a Synology NAS and should work. However this can also
be checked in the same way by EPIPHAN and would be a very valuable solution for MANY customers !!!

SCENARIO:

1 Like
6

Hi there,

i just did some reearch in my lab here.

When shutting down the Pearl2 (no matter if via Webiface or Powerbutton), the Ethernetlink goes down and comes back up on 10Mbit/FDX. I send a Magic Packet to the Device MAC, and the Link disappears. No boot. Booting manually works normally.

For debug, i used a Mikrotik Switch (CRS112), which can send WOL and log as well.
I tried 2 other tools in Windows and another switch with the same result.

So the Pearl is actually receiving the Magic Packet, but the only reaction is to shut down the Ethernet port. There is definately sth wrong and a fix needed.

hth!

Andy

7

Thanks to your feedback and testing, the QA and development team were able to reproduce the problem and it seems to allow the devices to respond to WOL commands only under specific powered-off conditions. As WOL is a function at the BIOS level, this change would have corresponded after Pearl family devices received a BIOS update on July 26 2018 with Firmware 4.5.1e. With this update, the unofficial WOL feature behavior changed. We understand the challenges this has posed for you and other Pearl family users intending to use this workflow, however as this was never an intended or supported feature on the Pearl family, no further development or changes will be coming at this time.

While we understand it is not ideal, we can provide alternative recommendations. Pearl devices are designed to resume their last known current state if power is removed. This means that if Pearl was simply on “standby,” this is the behavior it will exhibit when power is returned. If Pearl was actively streaming at the time, upon the return of power it will resume streaming to its last known destination. One option could be using programmable power bars. The power bars can eliminate power to the connected devices. Once issuing a command to send power to the power bar, all devices will power back up to their last known states.

Pearl family of products were also designed with industrious use in mind. These devices can be left powered on and in use 24 hours a day, 365 days a year.

8

I have solved my issue by allowing power usage in sleep mode.