Jump to content


Photo

cant connect to others


  • Please log in to reply
154 replies to this topic

#151 FReQuEnZy

FReQuEnZy

    ( ͡° ͜ʖ ͡°)

  • Banned
  • PipPipPipPipPipPipPip
  • 7986 posts

Posted 26 January 2017 - 05:56 PM

Some sites have developed a way to get around it. Be careful.



#152 Showtime

Showtime

    Colonel

  • Members
  • PipPipPipPipPipPipPip
  • 7715 posts

Posted 08 February 2017 - 11:38 AM

Something strange happend, i tryed to connect to nb99 in qm cuple of times didnt work.

I made he made didnt work,but when we both hade random color we connected.

Could this be the problem for so many ?



#153 xact

xact

    Seal

  • Members
  • PipPipPipPip
  • 221 posts

Posted 22 May 2017 - 02:06 PM

That's really weird indeed.

But more and more providers put their users behind NAT because of the ipv4 exhaustion. Most of the time you end up behind a "PortRestrictedCone" NAT where the public port doesn't match the source port.

 

If it turns out that Red Alert 2 can't handle such cases then it's a bigger problem. It should be easy to update the server to handle such cases though, from what I know, Red Alert 2 is using random source ports, that means the server actually has to share not only the ip, but also the port of each player.

The server could override the port and share the public port instead.

 

Everything looks like it's all about NAT problems, you guys should at least run a test and paste your results in here. Maybe it's something else, but it's impossible to tell without running tests 

It's not that easy...

Providers use Carrier Grade Nat, you can't just use the opened tcp port as udp port, as the NAT-Device makes the assignement of the ports.

You'd need a udp listener on the server. On connecting, the game must send a connection request to the udp server port, to get the offical udp source port of the client and keep the client/server connection up to use the same port as udp game port again. When the connections between players is done, the dummy connection between server and client can be destroyed.

So you'd have to dll inject game (awwwwh  :crybaby: ) and also in server (easy going).


Edited by xact, 22 May 2017 - 02:08 PM.


#154 FunkyFr3sh

FunkyFr3sh

    Corporal

  • Members
  • PipPip
  • 14 posts

Posted 22 May 2017 - 10:18 PM

It's not that easy...

Providers use Carrier Grade Nat, you can't just use the opened tcp port as udp port, as the NAT-Device makes the assignement of the ports.

You'd need a udp listener on the server. On connecting, the game must send a connection request to the udp server port, to get the offical udp source port of the client and keep the client/server connection up to use the same port as udp game port again. When the connections between players is done, the dummy connection between server and client can be destroyed.

So you'd have to dll inject game (awwwwh  :crybaby: ) and also in server (easy going).

 

Yes, the server must listen on a random UDP port for that and the game needs updates too, it's tricky :D But you have no other choice (except using a VPN, but that's not really a good solution).



#155 xact

xact

    Seal

  • Members
  • PipPipPipPip
  • 221 posts

Posted 23 May 2017 - 10:17 AM

Yes, the server must listen on a random UDP port for that and the game needs updates too, it's tricky :D But you have no other choice (except using a VPN, but that's not really a good solution).

 

Yeah, but there's a way to fix it. I've already tried some scenarios. But it requires multiple manipulation of packets :D.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users