[ST Edge] Wake on LAN Broadcast Msg Crashes Driver

Developer Programs Writing Edge Drivers
1

102-byte Wake-on-LAN message needs to be sent to 255.255.255.255 on port 0, 7, or 9. However when I attempt this from an Edge driver, it is causing the driver to spontaneously restart. Is this a bug and/or is the platform prohibiting me from sending to that address?

Code

local BROADCAST_ADDR = '255.255.255.255'
local BROADCAST_PORT = 0
local sock = assert(socket.udp(), "WOL socket")
assert(sock:setsockname("0.0.0.0",0))        -- also tried omiting this line
log.info ("Sending WOL magic packet for MAC address", macaddr)
assert(sock:sendto(magic_packet, BROADCAST_ADDR, BROADCAST_PORT))      -- crashes here

Log Output

2021-12-09T18:01:18.403355854+00:00 DEBUG LAN Device Monitor  Wake on LAN requested; comand=	push
2021-12-09T18:01:18.411860926+00:00 INFO LAN Device Monitor  Sending WOL magic packet for MAC address	E8-E0-B7-79-F9-65
2021-12-09T18:01:24.107964079+00:00 TRACE LAN Device Monitor  Setup driver landevmonDriver with lifecycle handlers:
DeviceLifecycleDispatcher: landevmonDriver
  default_handlers:
    infoChanged:
    driverSwitched:
    removed:
    init:
    added:
    deleted:
    doConfigure:
  child_dispatchers:

2021-12-09T18:01:24.112827245+00:00 TRACE LAN Device Monitor  Setup driver landevmonDriver with Capability handlers:
CapabilityCommandDispatcher: landevmonDriver
  default_handlers:
    partyvoice23922.wakeonlan:
      push
    partyvoice23922.moncontrol:
      setSwitch
    partyvoice23922.createanother:
      push
  child_dispatchers:

2021-12-09T18:01:24.116235620+00:00 INFO LAN Device Monitor  LAN Device Monitor Driver v1.1 started
2021-12-09T18:01:24.231019412+00:00 TRACE LAN Device Monitor  Received event with handler environment_info
2021-12-09T18:01:24.245978829+00:00 TRACE LAN Device Monitor  Found DeviceLifecycleDispatcher handler in landevmonDriver
2

Hey, @TAustin

Interesting finding!

At first glance, I noticed that you’re not configuring the socket to actually broadcast. That may be triggering the issue. Try including the following:


assert(udp:setoption('broadcast', true))

Anyway, I’ll implement it right away to document it and share it with the engineering team.

1 Like
3

Thanks for your reply, Erick!

I hadn’t realized the broadcast option was supported, so that’s awesome, thanks.

I got this to work by using port 7, but trying to use port 0 is what seems to be causing the driver to crash (even with the broadcast option). Maybe you can replicate, and let the team know.

Thanks.

4

Port 0 isn’t a valid port, however it shouldn’t crash the driver, it should probably log an error.

https://www.grc.com/port_0.htm

5

Well, it’s complicated :slight_smile: It’s a ‘reserved port’ according to other sources. And it’s typically used for sending UDP broadcasts for wake-on-LAN messages. I’m sure it depends on the underlying sw layers how it’s treated (I can use it just fine with Lua sockets on other platforms).

But agreed that even if it’s not valid on the SmartThings hub, it needs to be handled more elegantly!

6

Agree and @RBoy thanks a lot for the insight!

After doing some implementation testing, I found that ports 7 and 9 allowed the driver to broadcast as expected and finally I was to track the packets through Wireshark.

In addition to our findings, I noticed that request is handled differently depending on the port I use, e.g.:

7

@erickv
Not surprised to see the different handling; port 7 is indeed also used for echo protocols.

For WOL purposes, the port is only important for router handling, since at the end device, the message is handled at the hardware interface and never even passed to the transport layer. I haven’t confirmed it’s all working yet from my driver, but fingers crossed.

Thanks very much for looking at this!

2 Likes
8

I don’t have anything technical to add, other than to say that I used to leverage Webcore to send wake on lan packets, but I moved that functionality over to Home Assistant while clearing out my Webcore of most pistons. It will be nice to have this functionality available in SmartThings going forward after Groovy shuts down!

1 Like
9

I have a working driver available to test if you are interested! I’ve been able to prove the WOL feature is working based on success with a laptop here, but would like some others to also try it.

10

@TAustin I’d like to try it it on one of my TV’s since they are all hardwired.

11

Works on a PC :grin::+1:

1 Like
12

Great! Sent you a DM.

13

Thanks, I am already enrolled in your other channel and using the LAN Device Monitor driver from there on a PC, Audio, and lighting setup I’m messing around

14

OK, this will replace your current driver and next time you create a new device, you should see the new WOL button and Settings options.