Show Posts
1411
Mods & Development / Re: Nerd's Corner
« on: March 20, 2017, 12:46:36 PM »RE-PURPOSING COMMON PORTS FOR WC2
Maybe some programmer should change the ports in the files from war2 : instead 6112-6119 make it on a port range which are usually open.
That could help a lot for all !!!
This is a nice idea, but I'm pretty sure it wouldn't work in most cases. There MAY be a solution here for some people, depending on their gear/connection, IMHO it's unlikely, but if you want to try....
The first thing I should point out is that you can already select your game port via the CE installer.
This is the only port you need to worry about (6112 by default).
The 6112-6119 thing is a misnomer which was probably introduced into some docs that were being written at the same time BNE was being written and before they had the final IPX --> UDP conversion sorted out. When you are in a game you may be getting WC2 game packets on a variety of ports, depending on whether any of the other players have changed their default port. THIS DOES NOT MATTER for hosting, it is all taken care of by hole punching. It's only that single game port that is the issue.
RELEVANT STUFF
1) “open” is an over-simplification. Ports are not “open” or “closed”.
2) Routing tables aren't made to assume that there is only one end user connected to them, even if that is all there is. The job they are doing is to try to find the right place to send each packet.
3) What we tend to refer to as “opening” a port is adding a rule to the routing table to tell it to send traffic on that port to a particular place (our WC2 computer).
4) If we can't do that then we need to give the router some kind of hint to let it know we want those packets.
5) Even for common ports, packets are not just forwarded without the router having more information, as per (2) above they still don't know where to send it. The only ports for which this is done are called “Multicast” ports.
MULTICAST:
In theory a router receiving a packet on a multicast port will re-transmit it to all nodes downstream. I'm sure you can all guess what these ports were used for 99% of the time – yes, either spam or hacking. As a result most servers do not re-transmit multicast traffic, they just ditch it without a second thought. So apart from all the other logistical issues there would be with using one of these ports, you can bet if your provider is not letting you add a simple routing rule for one port, there's no way they will be sending you multicast traffic.
SO, USING COMMON “OPEN” PORTS:
Let's use the example of a very common port that handles UDP traffic, port 53, which is the port for DNS. Anything accessing the network using domain names needs to use DNS to translate the name (i.e. server.war2.ru) into an IP address (i.e. 145.233.94.234), which is what the network protocol actually uses.
So a router has 3 computers attached to it, with people using web-browsers. Every time one of the 3 users loads a page, the address of the page (i.e. Forum.war2.ru) will be looked up using a DNS, then the HTML for that page is loaded which might include another 10 embedded items, like images, youtube vids or whatever, that are all hosted on different sites, and the HTML has named addresses in it so an additional DNS lookup may be required for each one of these. But even if the 3 computers are all using the same DNS server, they will all get the correct responses to their queries returned to them (and only them).
How? Well for UDP traffic in general ( DNS is UDP ) the router just keeps track of which computer was the last one to send a packet OUT to a given address on a given port, then when any traffic arrives from that address on that port, it sends it back to that computer – this is where the “hole punching” thing comes in...... but for the case where our 3 users are all simultaneously loading pages with 10-20 DNS lookups each, things would still get messed up.
So, in addition to that, for commonly used ports that are reserved for known protocols like 53, 80 ,443 etc. the LAN router, and/or the relevant local client service will often also be doing some amount of port translation. i.e. The to:/from: port numbers on the packets will be different. DNS servers are usually dedicated to just that single job and will accept requests on a broad range of ports, not just 53. They just check if any incoming traffic on any port is a valid DNS request, then if so, respond to it. So computer A will be talking to the DNS server on port 53:100 and computer B will be using 53:1987 or whatever. i.e. 'A' sends requests with “To Port: 100” and “From Port: 53” then the DNS server will respond with “To Port: 53” and “From Port: 100” so the LAN router will send it back to the correct node, where it will end up on port 53 and go to the correct service (DNS).
So you can see that even for the most commonly used UDP service port: the DNS port #53, in some cases NONE of the external traffic will actually be on port 53, and regardless of that, when some random packet turns up from an unknown address on port 53, even if the local router accepts it as being valid DNS traffic, it still doesn't know if it should be sent to computer 'A', 'B' or 'C', and as I have said, the fact that there may be only one computer connected locally usually does not change this. If the router can't find a valid reason to send a packet to a node, it won't. That's its job.
TRY IF YOU WANT:
So if you want, you can try changing you game port to 21, 25, 53, 80, 123, or 443. Perhaps even 37, 43, 67, 68, 137, 143 or 8080, and just hope that there is some kind of exception built into the upstream routing.
However this approach also requires all other players in a game to be able to reliably send you WC2 data over these ports, and the chances of NOBODY having these ports either A) blocked, B) running on stateful or app-layer firewalls, or C) being controlled by protocol specific daemons, seem fairly remote.
BEST BET:
For the people who are having issues because they are using some kind of mobile service that reduces it's bandwidth by tracking its routing upstream of the end-user, I think your best bet for something that is might possibly “sneak through” and not get butchered by everyone else's firewalls might be one of these:
2195 - Apple Push Notification Service
3689 - iTunes, AirPlay
4488 - Apple WACS
5223 - Apple Push Notification Service
5228 - Google play store, Android cloud messaging
As a wild stab-in-the-dark, I'd try 4488 first.
But this is just if you want to try and hope, I don't really think there is much chance of it working.
**and using an Apple port definitely wouldn't work through an Apple phone, or probably not even if there was an Apple phone connected anywhere on the network.**
... and thank YOU for your testing and reports - that stuff is invaluable. Wish I knew why the GDI+ stuff isn't working though 
oh well... another day.
that would be really tricky.... give it some interesting name that stands out so people want to look at it. hehe.. then OMG they will see my HELLO WORLD MESSAGE! AAARRRRGGHHHH!! 
