Skip to content

Fix room server login response#2

Open
jwasher wants to merge 1 commit intobrianwiddas:mainfrom
jwasher:main
Open

Fix room server login response#2
jwasher wants to merge 1 commit intobrianwiddas:mainfrom
jwasher:main

Conversation

@jwasher
Copy link
Copy Markdown

@jwasher jwasher commented Mar 31, 2026

Two fixes to the ANON_REQ login response handler:

  1. Echo the ANON_REQ timestamp back in the response so the companion firmware can match it to pending_req tag, enabling proper login handling for both flood and direct logins.

  2. Set correct ACL permissions (PERM_ACL_READ_WRITE=2 for guest, PERM_ACL_ADMIN=3 for admin) instead of hardcoded 0, allowing clients to post messages to the room.

Also add a 5 second startup delay before the first flood advert to allow the companion radio interface time to connect, preventing the advert from being lost with 'Cannot send, companion radio not connected'.

Two fixes to the ANON_REQ login response handler:

1. Echo the ANON_REQ timestamp back in the response so the companion
   firmware can match it to pending_req tag, enabling proper login
   handling for both flood and direct logins.

2. Set correct ACL permissions (PERM_ACL_READ_WRITE=2 for guest,
   PERM_ACL_ADMIN=3 for admin) instead of hardcoded 0, allowing
   clients to post messages to the room.

Also add a 5 second startup delay before the first flood advert to
allow the companion radio interface time to connect, preventing the
advert from being lost with 'Cannot send, companion radio not connected'.
@jwasher
Copy link
Copy Markdown
Author

jwasher commented Mar 31, 2026

Brian, Here's a few patches for your consideration. I must admit, I had help from Claude since it's faster than I am at reading room server logs.

@jwasher jwasher closed this Mar 31, 2026
@jwasher jwasher reopened this Mar 31, 2026
@brianwiddas
Copy link
Copy Markdown
Owner

Hi,

I've added the advert delay (commit 79ae764)

I see what you're getting at with the ACL permissions, but I think it's the wrong place for it. I wasn't aware that 0 would prevent clients posting; I presume this is something which has been added since I wrote that code. However, there are more than 2 permissions needed, as the room server also has read-only clients, so we need some people to receive PERM_ACL_READ_ONLY PERM_ACL_GUEST (according to the room server code). And PERM_ACL_READ_* is probably not appropriate for a repeater login.

I'm looking at this now and will add appropriate code to the login options.

The code you supplied eliminates the PATH response to flood requests, which doesn't follow the behaviour of the MeshCore firmware, and means that the client won't switch from flood to direct.

As far as I can see from the MeshCore firmware, echoing the timestamp back to the requesting device is not the correct behaviour for an ANON_REQ. The room server records the sender timestamp, but although the response is prefixed with a timestamp, this is a new, unique timestamp generated on the room server, not the senders' timestamp. Echoing the requester's timestamp is correct for REQ types.

From examples/simple_room_server/MyMesh.cpp (MyMesh::onAnonDataRecv function)

    uint32_t now = getRTCClock()->getCurrentTimeUnique();
    memcpy(reply_data, &now, 4); // response packets always prefixed with timestamp

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants