double.

If this was working for any of you at some point, I wonder if you have an old IP stored in your DNS cache from when they were doing all the work on NAT facilitation. Give this command (either in cmd.exe or Start->Run) a try:

ipconfig /flushdns

Really, I don't see how you can consistently not connect to a server that others have no problems connecting to. Either there's something happening with outgoing UDP connections being blocked, or you're not hitting the right server (which the above command might address--I have my doubts).

I wonder how many of you have a certain kind of AV software that would block this for some godawful reason. Other possibilities include a misunderstanding of what is between you and the internet: for instance, there are many DSL modems that also serve as routers, which can throw a wrench in the works.

So let's be helpful: what is your broadband modem model, router model, and security software product/version? Obviously I don't work for Stardock, but I do fix network problems for a living and would love to help. This NAT facilitator connection problem has piqued my interest.

Here's the thing: UDP packets are not inherently reliable, and judging by somewhat inconsistent connection problems between peers as well as the facilitator, no reliability has been built on top of the UDP packets. If your speed is underperforming, this is often indicative of a lossy connection--most of the speeds you see are from downloads that are conducted over TCP which slows down every time a packet is lost, but the transfer will almost always succeed regardless.

With UDP, the lossy slowness can actually translate into this not working at all (I'm looking at some of you guys that get dropped connections after an initial success, or even those days where it seemed to work fine). This is just scratching the surface, too.

A good way to test this is to do the following at the command prompt (type cmd at Start->Run):

ping -t google.com

This will send ICMP packets (which are subject to the same loss rate as UDP, because it is not reliable either) to a google server which should always accept ICMP. Whenever you see "Request timed out" that ping was dropped. Let it do this for a while (like 20-30 mins) and hit Ctrl+C. It should display the loss rate. Even if you're getting a 5-10% loss, you're probably in trouble.

Also, try IP passthrough WITHOUT a router. You may have done this, just want to check. That would narrow it down to ISP/physical connection issues or software problems.

 

edit: by the way, port 6000 you see in the logs is the facilitator's server port. You won't see it in TCPview.

UDP is unreliable, however, the use of Raknet as their UDP library is suppose to ensure reliability (a lost packet is re-submitted), this is one of Raknet's primary features.

Router: DG384v4

I haven't tested today yet, I'm at work still, however since my last post, I've not been getting this error anymore. I did have this error since release when running my router in "Router" mode (NAT enabled) and using it as a gateway, BUT NOT when dialing out the PPPoE connection from my PC.

I honestly cannot say for certain if it was caused by my router, my ISP or Demigod, because quite frankly I messed around with it so much. I can say now, that I am back to my original setup. 6120-6140 specified in impulsereactoroptions, 6120-6140 forwarded to my PC and direct connect is working.

There are a few things I can say for certain though:

1. The ports were forwarded correctly.
2. A firewall was NOT blocking demigod traffic.
3. Regardless of whether the ports were forwarded correctly or not, I should have been able to connect to the facilitator, its an outbound connection, not an inbound one.
4. The router itself was not blocking the packets, confirmed by setting up a log rule in the router.

I suspect, specifically for me, that it may have been a syncing issue between my router and ISP, since there were one or two other internet applications not behaving correctly, which have now also been resolved.

@ShunKeets

Thanks for the response. Definitely enlightening to have the UDP/TCP difference explained a bit better. At least as far as it applies here. 

I'll test his line for loss today. I spent a while living there and never noticed it, and I'd habitually do ping google.com -t's for a few hours just to see how hard I could push it while torrenting before we'd get sketchy with the rest of our stuff. I never actually noted any lossyness on the connection to speak of, but if even a minor number is a big deal, I might notice now that I know better.

As for IP passthrough without routing. I think I might try switching out his modem for my older model. That being the case, I'm still not sure there's any way to be certain these things aren't doing some crumby built-in routing stuff. I get the impression they only wanted to give the option of doing IP passthrough to another router so that, if you're only using the modem, You'll be guaranteed to have something between you and the internet at large. Honestly, the interface is so clunky, I'm never quite sure what's going on. DD-WRT spoiled me.

 

Thanks again for the awesome comprehensive reply ShunKeets.

 

Sorry, my reply wasn't directly to you; it seems that your case is somewhat unique. If there is an SPI function on your router, disabling it might fix this. The problem is that you want the router to assume that if you've opened an outbound connection to a host, the inbound traffic on that connection should pass through the firewall unhindered. This isn't always the case.

I actually had a hunch that it had something to do with the traffic getting blocked on its way back into your network because of a subtlety in the logs:

ID_CONNECTION_ATTEMPT_FAILED from 209.124.63.249:6000

... which indeed makes a lot of sense, because there really isn't a good reason for outgoing connections to ever be blocked by your typical SOHO routers (which is partially why this is so puzzling).

A good way to troubleshoot this would be to try the port triggeriing function on your firewall. Set it up so that if you connect out to 6000/udp, it opens UDP ports to your system from 10000-65535. Not exactly a permanent solution, especially if you have a bunch of other systems on your network using UDP, but again for troubleshooting purposes it would confirm the inbound channel blockage and maybe even be a temporary fix. You could probably narrow-down that port range, but I'm really not sure how low it goes.

As for UDP reliability, I read SOMEWHERE in the RakNet manual that there wasn't reliability during some phase of the connection. During gameplay, I hope there would be loss detection and retransmit, but that doesn't necessarily need to be the case durring connection establishment. It looks like it does retry a few times if there was a failure, so it's reasonable to assume that it is suceptible to loss, although I'm not committed to putting all my eggs in that basket.

my router doesn't even have a "SPI Function" to begin with I've disabled the router Firewall, but that isn't an SPI Firewall - i guess.

On the other hand I cannot change what the router opens, to my system. I can only change which ports the router forwards directly. So if I open Port 6000 the router should open port 6000 TCP and UDP. I'm using a Zyxel Prestige 660HW-67 Firmware V3.40(QD.8).

Also,  why did it work before?

 

 edit:

I've changed my router to "modem mode" that means my router is working as a DSL modem only. I started the game, custom games, klicked join, and voila - i got in. However, that means only one pc can connect to the internet via PPPoE and that isn't a good solution for me. so my "router" (router mode) must somehow block incoming udp connections, right? But why did PfPortchecker from portforward.com say: "Your Port is open!" .. WTF? Is there some way to check that? It's an older router - so that maybe the reason - but I never had any problems with it.

 

Potentially, yes. The router would have to inspect (SPI = stateful packet inspection) the packets to determine how they're fragmented. A false positive for that attack on the Demigod/Impulse packets would definitely cause this. That said, I haven't really looked at a trace of the game's traffic to see if it could possibly be considered an attack, but if someone reports that it has been detected as such, it may very well be that others would detect it that way. I have to admit, this is kind of a stretch, but it seems stretching is required at this point. A good analogy would be the differential diagnoses on the show House 

Try enabling SIP ALG. Also, are you in SUA or Full-featured mode when you aren't in modem-only? SUA may work better for you. This said, it's really not clear that they allow you to forward UDP, given there isn't an option. Still, I think others have had some luck with this router line if they get the settings just right.
 

Couldn't tell you, unless it has something to do with implementation of session initiation protocol application layer gateway (SIP ALG) in new patches. Again, I wish I had the time to look at some traces. Trying to finish school without getting too distracted here.

Unsurprising--at least you've successfully narrowed the issue. You may want to invest a small amount of money in a decent router to use for connection sharing and keep that thing in modem-only mode. There may be other complications to doing this; it may be worth it, though. Realize I'm hesitant to recommend you buying something else especially if it's just going to cause you more problems, time, and money. But on the other hand, from what I can tell, routing on that thing blows.

I'm starting to feel more and more that dropped connections are dropped on purpose by the firewall when they see something they don't like. What is your router, desktop security software?

I am just asking because I thought may be this time, my Router (behind the Modemrouter of my ISP) is the culprit, since it runs SPI. It's a WRT54GL and I recently flashed it with Tomato, where you can't disable the SPI firewall, so I couldn't check it that quickly. When I get to vienna again on Sunday, I'll try the direct connection again and see if it changes anything.

Still, I think Stardock shouldn't be leaving a system like that, that could potentially trigger a "hacking alert" in a Firewall.

 

Anyway, there is a new ImpulseReactor.dll that everyone should try that has a NAT facilitator error. I can't test it before Sunday though.

SPI firewalls are inherently bad for gaming. The inspection process is slow, which introduces extra latency and even if you can connect with it enabled, it will likely cause lag spikes in bigger games, 4v4 + 5v5.

Not only that, may router has an option in its WAN configuration, "Disable Port Scan and DOS Protection". If I DO NOT disable "Port Scan and DOS Protection" and I play almost any game (TF2, Left4Dead, Warcraft III, Starcraft, Demigod) the router flags thousands of packets in the router log as DOS attack attempts and drops them, resulting in massive lag spikes in these games (5-30 seconds).

Ofcourse, all these issues are totally bypassed connecting via PPPoE from your PC as opposed to using your routers NAT and letting your OS and a software firewall handle all these issues. For many people, including myself, this is not a permanent solution though. My ISP only allows 1 connection on my internet account, meaning only 1 PC can be on the net at a time, solved by letting my router act as a gateway (NAT).

IMO, router manufacturers are still pretty retarded when it comes to making games oriented routers. Security features always get in the way of gaming.

Ok, I've managed to break through. Resetting modem and removing all traces of packet routing did the trick, I was even able to carefully apply some routing back (i.e. like ports for torrent for other computers in my lan).

 

However, other "nice" problems like "desync" window and insanely high ping spikes (see http://forums.demigodthegame.com/352130) are still there.

I'd say that given a hard choice between a modem and Demigod, the choice will be "modem".

If some shitty network code can't do it on my equipment, then the blame lies on the code, not on equipment. ESPECIALLY given the fact that the same code worked quite decently (if not very fast) before the patch.

 

1Mbit/s down, 512Kbit/s up. Now go on and say "your connection is too shitty to play this godly game properly".