Skip to main content
GameDev.net gamedev.net
🔒 Locked

"Solicited UDP packets"? [RESOLVED 9/28]

Started by Waverider Sep 24, 2008 at 4:13 PM 20 replies 9.4k views
Original Post
Waverider
Waverider
Greetings, all. I've been fiddling with Winsock 2.2 programming with some success. I've written an app that uses TCP, and it functions rather well. Recently, however, I've attempted some UDP programming. In order to get an idea what kinds of troubles I'll have to deal with over the internet, I wrote a small chat program that also sends packets to the other machine to perform an analysis on packet loss and overall data rate. It entirely uses UDP, which of course, presents its own difficulties... The one I want to ask about here is the concept of "solicited UDP". Apparently, some routers that otherwise block UDP packets will recognize an outgoing UDP packet and will temporarily allow a response through the sending packet's port. This allows the host side to send a response back and allow the sending machine to receive it. However, in my initial testing, the client's machine was failing to receive my packets at all (I was serving as the host). The client connects by first sending a UDP packet with username information. Then, when the client types in a chat message, that request is sent to the host which then sends the chat message back to the client to be echoed on their screen. The client wasn't seeing those messages, so this apparently wasn't working. I've tested it on my LAN, and my local machine, and it works fine. * My primary question is: Is there a way in Winsock to flag a sent UDP packet as "solicited", or is this entirely an automatic router function? Any links to articles or mention of Winsock functions and flags to set would be appreciated. I've been combing through MSDN and various other google attempts to no avail. Thanks for any insight! [Edited by - Waverider on September 28, 2008 9:33:32 PM]
It's not what you're taught, it's what you learn.
Evil Steve
Evil Steve
Quote:
Original post by Waverider
However, in my initial testing, the client's machine was failing to receive my packets at all (I was serving as the host).

* My primary question is: Is there a way in Winsock to flag a sent UDP packet as "solicited", or is this entirely an automatic router function?

Any links to articles or mention of Winsock functions and flags to set would be appreciated. I've been combing through MSDN and various other google attempts to no avail. Thanks for any insight!
There's no flag to do this, no. It's entirely up to the router. If there was such a way, then everyone would just flag them as such to get through routers.

The problem is that you need to be able to get through on one side before you can send a reply. Have a look on google for NAT Punch Through, this link looks promising.
Waverider
Waverider
Quote:
Original post by Evil Steve
The problem is that you need to be able to get through on one side before you can send a reply.


Thanks for the link, I'll take a look at it.

In response to this comment, I didn't make it clear that I did in fact see login information and chat messages from the client, he just wasn't getting them back from me. Will NAT punch-through still help?

It's not what you're taught, it's what you learn.
Evil Steve
Evil Steve
Quote:
Original post by Waverider
In response to this comment, I didn't make it clear that I did in fact see login information and chat messages from the client, he just wasn't getting them back from me. Will NAT punch-through still help?
Ah I see, sorry. I don't think NAT punch-through will be much use here, that's more for when both sides are behind a router.

Are you using the same SOCKET to send and recieve on? I'm a bit rusty on UDP unfortunately [smile]
Waverider
Waverider
UDP is connectionless, so I'm just replying using a reserved socket (not one directly generated from the client connecting as TCP would, just one I allocated space for) and the address info sent on the login request. It works locally and on my LAN, so I was assuming it would work on the internet as well.

However, I could see where a router with its DMZ set to a different machine would route the packet incorrectly. Routers might do some things automatically, but I don't expect they would be able to predict where a UDP packet is REALLY meant to go...

Frustrating.

Maybe I should just try the app with someone else. Perhaps that first user's setup is just being difficult.
It's not what you're taught, it's what you learn.
Evil Steve
Evil Steve
Quote:
Original post by Waverider
Maybe I should just try the app with someone else. Perhaps that first user's setup is just being difficult.
It's definitely worth a shot. You could try forwarding the UDP port you're using on the router to check that works - if it doesn't, then there's a chance the packet is being dropped on the Internet. You could also try disabling any software firewall, and / or running a packet sniffer on the other machine to see if the packet is actually being recieved by the machine but is being dropped by the OS or software.
Waverider
Waverider
After our little troubles, he opened up the port it hosts on and we reversed roles. I DMZ'd my machine so that I would be sure to receive the responses. That part worked fine.

By the way, UDP packets above 1k size fragment often enough to not bother with... :P
It's not what you're taught, it's what you learn.
Waverider
Waverider
I just tried it again with my router NOT DMZ'd with him hosting, and it worked. So something about his setup prevents my host from sending a packet to him, but my router allows solicited UDP just fine.

How is he browsing? (DNS requests are UDP, that's how I found out about "solicited" in the first place).

Oh well, at least I learned something!

Thanks!
It's not what you're taught, it's what you learn.
Waverider
Waverider
I just tried hosting with someone else... same problem.

Curses.
It's not what you're taught, it's what you learn.
Captain Griffen
Captain Griffen
There is no real way around this apart from for the host to have the router configured to allow it, I think. If there was, then I suspect that commercial games would use it - as it is, pretty much every game requires a correctly set up router in order to be able to host behind it.
Waverider
Waverider
Quote:
Original post by Captain Griffen
There is no real way around this apart from for the host to have the router configured to allow it, I think. If there was, then I suspect that commercial games would use it - as it is, pretty much every game requires a correctly set up router in order to be able to host behind it.


Hosting isn't the problem. The problem is getting the client router to accept a response UDP packet via "solicited UDP". It works when I'm a client, but not when someone else is, so far.
It's not what you're taught, it's what you learn.
hplus0603
hplus0603
First, read up on how NAT (Network Address Translation) works. There are some links in the Forum FAQ, and there are lots of links that are just a Google search away. Without understanding how NAT works in detail, you'll have trouble getting this set-up to work.

Second, I recommend using WireShark to capture packets on both ends -- and, ideally, capture packets on the outside of the routers as well.
enum Bool { True, False, FileNotFound };
Waverider
Waverider
I've read up on NAT, I'm just not sure it applies to me. If the client's router is using NAT, then the UDP packets I receive from him should have an IP:port for me to reply to, which I do. The client's router, using its NAT that it filled in when that client sent his first UDP packet out, should route my response back to the correct machine.

It works great when I'm a client. I even connected up with two machines from my LAN, and the host out on the internet sent the corresponding packets back to each of my machines correctly.

To further investigate, we both enabled logging on our routers and looked at the IP:port's being sent and received. When I was hosting, I received and sent packets just fine to their expected destination. On the client's side, he saw that he was sending packets to me, but he had no log of the packets I sent to him. Further testing this, I blocked everything on my router and continued. His chat messages no longer showed up, but my router log still recorded his packets, even though they were blocked.

This is really a mystery. This almost, ALMOST suggests that my outgoing UDP packets as a host are being blocked at my own router. But that doesn't make any sense, because as a client, I can connect to him, which shouldn't be possible if my router is blocking my outgoing packets.

I'll continue reading up on NAT for more clues. At this point, I don't think the clients that have connected with me (3 so far, none can see my packets) are ALL using more than one router in their networks. It would seem to me the NAT vulnerabilities shouldn't be this prominent.
It's not what you're taught, it's what you learn.
Waverider
Waverider
On the plus side, I allowed my tester across the net to host (which always worked) and ran 3 instances of the app on one of my machines and 3 more on my laptop, both machines on my LAN. All 6 processes received their respective messages. So my router is NATing quite well.

Looking more at the NAT articles, I'm still not seeing how they apply to me. I usually recommend that someone open up a port through their router if they want to host anything at all. NAT Punch Through seems to be only for machines that can't establish a connection either way. With my app, once one machine receives a UDP packet successfully (which always happens through the opened port), it attempts to reply to the client with the address and port in the sent packet (which works when he hosts, but not when I do).
It's not what you're taught, it's what you learn.
hplus0603
hplus0603
To me, it sounds like a firewall bug or configuration problem on your end. Putting Wireshark on the inside and outside of your firewall ought to tell you where the packets get dropped.
enum Bool { True, False, FileNotFound };
Waverider
Waverider
I took a look at WireShark.

I'm assuming to get it to work I would have to install it on my sending machine behind my router, and have it installed on another machine just outside my router but before my cable modem?

From a programmatic standpoint, the problem just doesn't make any sense. All I use for communication is recvfrom() and sendto() with address parameters. That's it. Any concept of "connection" is only how each program just holds on to the address info for each send, and how routers open that temporary tunnel for "solicited UDP". Why would it work on my router when it's closed and I'm a client, but not when it's open and I'm hosting? Wouldn't I notice other difficulties on my machine, like DNS lookups failing or something?
It's not what you're taught, it's what you learn.
hplus0603
hplus0603
For DNS look-ups, you are always a client. It sounds like when you think the router is "open," it might not actually be. Or it's some "personal firewall" on your machine getting in the way.

If your router supports port forwarding, then that might be a simpler way to get a server set up than trying to set up a full DMZ.
enum Bool { True, False, FileNotFound };
Waverider
Waverider
I tried to get port forwarding set up, but for some reason my router continues to reset to its current values.

Frustrating. I'll keep fiddling with it. If I discover anything, I'll be sure to report back here. If it's solved with programming I'll definitely be writing an article.
It's not what you're taught, it's what you learn.
hplus0603
hplus0603
Quote:
for some reason my router continues to reset to its current values


Sounds like the problem is your router.
enum Bool { True, False, FileNotFound };
Waverider
Waverider
SUCCESS!

I made a rookie mistake.

It wasn't my router. Actually my router was working as a client because it's older.

Today's routers apparently have two-way validation, meaning they keep track not only of where local packets came from, but also where they are going. And the only packets they will allow back are the ones addressed from the same IP:port that the client sent the first UDP packet to!

I was sending host responses through a separate socket that I allocated to each client that connected instead of the port-bound socket I was listening on! That means the port number didn't match the router's record, so the client's router blocked it!

*Falls down*

I recompiled it to send everything out through the host's bound listening packet and everything works!

I discovered this by downloading some UDP Chat C# code that worked. The only difference from my code was that the host sent responses out through the listening socket!

Whew, glad that's over. I'm off and running now...

Thanks for the help!

[Edited by - Waverider on September 29, 2008 8:29:31 AM]
It's not what you're taught, it's what you learn.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.