Skip to content

feat: Allow repeater firmware to bridge over USB and IP#3020

Open
hickey wants to merge 6 commits into
meshcore-dev:mainfrom
hickey:bridge-over-usb-and-ip
Open

feat: Allow repeater firmware to bridge over USB and IP#3020
hickey wants to merge 6 commits into
meshcore-dev:mainfrom
hickey:bridge-over-usb-and-ip

Conversation

@hickey

@hickey hickey commented Jul 21, 2026

Copy link
Copy Markdown

This PR adds support for bridging packets over USB serial and TCP connections in the same manner as the RS232 bridging works. It uses the same encoding as the RS232 bridge code.

USB serial bridge code is enabled with defining WITH_USB_SERIAL_BRIDGE and setting the serial stream by defining USB_SERIAL_STREAM (usually to Serial). Defining the stream in theory should allow the bridging output to be directed to a second USB port if the platform has another USB connection; although I do not have a solid way to test this configuration with the hardware available to me.

TCP bridge code is enable by defining WITH_TCP_BRIDGE. The port that the repeater will listen on is defined by TCP_BRIDGE_PORTand will default to 4403 if not specified. As a result when using the TCP bridge code the WIFI credential definitions need to be specified also in the build.

I have added build environments for the lilygo_tbeam_SX1262 named Tbeam_SX1262_repeater_bridge_usbserial and Tbeam_SX1262_repeater_bridge_wifi to demonstrate how the firmwares can be built. These environments should be able to be transported to other platforms that have compatible hardware.

In addition, I have added the usbserial and tcp bridge types to the get bridge.type CLI command. I am not certain if this will have any effects on the remote management in the companion app. There is nothing I see that is obvious. I have also updated the CLI documentation to note the values that can be returned by get bridge.type.

Also included is a fix for a bug with the set bridge.source CLI command. The original code would accept a parameter of rx which contradicts the CLI documentation. Any other parameter would be discarded. The fix proposed will only accept logRx and logTx parameters (also the full lowercase versions of these parameters) and produce an error message should another parameter value be specified. This change supersedes #3014 that I created earlier and I will be closing that PR shortly.

hickey added 6 commits July 21, 2026 16:03
Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
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.

1 participant