`UDP_MUX_PORT` only applying to first IP in answer

[caraar12345]

Hi there! Thanks for creating broadcast-box -- it's immediately solved an issue I've been stuck on for months and I am elated!

It seems I've found a bug though with how UDP_MUX_PORT applies.

With srflx set, the ANSWER includes the LAN IP, WAN IP (and a second WAN IP?). In that case, only the LAN IP answers with the UDP_MUX_PORT; the two WAN IPs include randomised UDP ports.

Without srflx set, the ANSWER includes the WAN IP twice -- where the first WAN IP is listening on the UDP_MUX_PORT set in .env.production.

(I'm using 111.222.3.444 as a placeholder for my home public IP)

.env.production

UDP_MUX_PORT=62123
#INCLUDE_PUBLIC_IP_IN_NAT_1_TO_1_IP=true
#DEBUG_PRINT_OFFER=true
DEBUG_PRINT_ANSWER=true

#NAT_1_TO_1_IP=1.2.3.4|192.168.1.192 < (unrelated? - this causes 'invalid 1:1 NAT mapping' errors)
INCLUDE_PUBLIC_IP_IN_NAT_1_TO_1_IP=yes
STUN_SERVERS=stun.l.google.com
NETWORK_TYPES=udp4

NAT_ICE_CANDIDATE_TYPE=srflx

ANSWER with NAT_ICE_CANDIDATE_TYPE=srflx set

a=candidate:1639014701 1 udp 2130706431 192.168.1.192 62123 typ host ufrag nEIlQnWTUjUzqpYl
a=candidate:1639014701 2 udp 2130706431 192.168.1.192 62123 typ host ufrag nEIlQnWTUjUzqpYl
a=candidate:2663148295 1 udp 1694498815 111.222.3.444 49280 typ srflx raddr 0.0.0.0 rport 49280 ufrag nEIlQnWTUjUzqpYl
a=candidate:2663148295 2 udp 1694498815 111.222.3.444 49280 typ srflx raddr 0.0.0.0 rport 49280 ufrag nEIlQnWTUjUzqpYl
a=candidate:2663148295 1 udp 1694498815 111.222.3.444 41610 typ srflx raddr 0.0.0.0 rport 41610 ufrag nEIlQnWTUjUzqpYl
a=candidate:2663148295 2 udp 1694498815 111.222.3.444 41610 typ srflx raddr 0.0.0.0 rport 41610 ufrag nEIlQnWTUjUzqpYl

ANSWER without NAT_ICE_CANDIDATE_TYPE=srflx set

a=candidate:2609212084 1 udp 2130706431 111.222.3.444 62123 typ host ufrag yNAmdGYQYdAYJCXZ
a=candidate:2609212084 2 udp 2130706431 111.222.3.444 62123 typ host ufrag yNAmdGYQYdAYJCXZ
a=candidate:2663148295 1 udp 1694498815 111.222.3.444 48992 typ srflx raddr 0.0.0.0 rport 48992 ufrag yNAmdGYQYdAYJCXZ
a=candidate:2663148295 2 udp 1694498815 111.222.3.444 48992 typ srflx raddr 0.0.0.0 rport 48992 ufrag yNAmdGYQYdAYJCXZ

[Sean-Der]

That's some weird behavior, thanks for reporting @caraar12345

NAT_ICE_CANDIDATE_TYPE=srflx was designed to be additive. When set it should publish LAN IP + WAN. So everything up to that point looks ok.

When set I would expect both candidates to use the UDP_MUX_PORT you specified though. That for sure is a bug.

If you are up for it I would love your help fixing! It's a pion/ice bug, and should be really easy to reproduce/unit test and fix :)