I know it's possible to change the UDP port to bind to Battle.net, but I don't know exactly how to do so. I'm pretty sure it's within the sending of 0x50, but I don't know.
Any help would be appreciated.

If you're talking about the local port from which to send a UDP ping, you can bind that to whatever port you like. Battle.net will respond correctly. I believe the game checks about 100 ports (starting at 6112), I'm not sure of the exact number. It binds to the first one that's not in use.

The game's binding can be tuned using the "Game Data Port" registry value. Set it to a dword containing the port number you want to use.

I'm trying to get my bot i'm working on to be able to connect to Battle.net via UDP, get the DWORD for 0x14, and then send 0x14.
I've managed to get it working successfully, but only when I bind the UDP socket to port 6112 will it actually work.
I was thinking that the problem was in the sixth DWORD of 0x50 (Local IP for NAT compatibility), which I send as Null, but if this was true, why am I able to connect successfully via port 6112?

[quote author=UserLoser. link=board=17;threadid=4809;start=0#msg40410 date=1074647951]
[code]
With MyUdpSocket
.RemoteHost = "useast.battle.net"
.RemotePort = 6112
.Bind 6112
End With
[/code]
[/quote]

Why are you specifying port 6112 twice? Also, you shouldn't assume that port will always be available.

If you're going to be using this for games, don't set up the socket the way UserLoser. said. At least at the OS layer, and presumably VB doesn't screw this up, specifying a peer for a UDP socket causes the OS to silently discard all traffic from hosts other than the peer. As UL's code is written, this would occur and you'd only be able to play with someone running off the battle.net server. :P

[quote author=UserLoser. link=board=17;threadid=4809;start=0#msg40410 date=1074647951]
[quote author=LoRd link=board=17;threadid=4809;start=0#msg40361 date=1074624526]
I'm trying to get my bot i'm working on to be able to connect to Battle.net via UDP, get the DWORD for 0x14, and then send 0x14.
I've managed to get it working successfully, but only when I bind the UDP socket to port 6112 will it actually work.
I was thinking that the problem was in the sixth DWORD of 0x50 (Local IP for NAT compatibility), which I send as Null, but if this was true, why am I able to connect successfully via port 6112?
[/quote]

Assuming you're using Visual Basic, when you first connect before sending 0x50:

[code]
With MyUdpSocket
.RemoteHost = "useast.battle.net"
.RemotePort = 6112
.Bind 6112
End With
[/code]

This will create a UDP socket set up, no events such as socket_Connect() will be fired

Upon recieving 0x50, it contains two DWORDs that you should echo back to Battle.net through this UDP packet:

(DWORD) 0x09
(DWORD) Server Token (Or the second DWORD not counting the header)
(DWORD) UDP value (Or the third DWORD not counting the header)

After sending that, Battle.net should send you back a couple UDP packets that contain the UDP code used in (TCP) 0x14

These UDP packets back from Battle.net is the following format:

(DWORD) 0x05
(DWORD) UDP value used in 0x14

As far as sending a Null DWORD in 0x50 for Local IP, that doesn't have anything to do with setting up a UDP socket, or getting the servers to respond to you...

If you're looking to set up UDP support for joining/hosting games, you don't need one for the Battle.net servers since games is all joining users-><-game host
[/quote]

I've got all this already, but as I said I don't want to use port 6112, and just changing 6112 to say 6113 or something doesn't seem to be working.

[quote author=UserLoser. link=board=17;threadid=4809;start=0#msg40413 date=1074648583]
You'll know if it's not available if it doesn't work

Also, since when is LocalPort the same as RemotePort?
[/quote]

Didn't know it ever was, who told you that? I'm wondering why you're setting the remote port if you're never going to use it.

And you're fine with "6112 is in use, oh well -- no UDP support for you"? You should allow the system to find a free port instead of using a static port which may not always be available.

[quote author=UserLoser. link=board=17;threadid=4809;start=0#msg40497 date=1074702783]
Whatever, complain, complain bitch bitch, I don't have to do everything the way vL does it
[/quote]
Nobody said anything about doing stuff "the way vL does it". In any case, as Kp pointed out, the problem is that your method will restrict you to receiving data from only Battle.net itself. Thus, you will fail to properly receive things like replies to game-pings or other UDP traffic sent to non-Battle.net hosts which requires a reply.

[quote author=Skywing link=board=17;threadid=4809;start=0#msg40519 date=1074713233]
In any case, as Kp pointed out, the problem is that your method will restrict you to receiving data from only Battle.net itself. Thus, you will fail to properly receive things like replies to game-pings or other UDP traffic sent to non-Battle.net hosts which requires a reply.[/quote]

In addition to the problem that Spht pointed out with it potentially failing if port 6112 is busy (perhaps because the user is already running Starcraft). :)

I suppose at some point somebody should address the original question. Send battle.net a message to let it know where your socket has been bound.