Ok, so how many people *still* can't connect to the game?

Just so you feel better, Inc, I had no problem connecting.

I can't let you know until after 2000 hrs EDT. Still stuck at work.

Still cannot connect. Someone kindly let me know how to obtain info ya'll require to unFUBAR this?

G5 I mac osX 10.4.6
Absolutely no problems ( Hope this info adds to the overall picture )

Ecka

Still unable to connect...
v1.6.4.2

1G iMac OS X 10.4.6

"Connection to server timed out"

dumping config and wgaf did nothing.

Still timing out...log-in, then "Connecting to server". Then, "Connection to server timed out". [edit 0515hrs - re-downloading and updating from 1.0.6 to 1.6.4.2 did not resolve anything.][edit 2 0525hrs - bypassing the router resolved the problem... going after updated router software.]

build 8I127
MacOS version 1046
This is a Power Macintosh with a G4-7455 processor.
Hardware: (18 11:PPC 7450) PowerMac6,1 @ 999 MHz, 768 MB
[Sun Jun 11 05:39:29 2006] Found driver: "Mac sound driver". Type 1, Version 8.1. Load @0x00644990
[Sun Jun 11 05:39:29 2006] Instantiate address: 0x5d6144
[Sun Jun 11 05:39:29 2006] Found driver: "OpenGL Reference GKGL driver". Type 5, Version 64.0. Load @0x00644b00
[Sun Jun 11 05:39:29 2006] Instantiate address: 0x70e5c8
sound driver initialized.
No joysticks found.
[Sun Jun 11 05:39:40 2006] Flight-Assist mode disabled.
Connection to server timed out

[Sun Jun 11 05:41:09 2006] Connection to server timed out

[refgl]
version=3
illummap=0
envmap=0
bumpmap=0
tc=0
minfilter=9987
maxfilter=34046
specular=1
windowmode=1
textureresolution=1
texturequality=32
gamma=9
def_freq=0
tfactor_hack=0
doshaders=0
dovertexbuffers=1
doindexbuffers=1
do_compiled_vertex_array=1
do_env_combine=1
do_extensions=1
vbl=1

[Vendetta]
version=3
showhelpstring=0
usefontscaling=1
Username=RelayeR
AudioDriver=Mac sound driver
VideoDriver=OpenGL Reference GKGL driver
xres=800
yres=600
bpp=32

RelayeR's issue is the same as mine, though I'm sure we're running different platforms.

I can think of 2 things that might cause that:

1. Might be a DNS issue. As in your router was acting as a DNS forwarder for your computer, but for one reason or another was not getting DNS replies for the server address. Connecting directly to your cable/dsl line would have forced your computer to send DNS queries directly to your ISP's DNS servers.

2. Your router doesn't like Path MTU Discovery or some other tweak to the network code. Path MTU discovery can cause connections to timeout if one or both machines on each end do not accept ICMP "Fragmentation Needed" messages.

<Network Geekery Begins>
Path MTU Discovery works by having the server send as large a packet as possible with the "Do Not Fragment" bit set. If a machine or router along the path cannot handle that size packet, it sends back the "Fragmentation Needed" message, which will cause the server to try smaller packets, unless the ICMP message is dropped somewhere along the line due to a paranoid admin dropping all ICMP messages because "they can give someone too much info about our network". Then the server just retries with the same packet size a few times until it gives up, causing the client at the other end to see "Connection Timed Out" or "Could Not Connect To Server".
<End Network Geekery>

Except that our MTU discovery backs off to smaller sizes, rather than just giving up, but I'm sure Andy will be looking into it.

What's the max MTU packet size?

[edit] enabling MTU with a max packet size of 1500 did nothing.

1518 bytes for ethernet, 9000 bytes with jumbo frames. AFAIK.

If you are on a mac in the UK ( accepted RR isn't ) try setting MTU to 1458 , not the 1500 default . The reason is beyond me but its something to do with BT's ADSL protocols, and routers working in half bridge rather than full bridge mode .

cheers

Ecka

Updating LinkSys firmware and setting the MTU resolved the problem. Give it a try here, Lecter.

Is there anyone else that is still not able to connect since the last update?

Yes, we don't rely on ICMP at all (though if we get it, we do make use of it).

You shouldn't have needed to mess with your MTU, RelayeR. What was it/what did you set it to? Are you using DSL with PPPoE?

The whole point of the stuff I added was to figure out what the lowest MTU is set to between you and us, whatever it happens to be, and once that's figured out, not send any packets bigger than that. So even if there's a misbehaving router somewhere it should work, UNLESS the router thinks there's something fishy about the UDP stream we're setting up and blocks it, which I believe is the issue cocomonster & Menendel are seeing.

It was and still is set at 1500 and I'm on cable with DHCP. I believe the router thought there was something fishy with the change in the UDP stream. I didn't get into changing anything with UDP ports. That would have been something I would have done after updating the firmware. It seems the firmware update made the router forget the change in UDP and took what you were sending as OK.