-
-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorrect REQUESTED-ADDRESS-FAMILY attribute length #12
Comments
@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 ? |
Seems you're setting the length to 5 byte now (the payload + 4 bytes of padding) 😄 |
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 :) |
I think the answer is "yes it should include them", it's one byte payload plus three reserved bytes, no?
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.
Works just fine now, thank you very much for the super-quick fix! 👍 |
Thanks! Uploaded version v0.4.0 with this fix: thanks again for the report! |
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 attribute0x0017
.)At least eturnal rejects requests for this reason (because "be strict in what you accept").
Many thanks for this great tool!
The text was updated successfully, but these errors were encountered: