# Network

Configure Oden network behavior and diagnose connection quality.

Last validated: 2026-05-05

Oden network links carry realtime video, audio, feedback, and com-channel traffic between Streamer and Player. For most projects, configure one Streamer `Initiator` link and one Player `Responder` link.

For bitrate, FEC, and bandwidth regulation, see [Bitrate control and Auto Video Packing](stream-settings.md).

## Configure a direct Streamer-to-Player link

Use this when the Streamer can reach the Player IP address and UDP receive port.

1.  On the Player, select the `Remote Streamer` entity.
    
2.  Open `Network`.
    
3.  Select `Add Link` if the entity has no link.
    
4.  Set `Mode` to `Responder`.
    
5.  Set `Receive Port` to the UDP port the Streamer will send to, for example `47000`.
    
6.  Leave `Bind IP` empty or set it to `0.0.0.0` unless the Player must listen on one specific address.
    
7.  On Linux, set `Bind Device` only when traffic must use one network interface regardless of system routes.
    
8.  On the Streamer, open `Network`.
    
9.  Set the Streamer link `Mode` to `Initiator`.
    
10.  Set `Destination Addr.` to the Player address or DNS name.
     
11.  Set `Destination Port` to the Player `Receive Port`.
     
12.  Start `Output` and verify video on the Player.
     

The default Streamer link is an initiator, and the default destination is `127.0.0.1:47000`. Change it before testing across machines.

Core link settings:

Mode

`Initiator` sends to a destination address and port. `Responder` listens on a receive port and replies through the same link state.

Receive Port

UDP port used by a responder.

Destination Addr. / Destination Port

Address and UDP port used by an initiator.

Bind IP

Local address to bind. Leave empty or use `0.0.0.0`/`::` unless a specific local address is required.

Bind Device

Linux interface name used when the link must leave through a specific network device.

Name

Human-readable label shown in stats and commissioning notes.

Bonding Group

Groups links that carry the same realtime stream.

## Add modem or interface links

Use multiple links when a vehicle has more than one modem, network adapter, or route to the Player.

1.  Add one link per path on both sides.
    
2.  Keep each Streamer `Destination Addr.` and `Destination Port` matched to the corresponding Player responder.
    
3.  Give each link a `Name` that identifies the modem or adapter.
    
4.  On Linux, set `Bind Device` for links that must leave through a specific interface.
    
5.  Put links that carry the same stream in the same `Bonding Group`.
    
6.  In `LLTP Bonding`, leave `Dynamic Bonding` enabled only when Oden should choose link usage from feedback.
    
7.  Set `FEC Redundant Links` to `0` or `1` unless a measured network test shows that more redundancy is needed.
    

Use `Link Stats` to confirm that traffic is flowing on the expected links. If one link shows errors or no traffic, first check route, firewall, bind device, and destination port. Link stats include per-link bandwidth, packet loss, bytes in flight, round-trip time, and channel usage. Use the graph colors and link names to confirm that each physical modem or interface is active during the test, not merely configured.

## Use P2P or encryption

Use `P2P` when the link may be able to switch to a direct peer-to-peer path after initial connectivity. The default `STUN Server` is `stun.l.google.com:19302`. Add `Excluded Subnets` in CIDR notation, for example `100.100.0.0/24`, when a subnet must not be used for P2P.

Use `Encryption` when the link must authenticate peers and encrypt traffic.

1.  Generate or select a `Key Pair Path` on each side.
    
2.  Copy the other side’s `Public Key` into `Allowed Public Keys`.
    
3.  If traffic is relayed through a WireGuard server, set `Internal src.` and `Internal dst.` to the corresponding tunnel addresses.
    
4.  Keep initiator links to one allowed public key unless support has given a project-specific reason to do otherwise.
    

## Relay traffic through a WireGuard server

Use this pattern when Streamer and Player cannot reach each other directly and must relay encrypted Oden traffic through a standalone WireGuard server. In this setup, both Streamer and Player links use `Initiator` mode because both sides send to the relay server rather than directly to each other.

Example assumptions:

-   WireGuard server: `gateway.example.com`
    
-   Streamer has two modem interfaces: `192.168.8.10` and `192.168.10.10`
    
-   Internal tunnel addresses: `10.200.0.10` and `10.200.0.20` for Streamer links, `10.200.0.30` and `10.200.0.40` for Player links
    

| Setting | Link 0 | Link 1 |
| --- | --- | --- |
| Mode | `Initiator` | `Initiator` |
| Bind Addr. | `192.168.8.10` | `192.168.10.10` |
| Destination Addr. | `gateway.example.com` | `gateway.example.com` |
| Encryption > Allowed Public Keys | WireGuard server public key | WireGuard server public key |
| Encryption > Advanced > Internal src. | `10.200.0.10` | `10.200.0.20` |
| Encryption > Advanced > Internal dst. | `10.200.0.30` | `10.200.0.40` |

| Setting | Link 0 | Link 1 |
| --- | --- | --- |
| Mode | `Initiator` | `Initiator` |
| Bind Addr. | `0.0.0.0` | `0.0.0.0` |
| Destination Addr. | `gateway.example.com` | `gateway.example.com` |
| Encryption > Allowed Public Keys | WireGuard server public key | WireGuard server public key |
| Encryption > Advanced > Internal src. | `10.200.0.30` | `10.200.0.40` |
| Encryption > Advanced > Internal dst. | `10.200.0.10` | `10.200.0.20` |

Generate a key pair for every Oden link and copy each public key to the WireGuard server.

```ini
[Interface]
Address = 10.200.0.1/24
PrivateKey = WIREGUARD_SERVER_PRIVATE_KEY
ListenPort = 51820

[Peer]
PublicKey = WIREGUARD_STREAMER_LINK_0_PUBLIC_KEY
AllowedIPs = 10.200.0.10/32

[Peer]
PublicKey = WIREGUARD_STREAMER_LINK_1_PUBLIC_KEY
AllowedIPs = 10.200.0.20/32

[Peer]
PublicKey = WIREGUARD_PLAYER_LINK_0_PUBLIC_KEY
AllowedIPs = 10.200.0.30/32

[Peer]
PublicKey = WIREGUARD_PLAYER_LINK_1_PUBLIC_KEY
AllowedIPs = 10.200.0.40/32
```

Make sure Linux routing sends each Streamer modem interface through the intended modem gateway. For example, traffic bound to `192.168.8.10` should leave through the modem on that interface.

## Validate network changes

1.  Start Streamer `Output`.
    
2.  On the Player, open the `Remote Streamer` entity.
    
3.  In `Network`, open `Stats` and enable `Enable Link Stats`.
    
4.  Confirm that `Rx` and `Tx` traffic update on the intended link.
    
5.  In `Output`, open `Bandwidth Control` and check `Bandwidth`, `Round Trip Time`, `Packet Loss`, and `Wanted Bitrate`.
    
6.  Save both projects when link settings are stable.
    

If video connects but audio or com-channel traffic does not, check the same link first. All realtime traffic uses the configured network manager links.

## Project-file names

Network links are stored under `net_settings.links`. The UI mode names `Initiator` and `Responder` serialize as `sender` and `receiver`.

```libconfig
net_settings : {
    links : ( {
        name : "primary";
        mode : "sender";
        bind_ip : "::";
        destination_ip : "192.0.2.20";
        destination_port : 47000;
        bonding_group : 0;
    } );
};
```

In Streamer projects, `net_settings` is under `stream_settings.typeData.realtime_nvenc_gstreamer`. In Player projects, it is under the `remote_streamer` entity.