STUN response with SOFTWARE attribute causes compatibility issue with FreeSWITCH

[alekseiZh]

Hello,

I'm encountering an issue when using your STUN server with FreeSWITCH.

When the server responds to a Binding Request with a Binding Success Response that includes the SOFTWARE attribute before the XOR-MAPPED-ADDRESS attribute, FreeSWITCH fails to extract the IP and port, even though the packet is RFC 5389-compliant.

Examples

Captured using Wireshark:

Working STUN Response (IP/port extracted successfully)

Message Type: 0x0101 (Binding Success Response)
Message Length: 12
Attributes: 
    XOR-MAPPED-ADDRESS: x.x.x.x:48755

Problematic STUN Response (Returns success, but IP/port are NULL)

Message Type: 0x0101 (Binding Success Response)
Message Length: 32
Attributes: 
    SOFTWARE: "P1 STUN library"
    XOR-MAPPED-ADDRESS: x.x.x.x:34996

Both messages appear well-formed and are accepted by Wireshark and other parsers.

Questions

1. Is the order of attributes in your response configurable?
2. Would it be possible to place XOR-MAPPED-ADDRESS before other attributes like SOFTWARE?
3. Alternatively, is there a known workaround on the client side for this behavior?

Thanks in advance

[weiss]

The order currently isn't configurable, and an option to do that seems a bit weirdo to me.

I see the following solutions:

1. Hard-code a different order, hoping that the new order will be good enough for everyone.
2. Allow for omitting the SOFTWARE attribute altogether.
3. Do both.

I'm leaning towards (2). The RFC says that

the server SHOULD add a SOFTWARE attribute to the message.

However, it also says:

Revealing the specific software version of the agent through the SOFTWARE attribute might allow them to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make usage of the SOFTWARE attribute a configurable option.

Therefore, such an option might make sense anyway, to allow for some security by obscurity.

I guess that should do the trick for you?

(Regardless of what we do, this sounds like FreeSWITCH might want to fix their client.)

[alekseiZh]

I guess that should do the trick for you?

Yes, I believe it should work. Thank you! I'm still awaiting a response from the FreeSWITCH team.

[weiss]

In case that helps with testing, we've published new Linux binaries/packages here (temporarily):

https://eturnal.net/tmp/HEAD-2025-03-24/

Those would allow for setting software_name: none.

[zinid]

@weiss thank you for the fast fix! However, we are using your official containers and it seems like the "edge" container is still lagging behind. Any plans to update it?

[sando38]

@zinid will look into the container tonight.

[sando38]

@zinid fixed.

[zinid]

It seems like the fix only works only when TURN is enabled. And that is a problem in the "stun" library: it only sets all the options in "prepare_state" when use_turn is true. However, we use eturnal as a STUN server only and enabling TURN is a potential risk for us.

[weiss]

We should find the guy who wrote that library.

(Will have a look later.)

[weiss]

Next try …