Incorrect REQUESTED-ADDRESS-FAMILY attribute length

[weiss]

stunner sets the length of the REQUESTED-ADDRESS-FAMILY attribute to 1 byte, whereas the "length of this attribute is 4 bytes" as per RFC 6256 (just as for e.g. REQUESTED-TRANSPORT, which does have the correct length):

(Wireshark calls it REQUESTED-ADDRESS-TYPE, as that was the initial name for attribute 0x0017.)

At least eturnal rejects requests for this reason (because "be strict in what you accept").

Many thanks for this great tool!

[firefart]

@weiss good catch thanks! I currently have no IPv6 enabled turn server at hand for testing but pushed a quick fix to the main branch. Can you please test if this now works with eturnal ?

[weiss]

Seems you're setting the length to 5 byte now (the payload + 4 bytes of padding) 😄

[firefart]

Jeah the RFC is not clear about this whether the length value should include the reserved bytes or not, wireshark decodes it correctly but that does not mean anything :)
This page https://docs.microsoft.com/en-us/openspecs/office_protocols/ms-turn/e7efc457-9312-4a6b-8089-94032a599198 means to always set the length to 0x0004 so will try that

[firefart]

With the latest changes:

can you please try again?

[weiss]

Jeah the RFC is not clear about this whether the length value should include the reserved bytes or not,

I think the answer is "yes it should include them", it's one byte payload plus three reserved bytes, no?

always set the length to 0x0004 so will try that

Yes I'm pretty sure that's what the RFC is trying to say as well. Wireshark and other servers can obviously decode things just fine by accepting other lengths (as long as they match reality), I'm just deliberately picky in eturnal.

can you please try again?

Works just fine now, thank you very much for the super-quick fix! 👍

[firefart]

Thanks! Uploaded version v0.4.0 with this fix:
https://github.com/firefart/stunner/releases/tag/v0.4.0

thanks again for the report!