server-udp-ports parser fails to parse documented port ranges and comma-separated lists

Description

When running Bedrock Dedicated Server with transport=nethernet, configuring the server-udp-ports property using the syntax explicitly documented in bedrock_server_how_to.html fails to register the port mappings.

According to bedrock_server_how_to.html (under UDP port configuration for NetherNet), the following syntax options are valid:

• Range mapping: server-udp-ports=<IP>:<EXT_START>-<EXT_END>:<INT_START>-<INT_END>
• Comma-separated entries on a single line: entry1,entry2

In practice, the binary configuration parser fails when evaluating start-end ranges or commas. It expects only single ip:port:port tokens on individual lines. Because the range/comma string is not parsed into discrete mapping entries, the server discards the mapping table and gathers only its local host/private IP address in WebRTC ICE SDP candidates. This leaves NAT/firewalled deployments unable to publish external UDP port mappings to clients.

Steps to Reproduce

1. Extract a clean, unmodified Bedrock Dedicated Server package for Linux (1.26.52.3).

2. Open server.properties and configure:
   

   transport=nethernet                                                                                            
   server-port=19132                                                                                              
   server-udp-ports=203.0.113.10:19132-19135:19132-19135    

   
   (or using comma-separated syntax on a single line: server-udp-ports=203.0.113.10:19132:19132,203.0.113.10:19133:19133)

3. Start the server executable:
   ./bedrock_server

4. Initiate a connection handshake over TCP 19132 (or query the signaling endpoint /v1/join) and inspect the
   gathered ICE candidates returned by the server.

Observed Result

The server ignores the range mapping and comma-separated list. In the SDP candidate gathering, the external IP (203.0.113.10) is never advertised for those UDP ports; the server advertises only its private/local interface IP.

Expected Result

The server should parse the start-end range or comma-separated list into individual internal-to-external port mappings as documented, correctly advertising the external IP and port range in ICE candidates.

Additional Notes

• Reproducibility: 100% reproducible (5 out of 5 attempts) on an unmodified Linux vanilla environment (bedrock_server 1.26.52.3, Build ID: 51798919).
• Workaround: Manually unrolling each port into its own distinct single-port line in server.properties works:
server-udp-ports=203.0.113.10:19132:19132
server-udp-ports=203.0.113.10:19133:19133
server-udp-ports=203.0.113.10:19134:19134
server-udp-ports=203.0.113.10:19135:19135

Relationship to Existing Issues:

This configuration parser failure appears to be the underlying root cause for several reported external/WAN connectivity failures where servers behind NAT/firewalls cannot be reached on NetherNet:

• BDS-23108 (NetherNet renders server inaccessible) and BDS-23118 (Cannot
  join external servers on NetherNet).

• BDS-23123 (Proxied/NAT dedicated servers timing out during connection
  negotiation).

• Explains the ICE connection timeout symptoms reported in BDS-23110
  (InitialConnection-45) and BDS-23125 (InitialConnection-13), as clients only receive
  internal/private IP candidates.