Not able to use STUN with WebRTC

[Gili]

Hi,

I am using version 3.0.0.0 of the server. TURN works fine, but I am having problems getting STUN to work. "stun:stun1.l.google.com:19302" works fine so I know the client is not at fault. Here is my configuration:

1. Pass "stun:myhost.org" to WebRTC.
2. Set "stun-only" in the server configuration.
3. One peer is behind the same NAT as the server (so I don't expect STUN to see his external IP) but I expect it to see the external IP of the remote end.
4. I try connecting the peers.
5. Wireshark shows the client connecting to the server, but WebRTC ICE candidates only contain local IPs.

How do I debug this further? I tried enabling "Verbose". It generated a very noisy log but still nothing stood out. When I tried "verbose" the log was a lot more readable and I see the following:

1385412610: handle_udp_packet: New UDP endpoint: local addr 192.168.1.100:3478, remote addr 91.234.135.178:19632

1385412610: handle_turn_command: STUN method 0x3 ignored

1385412610: handle_turn_command: STUN method 0x3 ignored

1385412611: TURN connection closed, user <>

Any ideas?

Gili

[Oleg Moskalenko]

Message "STUN Method 0x3 ignored" means that the client sends ALLOCATE request (0x3) to the STUN server. As you set the option --stun-only, the ALLOCATE request is ignored. You are using TURN (ALLOCATE is part of TURN) but you are not allowing TURN on the server. This is the problem.

Find out what exactly you want to do. If you want to use both TURN and STUN simultaneously, then do not set --stun-only option. You can always debug what is going on with wireshark. Decode the packets as "STUN".

[Gili]

Update: I just noticed that Wireshark reported Header Checksum: 0x0000 [incorrect, should be 0x60bd (may be caused by "IP checksum offload"?)]

Does that tell you anything?

Gili

[Gili]

I only want to use STUN. It's possible I was quoting the wrong section of the log file so let's ignore this. I think the main problem is the header checksum I mentioned below.

Gili

[Oleg Moskalenko]

I do not know whether that's related. But I know for sure that your client is trying to make TURN requests and you do not allow TURN requests on the server. Try to figure out what exactly you are doing. See what messages are going in both directions, in the wireshark.

[Gili]

Hi Oleg,

Please ignore the previous log I attached as it might have been incorrect.

I reproduced the problem as follows:

1. Configured WebRTC clients with a single STUN server: { "iceServers": [ { "url": "stun:my-server.com" } ] }
   
2. Checked for and removed any reference to TURN in the clients.
3. Enabled "stun-only" and "Verbose" in the server configuration.
4. Cleared all server logs and started the server.
5. Initiated a connection between two peers (one on the same machine as the server, one remote).

My local peer never received the address of the remote peer from the STUN server. I checked Wireshark and saw the same checksum error. I am attaching all relevant logs and configuration files for your review. I have emailed you the wireshark log separately as it contains sensitive information.

Thank you,

Gili

[Oleg Moskalenko]

I checked the pcap file and I found that the STUN server works fine. It is sending the responses. I'll send more explanations in the email reply.

[Gili]

Following up on this exchange, here is what I discovered:

1. Wireshark may detect invalid header checksums for packets that originate from the same computer as the recorder: http://ask.wireshark.org/questions/13577/header-checksum-error-incorrect-should-be
2. Because the STUN server is running inside the same LAN as one of the peers, it returns the gateway address (192.168.1.1) instead of the peer's public IP. This prevents the remote peer from establishing a connection.

Conclusion: the server is working as expect. Nothing to see here :)

Gili