Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Ports & firewall

Everything at a glance

PortProtocolUsed byDirection
8080 (default, --port)TCP — HTTP(S)proxy web server + WebRTC signalinginbound to the proxy
1024UDP — OpenHPSDR Protocol 1radio ↔ proxy / desktop GUI / emulator (discovery + data)LAN
1024–1029UDP — OpenHPSDR Protocol 2radio ↔ proxy / desktop GUILAN
ephemeral high UDPWebRTC mediaproxy ↔ browsers/AndroidLAN (or via TURN)
443TCP — wssproxy → cloud broker uplink; clients → brokeroutbound only
4532 (default)TCP — Hamlib NET rigctldesktop GUI / Android → WSJT-X, loggersinbound to the client, off by default
50001 (default)UDP — Icom network controlproxy → network Icom radiosLAN

Practical rules

LAN web operation (proxy on a Pi, browsers in the house): allow inbound TCP to the proxy’s port (8080) and UDP on high ports to the proxy host. WebRTC on the LAN path uses no STUN server at all, so no internet access is needed.

Cloud operation: the proxy makes only outbound connections — wss to the broker (443) and UDP to the broker’s STUN/TURN servers. No inbound rules, no port forwarding. That’s the point of the design.

Radio side: the proxy (or desktop GUI) must be able to exchange UDP with the radio on port 1024 (Protocol 1) / 1024–1029 (Protocol 2), including the initial broadcast discovery. Radios on other subnets won’t answer broadcasts — add them as manual hosts and make sure unicast UDP routes both ways.

Emulator: binds UDP 1024, which is a privileged port on some Linux systems — grant it once with sudo setcap 'cap_net_bind_service=+ep' ./podsdr-emu.