Using the jingle demo app I am not able to establish a connection between two machines,
each residing behind NAT firewalls.
My configuration contains two machines “L” and “R”. Machine “L” is residing behind a
Restricted Cone NAT and machine R is resisting behind a Port Restricted Code NAT.
(I determined the NAT configuration using de.javawi.jstun.test.demo.DiscoveryTestDemo
found in smackx-jingle.jar).
On both machines “L” had “R” I am using the demo program from the Smack trunk revision
8549 with a minor modification to use a STUN server (built from code at
http://sourceforge.net/projects/stun/) located on a third machine “S” with a direct
Internet connection. I did this simply to help capture the STUN info.
After quite a bit of spec reading and digging in the Smack jingle extension code I have
concluded that either a) I completely confused as to how a UDP NAT hole should be punched
or b) the current jingle code is not doing the right operations to punch UDP NAT holes
given my configuration.
OK, here is what I see happening…
- Demo is started on machine “L” and gets a STUN MappedAddress: 22.214.171.124:37212.
From ethereal I know that the source port used to connect to the STUN server was port 37212.
- Demo is started on machine “R” and get MappedAddress: 126.96.36.199:18260. From ethereal
I know that the source port used to connect to the STUN server was port 42614.
- When I initialte the call from “L” to “R” I get the following candidates and listeners
on machine “L”
C: /192.168.0.2|/192.168.0.2 p:2195
Listening for ECHO: 192.168.0.2:13334
C: /188.8.131.52|/192.168.0.2 p:1103
Listening for ECHO: 192.168.0.2:19974
- on machine “R” I see its candidates and listeners
C: /10.1.2.17|/10.1.2.17 p:2195
Listening for ECHO: 10.1.2.17:13586
Listening for ECHO: 10.1.2.17:12808
C: /184.108.40.206|/10.1.2.17 p:1103
- Machine “R” get candiates at machine “L” (yes I did a little XML formatting to help readibility)
- Using ethereal I see machine “L” attempt to transmit (Echo) UDP packets to machine “R”
based upon the second candidate listed in step (6). Here is the first of 10 attempts…
No. Time Source Destination Protocol Info
3 19.295599 192.168.0.2 220.127.116.11 UDP Source port: 19974 Destination port: 12808
- Negotiation Closed.
If you are still with me here are my questions:
A) I am not sure how any packets can get across the NAT from an external host by using internal
port numbers. Shouldn’'t the external candidates exchanged between “L” and “R” provide and external port
(specifically the external port reported from the STUN server in steps (1) and (2))?
B) From what I understand from documents like http://www.brynosaurus.com/pub/net/p2pnat/ the key to
getting across a NAT to a known “internal” port is for a remote machine to transmit to known “external”
port from a previously established port mapping. Shouldn’'t the external candidates listed in steps 3 and
4 set up listeners with the same (internal) port used to communicate with the STUN server?
Thanks in advance for any information anyone can provide as to why I can not establish a successful
NAT hole punch with my configuration.