Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[GullyFoyle]

To be clear Torrent and gaming (possibly anything with many pc's web browsing) freeze may be caused by NAT table overflow. That does not mean every freeze with a router is caused by the overflow. Obviously there are a number of reasons including user error that may be the culprit. But based on my personal experience this looks to be the problem with my dir-655.
As I said I had a similar problem with a Linksys wrt54gl. Even after installing DDWRT it continued to happen. But raising the NAT table and lowering the release time solved it.
NAT table overflow is a common enough problem with routers.

[mackworth]

To be clear Torrent and gaming (possibly anything with many pc's web browsing) freeze may be caused by NAT table overflow. That does not mean every freeze with a router is caused by the overflow. Obviously there are a number of reasons including user error that may be the culprit. But based on my personal experience this looks to be the problem with my dir-655.
As I said I had a similar problem with a Linksys wrt54gl. Even after installing DDWRT it continued to happen. But raising the NAT table and lowering the release time solved it.
NAT table overflow is a common enough problem with routers.

What about the issues with DNS Relay?  How would the NAT overflow relate to turning of DNS relay?

[GullyFoyle]

http://www.dslreports.com/forum/remark,14316664

On certain specific D-Link router models that I have experience with (and probably others) there are known problems with the DNS cache implementation.

The DSL-604+ has a DNS caching feature called 'Proxy DNS'. There is a known problem where the memory allocated to the cache fills with DNS name resolutions, causing the router to 'hang'. The solution (with official instructions published by D-Link) is to disable Proxy DNS and configure the router's DHCP server to hand out the IP addresses of the ISP's DNS servers directly.

This problem is also present on other router products based on the GlobespanVirata Helium communications processor running ATMOS (the DSL-500 and DSL-504) so whether it is an inherent problem with that version of ATMOS or with specific D-Link firmware routines I do not know.

The line of products is now at 'end of life' so I don't expect it to ever be properly fixed.

The DSL-G604T has a similar problem with its 'DNS Relay' feature - again, the solution is to disable it and hand out explicit DNS server addresses. The same problem is also present on other T-series router products. Since these are based on embedded Linux running on the MIPS cpu within the TI AR7 communications processor, I suspect it's not an inherent problem, but a configuration issue.

This line of products is current, so if it's a configuration issue it will probably be fixed in later firmware. But there are already fairly tight memory constraints (see later) and the latest firmware with ADSL2+ support and additional features only makes the constraints worse...

In all cases I suspect the underlying cause is lack of physical memory. There is insufficient RAM available to allocate to a large cache, and also insufficient memory to run comprehensive error checking code with proper bounds checking and techniques such as the use of 'high water marks' so that cache entries are discarded as memory fills.

Let me rephrase that: the underlying cause is that these devices are designed and built to a very tight budget, and memory and other component counts are reduced to the absolute minimum to keep the cost down.

As far as performance improvement is concerned, successful DNS caching may shave 1 or 2 ms off a DNS request.

Sounds a lot like NAT table overflow.

http://www.dslreports.com/faq/11909

How can I prevent problems when using eMule P2P software? (#11909)
   
There are several issues that might occur when using eMule P2P software and some routers (including some D-Link routers). Although we have seen several firmware releases that attempt to address eMule problems, they seem to persist and become frequent issues in the forum.

The most frequent behaviors related to overloading are spontaneous reboots, gradually reduced performance, or a non-responsive router:

      •When KAD is used, the NAT table overflows and the router reboots. While some users have reported various improvements using various firmware versions, there is no certain cure except for not using KAD.

      •Under normal use, the router slows, locks, or reboots. You may turn off the router's DNS Relay feature, which on later firmware versions is located on the "Home / LAN" configuration page.

      •When there are hundreds of connections, the router slows or reboots. You may configure eMule to maintain fewer simultaneous connections.

DSLReports treats the problem as two separate issues. If DNS relay has a slow release time that may be what causes the problem. Either way the descriptions of NAT Table Overflow and DNS Relay caching filling with DNS resolutions on the surface look to be of similar nature.

http://www.broadbandreports.com/forum/remark,12342091~start=20

KAD works by using UDP to transfer eMule information instead of TCP connections.

When the connections are TCP, the NAT table can open, track, and close the connection -- even if there are many of them simultaneously.

However, UDP is connectionless. The NAT table basically has to hold the entry for a while and then close it after some (undetermined) timeout. The timeout has to be long enough to avoid shutting down active communication. There is no way to know when communication is over.

As a consequence, it seems that the NAT table just builds and overflows with open UDP entries coming from everywhere.

There are many routers that exhibit this behavior, and many that do not -- and, no, I don't know the solution. But after reading up on this problem today, I thought I'd share what I've learned.
--

If this is true then UDP is the culprit.
Then again
http://www.broadbandreports.com/forum/remark,12342091~start=40

The story goes that since UDP is connectionless, the NAT table fills up and each of these UDP connections has to time out.

I'm beginning to have my doubts about that theory. Scree's handy NATLIST.TXT reader / Connection Monitor is showing me that some TCP connections actually hang around in the NATLIST longer than the UDP connections.

http://www.broadbandreports.com/forum/remark,12342091~start=60

Yep, I think the UDP theory is difficult to accept. I also found (not using eMule, but with other connections) that the NAT table does not hold UDP connections for a long time nor does it accumulate to anywhere close to maximum.

http://www.broadbandreports.com/forum/remark,12342091~start=60

Sounds like there might be a solution in finding some way to reduce the amount of time that the router 'holds' onto a UDP connection. This thread has a bit to say about this - »forum.emule-project.net/lofivers···687.html - but my DI-624+ doesn't have this option. Sounds like firmware update time with a few new options.

Back to release time changing is a fix.

Someone made a D-link connection monitor.
http://www.broadbandreports.com/forum/remark,12608281

[mackworth]

That sounds like a different issue, an issue with DNS cache versus the nat table.

AFAIK although no final word has been given, the DNS relay in the dir-655 doesn't have caching.  I am still convinced the issue has to do with their "fix" for DNS relay.  If this same problem happened on 1.22B05 as reported on the page before, it makes all the sense since this is the (released/unreleased)first version that they had the fix.

[GullyFoyle]

That sounds like a different issue, an issue with DNS cache versus the nat table.

AFAIK although no final word has been given, the DNS relay in the dir-655 doesn't have caching.  I am still convinced the issue has to do with their "fix" for DNS relay.  If this same problem happened on 1.22B05 as reported on the page before, it makes all the sense since this is the (released/unreleased)first version that they had the fix.

No. It looks like both have excessive release times. Lowering that should stop the problem.

[barich]

The 1.32 beta does not fix this problem, just in case anyone was curious.

I really wish I could downgrade to 1.21, because, though it had some bugs, at least it could stay up for more than a few days.

[GullyFoyle]

The 1.32 beta does not fix this problem, just in case anyone was curious.

I really wish I could downgrade to 1.21, because, though it had some bugs, at least it could stay up for more than a few days.

I'm not crashing that frequently. I do crash when there are lots of seeds/peers, or when there is some strange combination of tweaked Firefox and Utorrent.
As I said I've seen similar crashes with my Linksys router.
I'm assuming in your case it is something else.
Do you have anything listed in Event viewer? Is your OS up to date? Have you modified your services and "tweaked" the os?
I see a lot of posts here blaming the firmware but relatively few state what hardware is running/what os and updates are running/if registry has been modified/if a firewall is operating/what antivirus and antispyware is running/what activities happened just before the crash and if duplicating those creates another crash. Basically I see very little regarding user error.
With the case of NAT overflow I'm only familiar because it has happened to me before. So when it happens now I know what application or combination causes it.
If it happens randomly I would then remove everything and slowly start adding first to a single pc, if that works fine I would follow the same procedure with others. You need to eliminate any possible potential conflict to find a solution.
DNS relay and NAT table overflow seem to have the same cause with overlong release time. There is no setting to change that.
I may be wrong.
Still it is always best to start with user error as the first cause. Once that is ruled out, and user error covers every aspect of incompatibility with both hardware and software not just incompetence, then move onto other areas. I've had cards and devices that play well with one pc but not another. I've had av .dlls block net access after the software had been removed and they remained hidden. Only the slow and steady approach of eliminating each and every foreseeable device/service/driver lead to a fix.
Sure it takes hours or days or even weeks to sort out any failure/incompatibility. Sure it is a pain in the ass. But it is the only way to be absolutely certain.

[barich]

I have a ton of stuff on my network, so it's really hard to troubleshoot what the problem might be if something on my network is causing problems with the router (2 Vista laptops, 2 XP laptops, 2 Vista desktops, 1 XP desktop, 1 Windows Home Server, 2 Vonage boxes and one each of a TiVo, PS3, Wii, HD-DVD player, Slingbox, and a LAN printer).  I simply can't disconnect all of those but one device for testing purposes, especially not for the entirety of the few days the router stays up at a time without freezing, first of all I work from home and need at least two PCs and the Vonage boxes at all times.

However, the router worked (mostly) fine with the older firmware.  I haven't tried disabling DNS relay, which I am going to do, but I shouldn't have to.  It should just work.  The only settings I've changed from the defaults are changing the SSID and enabling WPA2 security.  This router has easily been the most problematic that I've owned (and there have been several), but I've put up with it because of the excellent QoS features and performance.  I've been hoping that something will come along from a company other than D-Link with similar capabilities, but not yet.

[lotacus]

I'm going to go sifting through the code once more to see if there is a NAT table that is hidden somewhere that can be accesses vie the web gui.

[mackworth]

I'm not crashing that frequently. I do crash when there are lots of seeds/peers, or when there is some strange combination of tweaked Firefox and Utorrent.
As I said I've seen similar crashes with my Linksys router.
I'm assuming in your case it is something else.
Do you have anything listed in Event viewer? Is your OS up to date? Have you modified your services and "tweaked" the os?
I see a lot of posts here blaming the firmware but relatively few state what hardware is running/what os and updates are running/if registry has been modified/if a firewall is operating/what antivirus and antispyware is running/what activities happened just before the crash and if duplicating those creates another crash. Basically I see very little regarding user error.
With the case of NAT overflow I'm only familiar because it has happened to me before. So when it happens now I know what application or combination causes it.
If it happens randomly I would then remove everything and slowly start adding first to a single pc, if that works fine I would follow the same procedure with others. You need to eliminate any possible potential conflict to find a solution.
DNS relay and NAT table overflow seem to have the same cause with overlong release time. There is no setting to change that.
I may be wrong.
Still it is always best to start with user error as the first cause. Once that is ruled out, and user error covers every aspect of incompatibility with both hardware and software not just incompetence, then move onto other areas. I've had cards and devices that play well with one pc but not another. I've had av .dlls block net access after the software had been removed and they remained hidden. Only the slow and steady approach of eliminating each and every foreseeable device/service/driver lead to a fix.
Sure it takes hours or days or even weeks to sort out any failure/incompatibility. Sure it is a pain in the ass. But it is the only way to be absolutely certain.

People are blaming the firmware because this issue didn't occur with 1.21 and started in 1.22B05 and 1.31.  Both of these releases fix an issue with "DNS Slowdown" that was in 1.21 and subsequently fixed in 1.22B05.  Thats why 1.22B05 was released, to fix DNS relay as I remember.  It makes that this fix was bad since if you turn off DNS relay, it works correctly.

And since DNS relay isn't caching (as far as I know), there is no point in using it. Yes you shouldn't have to turn it off to get a working router, but you also aren't gaining anything either by having it on.

Why everyone isn't hitting this issue, I have no idea.  But I do know a lot of people are.  If we look at what we know:

This problem started in 1.22B05
The only solution that has worked for people with this issue is to turn off DNS relay
This problem also happens in firmware 1.11 of the DIR-825
This happens on all revisions

So we can come up with all the issues we think it is, Nat overflow, DNS caching,  but only dlink has the source code unfortunately.  As a software engineer, I would love to look at it myself, but we can't.

[GullyFoyle]

However, the router worked (mostly) fine with the older firmware.  I haven't tried disabling DNS relay, which I am going to do, but I shouldn't have to.  It should just work.  The only settings I've changed from the defaults are changing the SSID and enabling WPA2 security.  This router has easily been the most problematic that I've owned (and there have been several), but I've put up with it because of the excellent QoS features and performance.  I've been hoping that something will come along from a company other than D-Link with similar capabilities, but not yet.

Why should it just work? That is a dangerous assumption. I remember XP updates that would screw the system.
Things have bugs.
I've also has issues with security. I keep it off and go with invisible ssid. Security will slow down a connection. I may play with MAC filtering to only allow a limited amount of devices.

"And since DNS relay isn't caching (as far as I know)"
Why would it not?
http://www.dslreports.com/forum/r22013702-Help-Me-DIR655-DNS-Relay

When you have the DNS Relay option enabled, the router acts as a DNS caching server; meaning instead of all DNS requests being sent straight to your ISP, the router makes the request on your behalf and than caches the response it received from the ISP. When you go to the same website you accessed before it doesn't have to contact the IPS dns server because it already has the information in its cache, making DNS resolution faster.

Has anyone tried keeping DNS relay on but turning off DNS cache in the os?

[mackworth]

"And since DNS relay isn't caching (as far as I know)"
Why would it not?

There was a thread here a couple weaks ago and someone said that it wasn't caching.  The documentation isn't clear but it doesn't mention caching.  I had assumed that this was true since dlink had replaced the name of its DNS Cache feature to DNSRelay in its new models.

I could be wrong, but the points above still holds true.

[Demonized]

There was a thread here a couple weaks ago and someone said that it wasn't caching.  The documentation isn't clear but it doesn't mention caching.  I had assumed that this was true since dlink had replaced the name of its DNS Cache feature to DNSRelay in its new models.

I could be wrong, but the points above still holds true.

Can confim that it does no caching what so ever. It does exectly what it's name says: relaying DNS

[GullyFoyle]

There was a thread here a couple weaks ago and someone said that it wasn't caching.  The documentation isn't clear but it doesn't mention caching.  I had assumed that this was true since dlink had replaced the name of its DNS Cache feature to DNSRelay in its new models.

I could be wrong, but the points above still holds true.

So does the fact that it may not be releasing fast enough.
D-link doesn't look to be responding. Others think it caches. Just because D-link changed the term doesn't mean it doesn't cache. Enhanced Interrogation technique is still Torture despite the fancy name.
Right now it doesn't seem to work. Turn it off. If D-link screwed it up they should simply remove it.
But even with it off I still occasionally get what looks to be NAT overflow.
DNS relay is not the cause of that.
If we had access to NAT settings we could experiment and see if it solves the problem.
Instead I have to reboot.
Or maybe it interferes with the OS DNS cache service. I had an XP machine I had to keep the service off on otherwise it would freeze my net access.
This thread keeps repeating the same accusations with no new information or perspective. If someone can explain just why the router freezes, weak cpu and memory for example, or why DNS relay fails maybe then it becomes a cornerstone to work from.
My assumption is release times are screwed up or NAT table isn't large enough most likely both. When D-link disproves that and offers their own explanation I may move on. But I don't really trust any company to be honest about defects in their product.

[GullyFoyle]

Can confim that it does no caching what so ever. It does exectly what it's name says: relaying DNS

Ok, how?
Are you a D-link employee? If so why change the service title from "cache" to "relay"?
Did D-link merely turn off the cache? Wouldn't that create other issues?
Not trying to be rude but owning this router and upgrading firmware entitles me to ask those questions. And everyone should ask as many and as thorough questions as possible.
Thanks.