0

UPDATE

It turned out that the problem is unrelated to NAT and UDP hole punching. So I have created a new Q.

I've implemented UDP hole punching using the following approach:

A known server (no NAT), at a known port, is handling incoming UDP.

A client behind NAT sends a datagram to the server, after which the server responds by sending the address of a peer to this client.

The client now starts communicating with the peer using UDP over the same socket (but to different address of course.)

If after a while, the client stops communication with peer, and sends another datagram to the server again, this datagram does not arrive (unless I keep channels open by sending keepalive datagrams from server to client.)

My question: How come it is OK to switch from datagrams between server<->client to datagrams between peer<->client, but as soon as I switch back and the client sends to the server again, they don't arrive?

Community
  • 1
  • 1
Bram
  • 7,440
  • 3
  • 52
  • 94

1 Answers1

3

I suspect this behavior is specific to your NAT. It sounds like the port-mapping logic has issues. You could likely put in a different NAT box on your network and see different behavior.

My advice would be to always use a different local port and socket for each peer session. So let's say you were using port 2000 in the first session to talk to the server and peer, then the next session should use a completely different local port. Then whatever issues the NAT is having with the previous port won't impact this new socket.

In general, if you want to keep a UDP channel open between a pair of hosts, you should have at least one packet flowing every 45 seconds.

selbie
  • 100,020
  • 15
  • 103
  • 173
  • Thanks. Local port refers to the ephemeral port? Note that I never choose this port. When starting communication, the client sends one datagram to the known port of server (which cannot change per session.) The server then sees the client on an ephemeral port. To get a new one, I close the socket, create a new one, and send again? – Bram Jan 02 '14 at 16:28
  • This is weird: closing the socket, and creating a new one does not work. Restarting the application gives me access to the server again. But closing the socket, creating a new one, and sending a datagram does not. – Bram Jan 02 '14 at 22:36
  • Have you done a network trace both on the client side and on the server side to see if the packets are actually getting sent and received? – selbie Jan 02 '14 at 23:17
  • Yeah, using iptraf now, and also moved clients+server to my LAN, so there is no NAT involved anymore. Still the same problem, so I should close this Q, and create a new one as it is not related to hole punching. My router is Apple Airport Extreme, so not a cheap crappy one. – Bram Jan 02 '14 at 23:39
  • 2
    You didn't post any code, but from what you are saying now, it sounds more like a socket coding problem. You should post your code in subsequent posts. – selbie Jan 02 '14 at 23:58