FATAL crash in lustre WebSocket library when socket.select returns nil recv during connection loss

[alexzeitgeist]

I discovered this issue while developing a LAN driver using websockets; I assume it affects any Edge driver using lustre WebSockets where the connected device may reboot abruptly.

The lustre WebSocket library has a bug that causes a FATAL crash when the underlying socket connection is abruptly terminated (e.g., when a connected device reboots). The crash occurs in lustre's internal _receive_loop when it tries to access a nil recv value.

Steps to Reproduce

1. Create a SmartThings Edge driver that uses lustre WebSocket for device communication
2. Establish a WebSocket connection to a device using the standard pattern:

  local lustre = require("lustre")
  local ws = lustre.WebSocket.client(sock, path, config)
  ws:connect(host, port)

3. While the WebSocket is connected and receiving messages, abruptly reboot the device
4. The driver crashes with a FATAL error

Expected Behavior

The lustre library should handle connection losses gracefully, returning an error that the driver can catch and handle (e.g., trigger reconnection logic).

Actual Behavior

The driver crashes with the following FATAL error:

  FATAL Feller Wiser Gateway Driver  runtime error: [string "cosock.lua"]:250: [string "lustre/ws.lua"]:299: attempt to index a nil value (local 'recv')
  stack traceback:
      [string "lustre/ws.lua"]:299: in method '_handle_recvs'
      [string "lustre/ws.lua"]:286: in method '_receive_loop'
      [string "lustre/ws.lua"]:178: in function <[string "lustre/ws.lua"]:177>

Probable Root Cause

Looking at the lustre source code, the issue is in the _receive_loop function:

  local recv, _, err = socket.select(rs, nil, self.config._keep_alive)
  if not recv then
    if self:_handle_select_err(loop_state, err) then
      return
    end
  end
  if self:_handle_recvs(loop_state, recv, 1) then  -- Line 299: recv can be nil here!
    break
  end

The bug occurs when:

1. socket.select() returns recv = nil due to a socket error
2. _handle_select_err() is called but returns nil for non-timeout errors
3. Execution continues to _handle_recvs() which tries to access recv[1] when recv is nil

Proposed Fix

Add proper control flow to prevent calling _handle_recvs when recv is nil:

  if not recv then
    if self:_handle_select_err(loop_state, err) then
      return
    end
  else  -- Only call _handle_recvs if recv is not nil
    if self:_handle_recvs(loop_state, recv, 1) then
      break
    end
  end

Environment

• SmartThings Edge Hub 0.56.11
• Built-in lustre library (not vendored)
• Occurs when devices reboot

[alexzeitgeist]

I did some more debugging. The crash in my driver occurs due to a race condition between Lustre's internal keep-alive mechanism and the driver's reconnection logic.

When config:keep_alive() is enabled, Lustre spawns its own internal _receive_loop coroutine that:

1. Sends periodic PING frames
2. Reads from the same socket as the main receive loop
3. Creates a situation where two coroutines are calling ws:receive() on the same WebSocket

When the connection drops (e.g., lan device reboot), both loops detect the failure simultaneously, leading to the crash when recv is nil.

The issue can be completely avoided by disabling Lustre's built-in keep-alive and implementing manual keep-alive at the application level:

  -- Don't use this - it causes the race condition:
  -- config:keep_alive(30)

  -- Instead, implement manual keep-alive:
  local function manual_keepalive(ws)
    while ws and not ws.closed do
      -- Send PING through Lustre's internal channel
      local Frame = require("lustre.frame")
      local ping = Frame.ping("")
      if ws.is_client then
        ping:set_mask()
      end

      local tx, rx = cosock.channel.new()
      ws._send_tx:send({ frame = ping, reply = tx })

      socket.sleep(30)
    end
  end

Why This Works

• Only one coroutine reads from the socket (no race condition)
• Connection failures are detected cleanly by the single receive loop
• The driver can implement proper reconnection logic without conflicts

I believe this issue affects any Edge driver using Lustre WebSockets with built-in keep-alive enabled, particularly when connecting to devices that may disconnect abruptly.