ET: Connection problem or between maps - blaming ISP

(darko) #1

Hello guys,

I run ET 2.60 on Linux (but my son has a Windows based machine on same LAN and symptoms are same) and since 6 months ago I started having problems connecting to game Enemy Territory servers. It coincided with my ISP’s major network upgrade. Here are details:

  1. Connection starts normally, handshake occures and client goes up to “Awaiting gamestate” stage.

  2. At this time in console I can see that evenbalance has been contacted and master server has been sent a request etc.

3a) In some cases it will take another 1 minute or so till I actually get on server, although from another console I can run qstat and confirm that I am all the time connected to server with ping 999.

3b) In other cases I never get to play and simply reconnect after 10-15 minutes of waiting. Same applies - in another console I can see that I am connected to server and my name recognized etc…

  1. While in process of waiting i can ping server just fine, with low responses (less than 100ms) and traceroute shows up fine too. From time to time traceroute gets stuck a bit on some node but nothing too much out of the ordinary.

  2. Reconnecting several times usually helps.

  3. Even if I sucessfully play the game and map finishes, the switchover to the next map sometimes never occurs. I can see some of scripts are loaded, people appear like they have joined the game (the new map) but the graphics belongs to the old map and if I move my mouse around everythign gets smeared. The last ‘live’ thing I get from, the new map is “FIGHT” sound. In console I can see a bunch of lines saying “playerXYZ entered the game” and as well a message saying that the XY seconds old status was loaded. At this point I can again run qstat to see myself present on server with ping 999.

My interent connection is 4Mbit, with only cable provider on a small Island of Malta and they do have a history of lamenes, inadequately trained staff and restrictions of everything and anything in hope of cutting on damned file sharers. I had to actually apply for a business connection to be treated a bit better. Many times before I pointed to them mistakes or iregularities but this time there’s nothing I could bring as an argument that the problem is on their side.

Talk about arguments, I ran a tcpdump/ethereal while connecting to server. I forgot the exact look of traffic (can repeat and send log if needed) but after what seemed as initiated handshake (connection and then both client and server send their commands), I started seeing a client sending bunch (like 6-7) of requests on various Q3 ports, followed by a packet from server. Then again a bunch of requests on various Q3 ports followed by server’s packet. That would go on and on. I am not a network wizrd but UDP is hardly complicated. To me it looks as if packets are being dropped ‘en route’ and a poor server simply repeats his request for client to continue registration or whatever the stage it is in.

I have been explainig this so many times that it became a routine and I probably forgot to mention something. So please forgive me if there are missing details that should have been obviously included in description of problem and kindly ask me to provide them.

Please help me find the source of the problem and potentially way to resolution.

(darko) #2

Ah right, forgot to mention that usually there is almost no internet traffic other than the ET related and that problem does seem to be somehow related to time of the day, although not 100%. Usually after midnight I have much less problems as well as during the morning hours (I was recently ill and stayed two weeks at home). But it’s not a rule, unfortunantly problem does show up then too, but seldom. Also, this happens when connecting to many differnet servers in different countries and running different ET modules.

(mortis) #3

Have you tried deleting servercache.dat? I’ve had that file go bad and cause otherwise normally running systems to lock up for no particular reason when loading the server browser or occasionally on connect.

(SCDS_reyalP) #4

Packet loss can cause that kind of connection issue. Do you see red spikes in the lagometer when you play ?

(darko) #5

@ mortis:
Nothing locks up - it just doesn’t establish connection in full, and never any problems with server browser. However, I did not delete servercache.dat. I may try later.

@ SCDS_reyaIP
Yes, red spikes are always present but, like, 5-6 of them at any particular momment - not more. Sometimes, rarely, I do have almost a flat red bar but then connection does go bad and ping is huge (over 200ms)

(SCDS_reyalP) #6

darko, this means your problem is packet loss. If you see 5-6 of them on the lagometer at any given time, this is quite bad, and will cause you to have problems connecting as well. Most likely, the problem lies with your ISP. Call them and complain.

edit:
It could also be cause by problems with your local hardware, for example, router, network cards or cables. If you normally use wireless, try using a wired connection instead.

You can do some diagnostics with tracert and ping. To do this, open a command prompt, and type


tracert <ip.of.some.server>

this should give you a list of IPs and ping times, starting with the one closest to you (either your router, or your ISPs equipment). You can tell which IPs are related to stuff inside your house, as they will tend to be < 10ms. Chances are, anything else will be > 10 ms.

Once you have that, run ping starting with the first ip from the tracert. You should use a command like


ping -n 100 -l 1000 <ip>

-n 100 says to try 100 times. -l 1000 says to use 1000 byte packets. Larger packets are more likely to show errors.
If the ping finishes with no packet loss, move on to the next IP.

In this way, you can find where the packets are being lost.

edit #2:
bleh, the above are options windows. The equivalent in linux is
traceroute <ip> and ping -c 100 -s 1000

the fact that both computers on your lan show the same problem suggest it is either your router or your ISP.

(darko) #7

Thanks for your kind reply.

I have been running traceroute, ping and analyzing packets with tcpdump/ethereal since day one. My suspicion indeed is the packet loss but I have problem proving it. Being UDP, how would one even know that packets are getting lost - that’s the whole point of UDP. You bring interesting point with lagometer though. Are you sure red spikes are lost packets? I thought it represents the network lattency. Game itself could know packets are lost because it surely possesses some kind of control mechanism but third party would have trouble establishing that. Perhaps a member of Splash would be so kind to provide input to this too?

In the meantime, I’ll try your suggestion of poking every node on route.

(mortis) #8

Packet fragmentation due to and inefficient MTU size might be to blame as well.

If you try the tweak test here: http://www.broadbandreports.com/tweaks it may give you some more insight as to what is going on with your connection.

(SCDS_reyalP) #9

Red spikes are lost packets (missing snapshots actually, which implies receive loss. The game doesn’t directly show if you have send loss). As you say, the game knows when it is missing packets.
see http://wolfwiki.anime.net/index.php/Lagometer

FWIW, I’ve seen a lot of cases where the default ping packet size doesn’t show any loss, but large (but less than MTU) ones do.

If you are using a NAT device (aka “broadband router”) you might try bypassing that. Some cheap routers are known to have problems with the high volume of UDP traffic that FPS games generate.

(mortis) #10

Broadbandreports.com also has a “line quality test” where you can check ping, “big ping”, and overall packet loss. I’m thinking that you are referring to ‘big ping’ when you are talking about packets that are larger than ICMP default size. P2P programs, spyware, or any other bandwidth parasites can also cause tremendous packet loss. I have found that even clean systems need their receive window size and MTUs adjusted to obtain obtimal performance.

(SCDS_reyalP) #11

The TCP window stuff will have absolutely no effect on UDP game traffic. MTU should almost always be ethernet standard, or the slightly smaller one that goes with PPPoE.

P2P stuff and malware can certainly cause packet loss.

(mortis) #12

True, some routers I notice try to fix MTU at 1500, I disable MTU size on the router and set 1492 on my machines at home because I use router PPPoE to connect. This make my connection smooth as silk.

Receive window settings only seem to help to optimize redirect download speeds and smooth usage under heavy bandwidth load. Might as use all bandwidth tweaks, methinks.

Packet loss with some ISPs is horrible no matter what you do. Another thing I do is manually set my DNS servers in my router config, using the servers that are located as close as possible to my home.

reyalP and I will be opening a support center in the SF Bay Area, where for a moderate fee, we will tell you the meaning of life. :wink:

(darko) #13

First off, I run no sharing, p2p, or whatever else. Morever, this is Linux system so unlikely that I have any kind of virus/trojan/whatnot else (I guess I would recognize it after so many years of computing).

But now that you’ve pointed out that red spikes are lost packets and I have so many of them things are getting the shape. See, for some reason, my ISP has a no download limit between midnight and 6AM - and in my book, that reason is only a consquence of upstream provider charging much lower in that period. And guess what - after midnight there’s no red spikes!

So, although I don’t have a hard proof in hand that points to their misconfiguration or anything - I now DO have what would be called ‘circumstancial’ evidence in the form of midnight changeover. Thanks again for your kind input - I hope my next post here will contain some good news!

(darko) #14

Bah, this is the next post but not the one I meant to post. Just to clarify what I meant earlier - I suspect my ISP having their bw capped during the day so to not exceed XYZ amount of bandwith (cash), so Cable&Wireless (uplink) routers are dropping packets accordingly. Come midnight, the cap is gone and so are problems.

(inf3rno.hungary) #15

Wow and I thought I have a bad gaming experience with ET and my ISP. I have just this: https://www.youtube.com/watch?v=ApxrdZadb8k and ofc the hitbox is totally out of sync too ever since 2008 when I went to a different ISP for higher bandwidth (30 vs 500 Mbps). It feels like as if they would buffer small packets and send out a “mega” packet somewhere on the network, so my game stays out of sync for several milliseconds. They halved my accuracy with this and even my nades don’t hit properly. Is there anything one can do in these cases? Did you manage to solve your problem?