Build 276 - A very serious problem

axamdeep

Hi there,

It has been two weeks since the lastest update of your reworked network protocol, as far as I know, accordingly to my observation through our Chinese NS2 community, all Chinese players at the moment are not able to connect to the servers that out of mainland China (e.g. Wooza's, DMD, IBIS, MCG). Players were not able to continue the game as most of them got stuck after they are connected to the server, while a ‘red plug’ is showing on the left of the screen; The rest were even stuck at the state of 'connecting' or 'attempting connection' screen. The weird thing is that it would not happen if players use a VPN with a node that out of China, which was not required or necessary before build 276.

Moreover, a Chinese player who spent $49.99 on a Mega Pack and today was not supposed to deserve the experiences like that. That is not what we expected and hopefully you can fix it ASAP. It is better to make it work as the previous version of network Protocol does.

BTW, a VPN is considerable costly in China, pretty much as the price of the game, no one is going to pay for it(VPN) by monthes if it is just for this game.

IronHorse

Hmm that is odd that a VPN is working around the issue..

We need data in order to resolve this issue for you, such as your techsupport.zip file that is generated by your techsupport.exe located in your NS2 folder.
With your VPN OFF :
Type net_log 1024 in the console (~ key) before joining a server / failing to connect to a server.. and then provide us with either that log.txt file or your techsupport.zip file.

Also, has anyone experiencing these issues attempted to do a trace route to one of these servers' IPs in windows?
With your VPN OFF :
Open command prompt with administrator privileges and type tracert 123.12.34.56 (replace these numbers with an actual server IP of a server you cannot connect to normally)
Then post the results / picture here.

axamdeep

Thanks for the response.

And After Build 277 patch, the ploblem is still existing.

Here is the log:

BabblerKing

These are all corresponding server log snippets.

For yoo I can't discover anything in the server log.

There are far more players affected than have sent in logs.

EDIT: It would help if this wasn't bloody invisible to the poor guy.

IronHorse

Thanks so much for the data!

It appears as if those users have no issue connecting to the server outside of NS2, so the issue is more than likely is isolated to NS2.

The net logs however were not as useful as they could be.. despite net_log 1024 being clearly activated, it did not provide any data.
Could you have one or two of those users try both verbose 3 and net_log 3 this time before connecting? One or two logs in total should be enough.
Hopefully that will capture something


edit: this may or may not be related to the other timeout issue that we are aware of and fixing.

matso

This MAY actually be related to NAT mapping; ie the same problem as described in http://forums.unknownworlds.com/discussion/139293/dropped-off-after-few-seconds-on-every-server-255-ack-problem#latest

If so, try to talk to a server op and see if he can see the telltales for port changing.

That would explain why a VPN would help; a VPN will bypass the errant NAT gateway.

Bw, for net_log purposes:

net_log is a bitmap to turn on various parts of the network logging, so 1024 will just turn on ... hmm... PING_QUAL logging. Not very interesting.


// logging for network is a bitfield
// Some logging requires multiple bits to be set; LOG_TRACE is required to triggers any LogHeaders
#define LOG_TRACE_BIT 0x20

#define LOG_MISC (m_verbose & 0x01)
#define LOG_DET (m_verbose & 0x02)
#define LOG_UREL (m_verbose & 0x04)
#define LOG_UREL_S (m_verbose & 0x08)
#define LOG_REL (m_verbose & 0x10)
#define LOG_TRACE (m_verbose & LOG_TRACE_BIT)
#define LOG_ACK (m_verbose & 0x40)
#define LOG_ANY (m_verbose != 0)

#define LOG_PING (*m_verbose & 0x100)
#define LOG_PING_TRACE (*m_verbose & 0x200)
#define LOG_PING_QUAL (*m_verbose & 0x400)

DET = detail, UREL is unreliable, UREL_S logs when sending, REL reliable stream, TRACE adds tracing for REL/UREL, ACK is for reliable acking and the PING stuff deals with the ping header

If you just want to see what's going on during the connection attempt, use "-1"; it turns on all of them.
Warning: it will log _a lot_

GhoulofGSG9

For anyone not familiar with bit masks and doesn't want to have a super long logs i suggest to use net_log 53 (Misc + UREL + REL + Trace)

Obraxis

I will post the English non-programmer version

CDT are looking into this as a matter of priority and we'll keep you guys informed. Seems the Great Firewall of China also includes NS2 blocking now, but hopefully not for long.

axamdeep

Well, here are some SUPER LONG logs with the console commands above that before joining a 'foriegn' server from us:

verbose 3
net_log 3

After unzip, the total size of files is 27.5 MB.
Hope it useful.

GhoulofGSG9

axamdeep wrote: »

Well, here are some SUPER LONG logs with the console command

verbose 3
net_log 3

from us.
After unzip the file size is 27.5 MB.
Hope it useful.

We "only" need net_log 53 But those logs should be helpful as well but require some filtering.

Edit: Okay your logs fit to our theory that the issue is caused by NAT port re-mapping

IronHorse

@axamdeep

We now have a fix for this that we are going to test tomorrow. Thanks so much for all the comprehensive data!

BabblerKing

Just played on their server. Basically getting what they get when they play on ours.
It's the same mentioned in this post, meaning all high latency connections are affected. Not just china.

Attaching my net_log 53 of it.
It captures two instances of heavy breakage (+ colourful plugs), one at the end of the log.