Re: [reTurn-devel] Wireshark reports malformed STUN packets from reTurn
I was digging into this more and found that the problem with Wireshark showing malformed, is not just a problem of the SOFTWARE header being present, it's that fact that the length of the field is using the new RFC5389 rules for string sizes - whereby the length of the header is NOT supposed to be padded to the nearest 4 byte boundary, as specified by the older RFC. In order to make things look better in Wireshark, I've padded that actual content of the software header to be on a 4 byte boundary, in order to play nicer with wireshark and other entities expecting the older RFC behavior. I've checked this into SVN head.
Thanks,
Scott
On Sat, Jul 25, 2009 at 1:09 PM, Scott Godin
<sgodin@xxxxxxxxxxxxxxx> wrote:
Hi Eric,
First off - what version of reTurn are you using? I would recommend with SVN head or resiprocate version 1.5 tarball. Those versions of return have passed all of the STUN message tests from draft-ietf-behave-stun-test-vectors-04.
One thing to keep in mind is that reTurn implements the lastest stun rfc 5389. RFC 5389 is relatively new and specifies a new SOFTWARE header - this is what's causing Wireshark to show a malformed packet. However stun clients should be ignoring headers they don't understand, so this should be causing any issues. If you want to avoid placing that header in the STUN messages from reTurn you can change line 145 of RequestHandler.cxx to say if(0) instead of if(1) - I eventually want to make this a setting.
Note: I'll provide some more info in response to your other posting.
Thanks,
Scott
On Fri, Jul 24, 2009 at 7:17 PM, Eric Chamberlain
<eric@xxxxxx> wrote:
Hello,
While troubleshooting a Linksys SPA942 STUN issue, I noticed that Wireshark (1.2.1 OS X build) reports that the STUN response packets are malformed.
Is there an issue with the STUN response packets, or is wireshark giving a false indication?
--
Eric Chamberlain, Founder
RF.com - http://RF.com/
_______________________________________________
reTurn-devel mailing list
reTurn-devel@xxxxxxxxxxxxxxx
List Archive: http://resiprocate.org/archive/return-devel/