TCP Local Server on Gateway Mode

[brybalicious]

Hi,

Amazing the work on making the firmware user-friendly! Love the new flasher.

I'm having an issue propagating announces on the local side. It seems it's by design. Nodes on WiFi connected to the TCP Local Server cannot hear announces from nodes on the LoRa Interface, nor vice versa, since there is some restriction to interfaces in AP Mode propagating announces to one another.

https://reticulum.miraheze.org/wiki/Interface#Modes

"Any announces into an access_point will propagate to all other interfaces except other access_points."

It would be great if there were an easy setting to change the interface modes in either the flasher or a configuration tool. Boundary Mode makes sense in general for the WAN side, but adding a mode select field for each interface would be way better for debug and configurability, especially for a Transport Node which can act as a local gateway to the reticulum backbone.

Thanks

[jrl290]

I'll check it out. The "LAN" interfaces shouldn't be in access_point mode. The routing is customized to act like a firewall. The "LAN" side has free reign (or should have free reign). The "WAN" side gets stopped unless it refers to a "LAN" address or unless a "LAN" device references it. That's really the only way to get the traffic down to a reasonable level for the ESP32

Thank you for bringing it to my attention

[brybalicious]

Yes. Confirmed with some other community members. AP cannot pass announces to AP, so one of either the TCP Local Server interface or LoRa interface need their mode to be changed. An alternative solution provided was to place a full node in between two nodes with AP interfaces... but that seems redundant and expensive.

[brybalicious]

https://github.com/jrl290/RTNode-HeltecV4#optional-local-tcp-server--mode_access_point

The docs for this repo show that the two local interfaces are indeed in AP mode, baked into the firmware. Apparently in microReticulum, this cannot be configured after flashing, and needs to have a different mode baked in to the firmware.

[jrl290]

The LoRa interface is now MODE_FULL and the Local TCP is now MODE_GATEWAY. Check the firmware to see that routing across Local interfaces is now opened up

[brybalicious]

Since updating, I can no longer access the GUI portal at the static IP, once the RTNode has successfully connected to the LAN.
LoRa, WiFi, WAN and LAN are all lit up. When long pressing PRG, I can access the portal via the STA WiFi connection. In AP mode, however, the local TCP server and the GUI portal seem inaccessible at a custom port number and address. This was not an issue with the previous firmware version.

Note, the defaults for the Local TCP Server port and the WAN port are the same. Perhaps this should be changed to e.g. port 4241 for the Local TCP Server to avoid conflicts.

[jrl290]

Hi brybalicious, I'm not sure what you experienced before. But the configuration portal was always programmed to only be accessible while the node was not running. Resources on the ESP32 are incredibly tight. It would not be good to run a webpage while running the node itself

Reticulum TCP servers are 4242 by convention. In the same way that you can run an html server on port 80 and still access a webpage on someone else's html server (also running on port 80), that's how the TCP Server and TCP Client act on RTNode. The RTNode can connect to the wider network and your local device can connect to the RTNode for access to the wider network

[brybalicious]

Okay. I need to just keep testing to see if I can get announces through the RTNode or just any confirmation that it's working at all. I guess I'm seeing obstructions where there may not be any, since I simply can't seem to achieve discoverability locally. Perhaps it's something to do with Sideband and Meshchat settings rather than settings on the RTNode.

[brybalicious]

Note, when I access http://XXX.XXX.XXX.XXX:4241 locally, I do receive an output:

[brybalicious]

Hi brybalicious, I'm not sure what you experienced before. But the configuration portal was always programmed to only be accessible while the node was not running. Resources on the ESP32 are incredibly tight. It would not be good to run a webpage while running the node itself

Reticulum TCP servers are 4242 by convention. In the same way that you can run an html server on port 80 and still access a webpage on someone else's html server (also running on port 80), that's how the TCP Server and TCP Client act on RTNode. The RTNode can connect to the wider network and your local device can connect to the RTNode for access to the wider network

I'm fairly sure that with the previous firmware, I was able to access the portal when I set the port numbers to be different. Even when not in 'configuration mode'. I'm not too excited to roll back and test it though XD

[brybalicious]

What am I missing here? PC MeshchatX client says the TCP Local Server is UP. RTNode itself shows the server is UP. Phone MeshchatX client shows the server is UP. Have turned off bluetooth (LoRa) and AutoInterface and made sure the devices are only able to connect via the TCPClientInterfaces. Both clients are showing TX and RX to the TCP Local Server. Under Interfaces, on both clients, the TCPClientInterfaces are showing 'Discoverable' flags. RNStatus shows outgoing announces on both clients, but no incoming announces (0/s)

[brybalicious]

Side-note... any possibility to connect to the RTNode via Bluetooth?

[jrl290]

That's something I can check out for you. The original concern was that announces were not propagating across the local interfaces. I'm not in a place to diagnose right now. But I'll take a look tonight As for Bluetooth, the purpose of RTNode is as a Lora repeater and bridge from Lora to the Internet. It is not meant to be mobile and therefore does not employ mobile interfaces The ESP32 is a highly constrained device. < 500kb of ram. It's hard enough getting it to function while being thrown thousands of announces from the Internet I'll get back to you

…

On Tue, May 5, 2026, 11:46 AM brybalicious ***@***.***> wrote: *brybalicious* left a comment (jrl290/RTNode-HeltecV4#18) <#18 (comment)> What am I missing here? PC MeshchatX client says the TCP Local Server is UP. RTNode itself shows the server is UP. Phone MeshchatX client shows the server is UP. Have turned off bluetooth (LoRa) and AutoInterface and made sure the devices are only able to connect via the TCPClientInterfaces. Both clients are showing TX and RX to the TCP Local Server. RNStatus shows outgoing announces on both clients, but no incoming announces (0/s) — Reply to this email directly, view it on GitHub <#18 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN2EVZDX3MF2GQCK5K34CT4ZIEFTAVCNFSM6AAAAACYHTFGB6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGOBQHA2DCMZSGY> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: ***@***.***>

[brybalicious]

Cheers! Yes, let's see if we can't just get devices on the same LAN to talk via the transport node. I was asking about bluetooth simply as an easy way to test the LoRa side by connecting directly to the RTNode. However, I guess I could test it by introducing a second companion node for the phone.

Anyhow, first things first. Propagating announces across the RTNode locally.

[brybalicious]

That's something I can check out for you. The original concern was that
announces were not propagating across the local interfaces. I'm not in a
place to diagnose right now. But I'll take a look tonight

As for Bluetooth, the purpose of RTNode is as a Lora repeater and bridge
from Lora to the Internet. It is not meant to be mobile and therefore does
not employ mobile interfaces

The ESP32 is a highly constrained device. < 500kb of ram. It's hard enough
getting it to function while being thrown thousands of announces from the
Internet

I'll get back to you
…

BTW ESP32S3 has 8MB+ of PSRAM (external RAM). The Seeedstudio Xiao ESP32S3 boards for example. Heltec v4 has 2MB PSRAM https://heltec.org/project/wifi-lora-32-v4/

[jrl290]

Not all of them. The v3 has no PSRAM