War2.ru Slogan
News: All hail our wise & benevolent admins!


Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
Welcome to the forums! We're glad to have you here! :) You can register your account here, then feel free to introduce yourself in the Server.War2.ru board & let us know who you are on the server.

The solution to hosting without port forwarding or UPnP 273  4

Grunt Posts: 50 Karma: +0/-0 ***

AHB

  • Grunt
  • ***
  • Posts: 50
    • View Profile
*

AHB

The solution to hosting without port forwarding or UPnP
« on: April 11, 2018, 09:30:55 AM »
UPnP is a great addition to WarCombat, but alot of routers these days are blocking UPnP.

The other day I had an epiphany for how it could be possible to host games without any port forwarding at all.

I was trying to hack an IP camera, watching the network traffic of how it communicates with "the cloud" when I realized that the cloud server was able to contact the camera even though I had not forwarded any ports to it.

That is made possible by STUN, and I don't totally understand how we would do it but this could allow people to host games without port forwarding I believe

http://www.ietf.org/rfc/rfc3489.txt

I even found some mention of it here in regard to Starcraft:
https://www.reddit.com/r/starcraft/comments/7l0t5z/starcraft_remastered_future_network_latency/

"Without getting too technical, there are 3 different types of NAT networks, and we've already rolled out a STUN server solution for the first type in patch 1.21 - we're hearing that you've noticed the difference in latency since its release. The second type is more complicated and we're working on it right now. The third type still requires the connection to route via a proxy server."

Another article I came across, this is by a famous hacker who created the Myspace worm (https://en.wikipedia.org/wiki/Samy_(computer_worm)) , one of my favorite hacks of all time lol

http://samy.pl/pwnat/

Sappers Posts: 857 Karma: +57/-0 ******

Lambchops

  • Sappers
  • ******
  • *
  • Posts: 857
    • View Profile
Re: The solution to hosting without port forwarding or UPnP
« Reply #1 on: April 11, 2018, 01:07:08 PM »
This is interesting stuff, but none of it is a stand-alone hosting fix, as far as I can tell. These are methods for unravelling NAT, which is cool, but there is still nothing that will make the game host send a packet to a client that is attempting to join, which is the missing step that is required for hosting.

There are many ways this could be accomplished, but they all involve some reasonably tricky mods and/or additions to the wc2 exe... one day maybe...

IDK maybe im wrong. I would be very happy to be wrong, but I don't think so. WC2 needed the game port mapped long before NAT was invented.
Grunt Posts: 50 Karma: +0/-0 ***

AHB

  • Grunt
  • ***
  • Posts: 50
    • View Profile
*

AHB

Re: The solution to hosting without port forwarding or UPnP
« Reply #2 on: April 11, 2018, 02:12:46 PM »
Lambchops,

Yes I think the game host has to contact the other players first (before they join the game) in order to open that inbound connection. However, the pvpgn server knows the IP of every player already, so what if a script was added to the client where the server sent the game host all IPs of the players, and the client reached out and contacted all the other players periodically to keep ports open to them

Something like that, I'm not really sure how it would work because the ports being opened by the game host to the other players would not be 6112? but if we spend some time learning how this problem has already been solved in other applications like VoIP then we can learn and understand how to hopefully apply it to PvPGN servers

Just look, I think theyve done it with Starcraft Remastered, it is possible I think
Grunt Posts: 68 Karma: +4/-0 KIng of Pool ***

Thumb$

  • Grunt
  • ***
  • *
  • Posts: 68
  • KIng of Pool
    • View Profile
Re: The solution to hosting without port forwarding or UPnP
« Reply #3 on: April 11, 2018, 04:49:32 PM »
the solutiom is "fuck U"
Sappers Posts: 857 Karma: +57/-0 ******

Lambchops

  • Sappers
  • ******
  • *
  • Posts: 857
    • View Profile
Re: The solution to hosting without port forwarding or UPnP
« Reply #4 on: April 12, 2018, 09:45:21 AM »
Lambchops,

Yes I think the game host has to contact the other players first (before they join the game) in order to open that inbound connection. However, the pvpgn server knows the IP of every player already, so what if a script was added to the client where the server sent the game host all IPs of the players, and the client reached out and contacted all the other players periodically to keep ports open to them

Something like that, I'm not really sure how it would work because the ports being opened by the game host to the other players would not be 6112? but if we spend some time learning how this problem has already been solved in other applications like VoIP then we can learn and understand how to hopefully apply it to PvPGN servers

Just look, I think theyve done it with Starcraft Remastered, it is possible I think




There's a discussion of the topic with lots of my thought on it HERE The crux of the matter is:


So in this entire scheme there is only one point at which a UDP transaction is being attempted where one of the clients is 'blind', .i.e. it hasn't been pre-supplied with the other client's address and port. That is when someone first tries to join a game. The joining client obviously knows the host's address, but the host has no clue. Why? Maybe it was by design to reduce server load on the original battle.net servers, idk, but both clients already have an established TCP connection to the server. So why not?

All that needs to happen is: when a client attempts to join a game, it notifies the server (of course over the TCP), and the server in turn notifies the host of the joining client's address and port, which is 6 lousy bytes! (plus standard transport overhead). Then the host just has to send a few UDP packets out to the joining client. That's all.

The packets can be anything. Null packets would probably work fine, whatever, as long as it doesn't crash the client with garbage, its all good. We have then done our “lat trick” between the host and the joining client which is the only one not already being done. End of hosting issues forever. GG.


The idea of having the the server notify each host of ALL the players connected to the server - or in the channel (not just those attempting to join the game) would simplify the process slightly, but doesn't really lessen the required discovery/mods to impliment it.

This approach would probably work in the current environment simply because of the low numbers of players currently using the server but on any larger scale it would be definately inelegant and possibly infeasable to have the host's router constantly holding open entries in its routing table for every available player.

For an implimentation we would have to either:

   (a) run it using the messaging system built in to the pvpgn server which already has a tcp connection to all clients.
           or
   (b) produce and deploy a seperate stand-alone server (could be run from server.war2.ru using an arbitrary unused port)

I much prefer option (a) being the far more elegant solution, although option (b) may possibly be slightly easier to get to a bootstrap level even though it's a bit like adding on a contraption made out of coat-hangers and  gaffer-tape to what is already a convoluted enough system ... and if done properly option (a) doesnt need another server or even any mods to the pvpgn server.

----------------

To do this the way I envisage it we would need to identify and tap the procs that handle the /m messaging to and from the server to use them for notifying the host of the joining players, and also locate and monitor the proc that handles the whole [JOIN] game bit.

I have lately (last month or 2) been pushing to map out the exe in my spare time. All the stuff involving messaging strings I have found so far stores them in temporary stack buffers which are then instantly overwritten with other data as soon as they are displayed, so we would need to hook one of the procs involved in both the send and receive functions.

The host list is quite easy to pull from process memory but we would need to find the and hook the join proc to identify the appropriate game and notify the host.

With unlimited time and resources it's all very simple, but in real terms there's still a way to go yet, but each bit of the exe I discover and notate makes the next part a little bit clearer.... or if anyone else know's where any of these procs are in real terms, let me know and we can out our heads together.

                                                               :critter:




the solutiom is "fuck U"


.... actually that one sounds much easier.... let's do that lol  ;D