• Welcome to Valhalla Legends Archive.
 

UDP Issues when adding support to bot in VB

Started by Don Cullen, October 18, 2007, 07:45 PM

Previous topic - Next topic

UserLoser

Quote from: Don Cullen on October 19, 2007, 12:42 AM
Quote from: Banana fanna fo fanna on October 19, 2007, 12:22 AM
I feel like there's a NAT somewhere that you missed. Oftentimes when one sends a UDP packet on a certain post to a certain host, the NAT opens a hole in the firewall for packets coming from that host and that port. This is how two people behind NATs can play StarCraft. I'd suggest sending a dummy UDP packet to the host you're trying to reach (BNET) on the port you're trying to use (6112?) before trying to login.

0x09 is sent prior to logon. No response is gotten. WireShark doesn't even catch the 0x09 outgoing udp packet.

Quote from: UserLoser on October 19, 2007, 12:29 AM
what are you setting the local port to for the UDP socket ?

6112.

I uploaded the source if you'd like to see if the UDP works fine.

If you do test it, basically, you should get a pop up msgbox saying "Got udp" when an udp packet comes in. For me, nothing pops up, but for the others who've tested it so far, it did pop up for them.

http://www.bnetdocs.org/archives/SanityOCX.zip

Are you sure you're not setting the local port on your TCP sockets to 6112 also (not needed/doesn't matter)?

Don Cullen

Quote from: UserLoser on October 21, 2007, 04:16 AMAre you sure you're not setting the local port on your TCP sockets to 6112 also (not needed/doesn't matter)?

I'd presume no.

Call BNETSock.Connect(sBNETAddress, lBNETPort)
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

Sorc.Polgara

#32
Quote from: Leaky on October 19, 2007, 06:24 PM
i do ISP tech support so i can tell you that disabling the windows firewall doesn't always disable it.. that's like saying turning off automatic updates turns automatic updates off... i would still add your program to the exception list trust me i've seen that be the issue way to many times to ignore it
If you work for cox, remind me to smack all of you.





That was kinda in jest...  It makes me want to pull my hair out and gouge pencils in my ears whenever I have to call my ISP tech support, just to go through a large checklist of things I've already done every single time.

Leaky

lol i don't work for cox and i do DSL tech support iuno what cox internet uses...

basically my checklist goes like this

unplug modem
plug modem in
go to google
hang up

Chriso


Don Cullen

Okay, I just got home. As all of you know, the UDP suddenly started working when I got to my girlfriends home and ran the bot while using her internet (AT&T DSL). So I was able to personally confirm it was fully functional.

Then I got home today, and ran the bot again. Now there's no UDP.

So my assumption is that it's the network.

I have a SR-200 router, which is very similar to (actually, it *IS*) the DI-604 by D Link. The SR-200 is just an OEM corporate-labeled version of the DI-604. Same interior architecture, same model, same web interface (minus D Link logo, plus Sorenson logo). My laptop is directly connected to the router, which in turn is connected to the cable modem (Motorola SB5120 Surfboard modem).

Ideas?
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

herzog_zwei

Since the same code works for some but not others, it's likely routing/NAT/firewall issue.  Disable any firewalls you have on your OS and connect your machine directly to the modem to avoid any problems that might be caused by the router.  If that works, your network and/or your code might be NAT unfriendly.  I believe most transparent NATP implementations open up a random port on the initial outbound UDP packet and incoming UDP must have a matching destination IP/port of what was opened on the router and a matching source IP/port of the initial UDP packet sent to.  If this isn't the behavior you want, you'll need to do more sophisticated routing/port forwarding.

You mentioned that sometimes you see UDP packets and sometimes you don't.  UDP is unreliable so when resources are low, UDP packets have a higher chance of getting dropped compared to other types.  You should run the code without any other heavily resource (CPU, network) intensive programs running to make sure this isn't the problem.

Don Cullen

Quote from: herzog_zwei on October 22, 2007, 01:31 PM
Since the same code works for some but not others, it's likely routing/NAT/firewall issue.  Disable any firewalls you have on your OS

I went one step further, I added the ports to the WinXP firewall (even though it was disabled), and also clicked advanced and added the ports to the services. No luck here.

Quoteand connect your machine directly to the modem to avoid any problems that might be caused by the router.

That worked.

QuoteIf that works, your network and/or your code might be NAT unfriendly.  I believe most transparent NATP implementations open up a random port on the initial outbound UDP packet and incoming UDP must have a matching destination IP/port of what was opened on the router and a matching source IP/port of the initial UDP packet sent to. 

How would I best determine whether my code is NAT unfriendly? Also, how would I make my router be NAT friendly?
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

Leaky

Quote from: Don Cullen on October 22, 2007, 06:25 PM
Quote from: herzog_zwei on October 22, 2007, 01:31 PM
Since the same code works for some but not others, it's likely routing/NAT/firewall issue.  Disable any firewalls you have on your OS

I went one step further, I added the ports to the WinXP firewall (even though it was disabled), and also clicked advanced and added the ports to the services. No luck here.

Quoteand connect your machine directly to the modem to avoid any problems that might be caused by the router.

That worked.

QuoteIf that works, your network and/or your code might be NAT unfriendly.  I believe most transparent NATP implementations open up a random port on the initial outbound UDP packet and incoming UDP must have a matching destination IP/port of what was opened on the router and a matching source IP/port of the initial UDP packet sent to. 

How would I best determine whether my code is NAT unfriendly? Also, how would I make my router be NAT friendly?

wait wait wait wait.. so connecting directly into the modem worked?

so the issue is your router... and NAT...

Don Cullen

#39
Quote from: Leaky on October 22, 2007, 09:16 PMwait wait wait wait.. so connecting directly into the modem worked?

so the issue is your router... and NAT...

It would seem to be so.  ;)

If even with the assistance of the others I am unable to resolve the router/NAT issue, I'll probably just go ahead and replace the router. I tried replacing the firmware of the SR-200 with the DI-604 firmware so I could update it (Sorenson stopped bothering updating the firmware), but that was undoable. Googled various methodologies of hacking the firmware of the DI-604 and applied them on the SR-200, didn't work. Tried deliberately crashing the router's firmware so I could replace it, didn't work. In short, SR-200, for me at least, is uncrackable. So unless a solution to fix the NAT/router problem is found, the router may have to be replaced. :\
Regards,
Don
-------

Don't wonder why people suddenly are hostile when you treat them the way they shouldn't be- it's called 'Mutual Respect'.

herzog_zwei

#40
Quote from: Don Cullen on October 22, 2007, 06:25 PM
How would I best determine whether my code is NAT unfriendly? Also, how would I make my router be NAT friendly?

The key to designing a NATP friendly (as much as possible) UDP protocol has to do with:

QuoteI believe most transparent NATP implementations open up a random port on the initial outbound UDP packet and incoming UDP must have a matching destination IP/port of what was opened on the router and a matching source IP/port of the initial UDP packet sent to. 

Most UDP based games probably don't follow that rule so you have to use other routing tricks like port redirection and forwarding on the router.

A simple test to make sure your code is NATP friendly (assuming you have a router that implements what I described) is to have one side of the network NATed (internal) and the other side normal (external).  Have your program run on the NATed side (making sure the program initiates the connection to open up a random port on the router) and set up a data reflector/echoer on the other side to send back the data.  If you receive the reflected data no matter what random port is opened on the router, it's as (transparent) NATP friendly as you're going to get.  You should not have any code on the client that expects data to be received from any specific port nor embed local/internal IPs/ports to try to traverse the NATed network (some protocols do this and IMO is the wrong way to do it due to security issues and requiring proprietary routing code, not to mention it doesn't always work).

Cheap routers generally don't give you much control over NAT so you'll need to play around with it to figure out how their NAT is implemented and work around it.  Because most peer to peer UDP multiplayer (with more than 2 players) based games weren't designed with NAT in mind, you'll likely need to resort to port forwarding and/or redirection on the router.  For a single player behind NAT using a game that locally binds to a static port A, you can use port forwarding of port A between the external and NATed side.  For multiple players in a game that locally binds to static ports but the game server doesn't care about which port the datagram was sent on, you can redirect the ports and forward them based upon the redirected port on the external side and the internal IP on the NATed side.  For games that aren't NAT friendly, dynamically bind, or expects data sent to the server came from a specific port, your only choice would be to use direct connection or DMZ for single player and multiple IP NAT/forwarding for multiple players.  If your router supports UPnP, you can implement that to dynamically deal with port forwarding.

If you have an old machine lying around with nothing to do, set up Linux/BSD on it to do the routing/firewalling.  If you know what you're doing, you can fit everything you need onto a floppy disk (harder to do) or CD-ROM and not even have a HDD/monitor/keyboard/mouse installed.  You will need two NICs though, one for each of the internal and external sides.

Mystical


Leaky

Quote from: MyStiCaL on October 23, 2007, 06:34 AM
login battle.net create game see if anyone can join.


we've already established starcraft works perfectly fine....

and i've made various starcraft UDP related things and never had a nat or router issue... :P linksys i guess just magically works correctly

|