No longer working for me.  It wasn't perfect before, but I could at least connect after trying several times.

double.

I've had this error since the monday patch, error continues with this patch.  It worked fine originally.

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.

@ShunKeets

I don't have access to my buddy's computer right now, but he's been having this same exact sort of problem since day one.

He's got 3Mbps Verizon DSL, ends up really only performing at about 180 kb/s down, 40-50 kb/s up.

His modem IS an annoying modem/router, a Westell 6100 I believe.

I completely reinstalled windows to be sure it wasn't a software problem (this guy has such bad luck about that stuff and needed it anyway.) Disabled UAC completely. Full Admin. No windows firewalls.

The modem is typically working in a sort of pass through mode where its own routing features are disabled so his Netgear can handle PPPoE and all the routing. I got that properly configured. Disabled SPI stuff. DMZ'd. Manually forwarded ALL ports even. It was kind of bizarre in TCPView. When I DMZ'd, it just seemed to result in a connection failure to the NAT Facilitator. When I manually forwarded all ports to his computer, it started trying to make connections at random 5 digit ports from 20000 up to 65000, still with no results.

 

  Figuring his shitty old netgear might be the problem (not sure what make/model. At least 4 years old though. Not even wifi equipped.) I unplugged it completely and reverted to direct connection through modem. Disabled the built in filtering and forwarded ports as best as I could within the limited interface. Nothing happened. Couldn't get into any games that way either.

 

Having exhausted all of my options and certain it's not Verizon blocking his stuff as I have the same ISP and am local, and can play, I figured the only difference that could possibly remain is my older Westell 2200 having less built in routing to muck it all up.

 

 

Still, I'm at a total loss, and he's completely disinterested in debugging for me by proxy over AIM at this point.

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.

No longer working. It can't get past "Waiting to connect to" stage, even if it shows player names fine. After a bit of waiting - see topic name.

 

PS: For those helping hands out there. Yes, it perfectly worked yesterday. No, I didn't change network/NAT/Firewall/whatever configurations. Yes, I *did* apply a patch, 0114 in that case. Yes, it worked before the latest patch and isn't working after it.

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.

It's not that simple, at least in my case. As already said, I can connect to the NAT facilitator, but lose the connection right after and then get the "Cannot connect to a NAT facilitator" error. This was the state before the May 7th patch. After the May 7th patch it worked. I have been told that they throttled down the traffic being sent from their server to the users. This seems to have fixed it for me. It seems that Stardock's server is sending too many UDP packets too fast. Either my router or my ISP doesn't like that. A friend's firewall even identified this as an opentear attack!

They removed the throttling with yesterday's patch and now it doesn't work again. Though it's now a bit different than before. I can connect to the NAT facilitator and even receive data after that. I can see connection information and can also connect to one or two players. But then the connection is lost again and I get the "Cannot connect to a NAT facilitator" error.

CariElf said, that they will reduce the amount of information that is being sent via the server and additionally they will do something with the RakNet process. Hopefully this will fix it again. If it were up to me, they should simply put the throttling back in, but they do not want that, since it slows down the connection process.

 

The evening update of yesterday's patch didn't change anything.

 

The problem is not with outgoing packets, but with the incoming packets.

Yes, I already narrowed it down to that.

@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.

 

since the new update i've got the same error as spooky has, again.... . I tried your ping -t google.com and I have no packet loss at all. (0%).

It was nearly working for me, but after thursday it hit ground zero. I can now only see "waiting for connection", I can see people who are connected and then I get the error: Cannot connect to NAT faciliator. Ports are forwarded, I tested that with the PFPortChecker from portforward.com.

here is my impulseractor.log :

 

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.

Ah, hang on, is spamming (fragmented?) UDP packets (apparently something called an "opentear attack"), like the Stardock server does, something that would be detected and blocked by an SPI Firewall?

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.

 

That "too many UDP packets at once" issue explains all that. If your modem is in bridge mode, then everything (read: packets) is sorted by OS, and it seems that Windows can handle this. If your modem is in router mode - *some* (there're a lot of ppl who CAN connect) modems is stuck.

 

BUT, it worked pretty decently during 5/11 - 5/14 period. Sure, it was probably slower than now - but I guess "something for everyone" is better than "good for some, nothing to others" attitude.

 

PS: Just for the sake of sharing info, here's excerpt from a custom game try my ImpulseReactor.log (they're all like this one):

Successful connection at first (and always only one) - then suddenly it's just lost/failed.

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 :P

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?

First of all, I really appreciate your help.

I forward the ports in the so called "SUA"-Mode. Then I've found a interesting article: http://www.voip-info.org/wiki/view/Routers+SIP+ALG

Zyxel

Models: 660 family comes with SIP ALG enabed by default.
NAT type: symmetrical
Issues:

• No incoming calls.
• SIP protocol broken making 50% of outgoing calls impossible because the wrong values are inserted into SIP headers.

So at least i want to try disabling that SIP ALG. Perhaps that is the issue here. But then there is some "telnet" em. well, I never had anything to do with telnet so perhaps you or someone else can tell me what I have to do, to disable it?

 Edit:

I guess I somehow figured it out and disabled it. Unfortunately it didn't work.

 

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.

I'm going to go ahead and try the new file, however, I certainly do not have a "low end system."  So I don't know if it is aimed at me or not...It is the error I get though so might as well.

 

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.

Zyxel P-660-T1 for a modem <--> unmanageable switch <--> PC. No firewalls of any kind (windows firewall is usually enabled, but it really doesn't matter even if I turn it off).

 

Same here, with the same modem. Guess it isn't for us.

 

I certainly don't have a "low-end machine", and the .dll don't do anything visible.

 

Update: oh, another log with some classic issues:

Namely, "GetPlayerDataByID: 47463 not found" and "Attempt to connect to player 47463 was not made because local client is not connected to host"

Indeed, it seems that it can't get any good data from NAT facilitator (while still getting initial query). And upon second try, "CVP: Refresh Login called" connection gets terminated.

 

PS: My previous log was from a 1/X game (i.e. only host there) - in that case there IS some connection attempts between me and that lone player. However, in any other case it's just like the one above.

PPS: This log is with that .dll for "low-end machines".

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.

It's pretty weird that there seems to be at least a couple people that get disconnected during the refresh login transaction. What could be so different about it with the first login? Perhaps you're supposed to disconnect, but you just failed to reconnect. If there is a disconnect and reconnect during that transaction, it could be that the routing table on your device is too slow or it gets confused. Either way, it's clearly a piece of shit. At least we've identified some hardware that will only be trouble with Demigod.

As I mentioned before, I'm sure you can get a decent router to replace that switch and keep that modem/router just doing its modem duties.

Oh jeez. What speed is your connection?

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".

just_dont_do_it: Its obviously not your connection speed, which SHOULD be fine in 5v5s, but definatly should give you no problems in 2v2-4v4.

The only thing I've ever experienced similar to that, was when my router had "Port Scan and DOS Protection" enabled. It was blocking many game packets, incorrectly identifying them as DOS attack attempts. This was in a wide range of games.