This proxy application is designed to facilitate file transfers over KISS TNC connections while also allowing for pass‑through access via separate TCP ports. In non‑loop mode the proxy connects to TNC1 and TNC2 (using TCP or serial) for file‑transfer processing and additionally listens for pass‑through connections on dedicated TCP ports. In loop mode the application simply listens on the specified ports and echoes data.
The proxy is intended for environments where file transfers need to be bridged between two different TNCs, such as cross band or cross modulation. It supports two main modes:
--loop, the application will listen on the configured pass‑through ports (default 5010 and 5011) and act as a loopback.
To build the application, ensure you have Go installed. Then compile the program:
go build -o bridge bridge.go
The following table lists all available command‑line options along with their descriptions and default values:
| Flag | Description | Default Value |
|---|---|---|
--tnc1-connection-type |
Connection type for TNC1 (tcp or serial). |
tcp |
--tnc1-host |
TCP host for TNC1. | 127.0.0.1 |
--tnc1-port |
TCP port for TNC1 file‑transfer connection. | 9001 |
--tnc1-serial-port |
Serial port for TNC1 (if using serial connection, e.g. /dev/ttyUSB0 or COM3). |
empty |
--tnc1-baud |
Baud rate for TNC1 serial connection. | 115200 |
--tnc2-connection-type |
Connection type for TNC2 (tcp or serial). |
tcp |
--tnc2-host |
TCP host for TNC2. | 127.0.0.1 |
--tnc2-port |
TCP port for TNC2 file‑transfer connection. | 9002 |
--tnc2-serial-port |
Serial port for TNC2. | empty |
--tnc2-baud |
Baud rate for TNC2 serial connection. | 115200 |
--tnc1-passthrough-port |
TCP port for TNC1 pass‑through clients. Used for both loop mode and non‑loop pass‑through. | 5010 |
--tnc2-passthrough-port |
TCP port for TNC2 pass‑through clients. Used for both loop mode and non‑loop pass‑through. | 5011 |
--callsigns |
Optional comma‑delimited list of valid sender/receiver callsigns. Supports wildcards and a comma‑delimited list.
Example: "MM3NDH-14,MM5NDH-*,*-15". When empty, all callsigns are allowed.
|
empty |
--debug |
Enable debug logging. | false |
--save-files |
Save all files seen by the proxy (prepending <SENDER>_<RECEIVER>_ to the filename).
|
false |
--loop |
Enable loopback mode. In loop mode the application uses the pass‑through ports for TNC1 and TNC2 and does not use the TNC1/TNC2 file‑transfer options. | false |
--tcp-read-deadline |
TCP read deadline in seconds for TNC connections (application‑level timeout). If no complete KISS frame is received from a TCP‑based TNC within this period, the connection is closed and a reconnect is triggered. | 600 |
The following command will run the proxy in non‑loop mode using TCP connections for both TNCs on the default ports.
The pass‑through listeners will be available on ports 5010 and 5011.
go run proxy.go
This command configures TNC1 and TNC2 for file‑transfer on the default host/port options and overrides the pass‑through ports.
go run proxy.go --tnc1-passthrough-port=6000 --tnc2-passthrough-port=6001
In this example, TNC1 uses a serial connection (e.g. /dev/ttyUSB0) and TNC2 uses a TCP connection.
Pass‑through clients will still connect on the default ports.
go run proxy.go --tnc1-connection-type=serial --tnc1-serial-port=/dev/ttyUSB0 --tnc1-baud=115200 --tnc2-connection-type=tcp --tnc2-host=127.0.0.1 --tnc2-port=9002
Loopback mode is activated with the --loop flag.
In this mode, TNC1 and TNC2 are not used for file‑transfer; instead, the application listens on the pass‑through ports.
Here you can also override the ports if desired.
go run proxy.go --loop --tnc1-passthrough-port=7000 --tnc2-passthrough-port=7001
The following command restricts file transfers to the callsigns N0CALL and any SSID matching *-R
and turns on debug logging.
go run proxy.go --callsigns=N0CALL,*-R --debug
/dev/ttyUSB0 on Unix or COM3 on Windows)
is specified correctly.
--loop mode is mutually exclusive with the TNC1/TNC2 file‑transfer options. When in loop mode,
the pass‑through ports are used to accept client connections directly.
--tcp-read-deadline option specifies an application‑level timeout for TCP‑based TNC connections.
If no complete KISS frame is received within the specified number of seconds, the connection is closed to trigger a reconnect.
For further questions or to report issues, please contact the project maintainer or consult the source repository.