Subject: [midcom] Re: Reference STUN servers?

From: [email-masked]
Date: Thu, 20 Nov 2003 12:04:47 -0800

Hi Justin,

I noticed the same behaviour.  You (and anyone else) can use our beta server if they like, available at stun01.newkinetics.com  If you get any problems with it email me directly at [email-masked].  It's just going through testing right now, and at present doesn't support the TLS part of the spec (, to be implemented in the next month or so).

Hope this helps,

Les

_--
> 
> Message: 1
> Date: Tue, 18 Nov 2003 13:17:05 -0500
> From: "Justin Uberti" <[email-masked]>
> To: [email-masked]
> Organization: America Online
> Subject: [midcom] Reference STUN servers?
> 
> Hello,
> 
> I have been testing my STUN client library against the two public STUN
> servers I know of, stun01.sipphone.com, and larry.gloo.net. However, I
> am not getting the results I expect - when I send a binding request to
> the server and get back a CHANGED-ADDRESS, and then send a second 
> binding request to the CHANGED-ADDRESS, the servers reply to the binding
> request from a different port (i.e. not the one from the 
> CHANGED-ADDRESS). I am not setting any CHANGE-REQUEST flags.
> 
> ex:
> sending request to stun01.sipphone.com (69.0.208.27:3478)
> received reply from 609.0.208.27:3478
> source address = 69.0.208.27:3478
> changed address = 69.0.209.22:3479
> 
> sending request to 69.0.209.22:3479
> received reply from 69.0.209.22:3478 <----------- BAD
> source address = 69.0.209.22:3479
> changed address = 69.0.209.27:3478
> 
> I assume this is not the correct behavior, as it causes the NAT 
> detection flow proposed in the STUN RFC to detect port-restricted-cone
> NATs as symmetric NATs. Does anyone know of any running 'reference' 
> servers that are known to behave correctly?
> 
> Thanks in advance,
> Justin Uberti
> 
>

---

From: "Justin Uberti" <[email-masked]>
Date: Tue, 25 Nov 2003 13:47:39 -0500

Hi,

Thanks for getting back to me.

Here is a ethereal dump of a NAT discovery process for a restricted
cone NAT against the larry.gloo.net server. (The stun01.sipphone.com
server behaves similarly, I assume they both use the Vovida STUN
library).

Pay particular attention to frames 10 and 11. 10 is the outgoing Type-I
request to the CHANGED-ADDRESS; note that the destination port is 3479.
11 is the reply to that request; note that the source port is 3478,
which as Jonathan Rosenberg pointed out, is incorrect behavior.

The Vovida STUN library has a number of problems. Looking at the
stun.cxx file at the lines 1190-1200, it is clear that the code does
not look at what port the request is received on, the 'recvAlt'
variable is only set based on the IP address used. As a result, when
the time comes to send the reply, the reply to a CHANGED-ADDRESS
request is on the wrong port.

The Vovida library also does the NAT detection process incorrectly,
with the
result typically being that most NATs are incorrectly detected as Full
Cones.

I did try the stun01.newkinetics.com server and it seemed to work fine.

Regards,

Justin Uberti

Chief Architect

America Online

Cullen Jennings wrote on 11/23/2003, 7:45 PM:

> The best list to get this fixed would probably be email to

> [email-masked].

> Can you send me an ethereal dump with the message you send and the

> response.

> I will see if I can get it fixed on the larry.gloo.net server - I
don't

> think this should be happening.

> Cullen

> On 11/18/03 10:17 AM, "Justin Uberti" <[email-masked]>
wrote:

> > binding request to the CHANGED-ADDRESS, the servers reply to
the

> binding

> > _______________________________________________

> > midcom mailing list

> > [email-masked]

> > https://www1.ietf.org/mailman/listinfo/midcom