BS 1.01A hosting port issue NOT resolved!!!!!

[graywo1fg]

Hi remember me? the annoying little gnat buzzing in your ear eagle dynamics? here is a refresher course. read up.....

 

http://forums.eagle.ru/showthread.php?t=35125&highlight=Hosting+black+shark

 

 

Well guess what! even after Coff's nice words about fixing it. its not..... proof.

 

Look at my Black Shark Server, notice the port?

 

if you cant tell i'm a tad bit frustrated of having a server that can only have a fraction of the people it could have on it because of this issue! i'm always having to baby my freakin server all the time because of it. now how can i help to get this issue RESOLVED for sure??? I know i'm not the only one with this issue, Six Marbles and several other people have this issue. Put me on the beta team if you wish i will gladly help! since I might just be the one wanting it fixed the most and no one on ED has the issue i'm guessing, i can test fixes easily! please contact me ED this issue is the last piece to the stable black shark puzzle!

[Ramstein]

my port still shows the wrong number too. I gave up on reporting it.. I kept asking if the multiplayer problems were adressed in the patch, but it seems everyone must think they were fixed.. and maybe I was the only one with problems..

 

:doh:

[graywo1fg]

you definatly were not the only one Ramstein ;) i asked 2 or 3 times in the patch thread but never got an answer :( but now i know why.

[c0ff]

Seems like the fix did not help :(

I'd look deeper then.

[Panzertard]

graywolf, did it happen running a while - or was it happening when you start it up (appears pretty quickly)?

(I think I read most of your original research some time ago).

 

Reason for me asking is that it would interesting to see some package tarces from your server (from the inside) before you hit the net.

That way it would be possible to eliminate if there's some sort of translate happening before you reach the server browser.

 

But if the issue reoccurs only after a while (or sporadic), then it's quite hard to have Wireshark (or other package sniffing tools) running for that long.

[graywo1fg]

it appeared right away. i would love to run wireshark on the server the only trouble is i'm not quite sure how to use it. is wireshark free?

[Panzertard]

it appeared right away. i would love to run wireshark on the server the only trouble is i'm not quite sure how to use it. is wireshark free?

 

Yes it's free :)

Thing is that you need to understand a bit of network to use. Hm. Maybe I can put together a filter that you can use, and post it here.

Thenn you can use the filter during startup of the server - collect the results, and upload the dump-file somewhere.

 

That ofc only if c0ff thinks it's valuable, unless he already *know* where the problem is and will fix it this time ;)

[Ramstein]

that program is a pain. I ran it on my wired newtork computer, there was no problem. But, I tried to run it on my wireless computer that I run the server on, and it refues to work and gives an error saying something about the adapter..

 

it's just a regular pc connected to my d-link router via an Airlink G model wireless adpater... but it refuses to capture on that computer...

 

and to top that off, Black Shark ran great and I did not get any errors are all while hosting on my server and playing on my other computer..

 

so capturing anything is worthless anyway if my computers will not give errors while running captures..

 

:doh:

[Panzertard]

Sorry Ramstein - I'm not going to argue you, but such a statement is just a tad off - and not helpful at all. Even though you couldnt get it to work, it is actually quite helpful when you understand how the network layers work - and you need to find data about it.

[c0ff]

The patch was only a half of the solution.

The other half - master server - will be updated on Monday.

 

Sorry, I simply forgot about it ;)

[Panzertard]

The patch was only a half of the solution.

The other half - master server - will be updated on Monday.

 

Sorry, I simply forgot about it ;)

Ah, good news indeed :)

[Ramstein]

Sorry Ramstein - I'm not going to argue you, but such a statement is just a tad off - and not helpful at all. Even though you couldnt get it to work, it is actually quite helpful when you understand how the network layers work - and you need to find data about it.

 

 

well I ran captures in the past for another online game player service (a few years ago..) and submitted them to the person who ran it so they could add a game and make it parse data correctly..,,

 

so I figured I would try it to get data for Black Shark.. and see why I sometimes have problems..

 

I should have not even attempted it.. I thought it was going to work as advertised out of the box, yet it gave me problems on one of the two computers.. I wasted my time.. I should have just let the experts try.. and I should have never opened my mouth and said I tried..

:doh:

Edited August 22, 2009 by Ramstein

[SixMarbles]

I have used wireshark pretty extensively to help diagnose this issue and I have determined that the problem resides within the master server's habit of mis-reporting your game server's port. This problem seems to be restricted to servers behind a router, but not all of them. In fact, I have observed this problem on my own PC behind three different routers (Buffalo, Linksys and Actiontec).

 

Running a netstat command with filters for active ports reveals that the host still thinks it's on the port you determine when you set up the server (default 10308 ), and the initial heartbeat packet specifies the correct port in hex, yet when polling your session server from the master server, the wrong port is displayed. Furthermore, the port shown on the server list cycles periodically (only if no clients are connected), making server administration extremely tedious since the admin has to change the port forwarding profile every five minutes or so when noone is connected to the session. Interestingly, as long as there is at least one remote client connected to the session, the port remains the same.

 

The ports shown on the master server list for servers exhibiting this problem typically vary randomly from around 60000 to 64000.

[c0ff]

Hi, SixMarbles.

What you describe is a typical NAT behavior.

BlackShark server sends heartbeat packet every 5 minutes, and NAT (in router) remaps server's port in the outgoing packet to a random one. When NAT detects incoming data on this port (i.e. when there are clients), it pins the port and does not remap it anymore, so the connections will not get broken.

 

To defeat this 'feature' of NAT, all routers I know about, have 'Virtual Server' and/or 'Port Trigger' option. You can use both of them, but 'Virtual Server' is more straightforward and robust. Typically you need to provide IP:port of an internal server and external port number, as well as select the protocol (TCP, UDP or BOTH). For BlackShark (and LockOn) you set both ports (internal and external) to 10308 and select BOTH (TCP+UDP) as a protocol. If you router only allows selecting TCP or UDP, you have to create 2 virtual servers - one for TCP and another one for UDP.

 

I think people hosting BlackShark servers do know about these things and there are some routers which remap outgoing packets even if they originate from a 'virtual-server' port. To get over this problem, in the patch I added port to a heartbeat packet, so master server will store and report this port number, instead of one derived from the incoming address.

 

The update of master server is scheduled on Monday. Sorry for a delay.

[c0ff]

Master server updated.

Please post your experience.

[SixMarbles]

Tentatively the issue appears to have been resolved. Tentatively!

 

Still probing the issue with rigorous testing with the help of Graywo1f.

c0ff, we may buy a plane ticket to Russia and find you, then give you a big sloppy kiss. No promises though, we are still determining what the deal is here.

[graywo1fg]

there was a minor episode of us having no ping the first try but after restarting the BS server and trying again it yes tentatively seems fixed..... testing :)

[bumfire]

Sounds like good news :)

[Quirkitized]

great news if fixed! more people hosting.... :)

[graywo1fg]

just flew for an hour and a half on my server, Marbles and I. great news so far... will check in tomorrow and then if confirmed. Death From Above will once again finally be public!!! :D

[c0ff]

I found one more place in client code where the issue can arise.

So, if for someone problem still persist, please, REPORT(!) and wait till next patch.

Edited August 26, 2009 by c0ff

[graywo1fg]

yea cOff the issue is still there...... my port is randomized again to a 60,000-64000 port, and now now it wont even show on the master server list.... like its blocking anything that isnt 10308....... guess we'll have to wait till next patch. :cry:

Edited August 27, 2009 by graywo1fg

[ZaltysZ]

graywo1fg, in another thread you have said that if you forward port to your gaming rig and try to host, no problem arises. Try this:

 

1)Make sure that DCS is not running on your gaming rig;

2)Forward required port to server and reboot the router;

3)Host the game on server;

4)Ask fellow players to check the server list for announced port of your server.

 

You see, most NATs work in "symmetrical" way. If host behind NAT sends packets with source port X, then NAT translates only IP (internal to external) and leaves the same source port. However, this is correct only with single host. In case of multiple hosts behind a NAT and them all communicating with the same external host and using the same source ports, only the first internal host gets its source ports not translated, source ports of other hosts get translated to random numbers (mostly to 64xxx-65xxx). Looks familiar? Try the steps above.

[c0ff]

The root of the problem is that your NAT remaps outgoing packets even if the originate from a port, owned by 'virtual server'.

 

my port is randomized again to a 60,000-64000 port, and now now it wont even show on the master server list.... like its blocking anything that isnt 10308.

 

No, it's not. Clients just do not receive a reply anymore. Here's why:

1) Your server sends a heartbeat to the master

2) your NAT maps outgoing packet to some random port AND stores the mapping

 

BEFORE the fix:

3) master stores your server address with remapped port number

4) clients get this 'remapped' address and send 'getinfo' request

5) NAT still stores the mapping and map incoming client request to the real server port

6) your server replies

7) NAT reuses the mapping it created in step 2

8] clients get a reply and show your server info (with a phantom port)

 

AFTER the fix:

3) master stores your non-mapped server address

4) clients get non-mapped address and send 'getinfo' request

5) NAT redirects the packet to your server IF you added it's real port to 'Virtual servers'

6) server replies

7) NAT haven't seen a bidirectional flow to mapping created in step 2, it sees the reply just as some random packet and creates a new mapping for it

8] Client shows a server for which it got a reply i.e. your server with a phantom port - close, but no cigar

 

I added port number to serverinfo packet as well, so client in step 8 will show correct server address, not a remapped one.

But this requires changes to the binaries - so till next patch.

Edited August 27, 2009 by c0ff

[Ali Fish]

Majorly dissapointed.

Edited August 27, 2009 by Ali Fish