Print

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

[FurryNutz]

Always go directly to the web site for FW updates. For some reason, using the routers FW update checker doesn't work or the servers are not correctly identifying whats being requested.

It's possible this could be a compatibility issue with your ISP Modem, have seen some Fiber issues with this routers. Possible FW issue to:
v1.10 is most resent.

This router at a home or business? If at a business I would recommend getting into a different model router for business. These low end 6 Series routers are good however generally designed for mom and pop email and surfing at home.

If you really wanna, Do the FW update and follow the FW update process outlined in the FW Update sticky.

Keep us posted.

[dpartrid]

The 1.10 revision is for the 615 and mine is the 601.  I checked the website for 601 and there, it shows 1.02NA as the current.  I'm tempted to try 1.01NA and see if the problem occurs there, too.  But I'm not sure if it's advisable or even possible.  Thoughts?

This is a "home" implementation... but I use my home office to work from on many occasions.

My impression is that most web browsing and such opens tcp connections, uses them, then closes them, so they don't have to remain open when idle.  So I can see how this problem might not manifest itself for many people.  However, I rely on some applications that form a TCP connection and leave it up and often idle for a while, then wants to use them again.  Having those silently "killed" by the 601 is dramatically slowing me down.

Ironically, this 601 is replacing a 7 year old ZyXel which only cost me $5 after rebate.  It never gave me any problems until the day it burnt out (10 days ago).  ZyXel certainly doesn't have the reputation of Dlink, and some of it's features weren't as nice... but at least it let me have idle tcp connections.

[FurryNutz]

Opps I got my links crossed, sorry bout that.

Possible that you can down grade and see if it will let you. Not sure if it will. It might as I don't think there is a major version between these two, only minor. Can give it a go.

Follow the FW update sticky process.

I can understand the frustrations of working with this router however I'm wondering after you mention that what your doing at home and needing these services to remain open is somewhat beyond the scope and design of this router. I'm curious if something better like a DGL-4500 would serve you better. I have this router, a DIR-825, DIR-655 and a DIR-657 routers. From my experience so far, they were great for general use and gaming. I also have a roommate who VPNs into work when needed and haven't had any issues. However I'm not sure what kind of open services besides gaming that I can relate to your services that you need.

Any thing you can elate here to help us understand what you are doing with this router? What applications are you using that you need these services to be open all the time? Will help us understand some.

It's possible that there is a better fit router out there that will handle your needs and probably this one just might not be suited for your needs at this time. I would try

Maybe someone can review your router settings with you using teamviewer.

[dpartrid]

Two apps which I use a lot and are effected are Novell Groupwise (email) and Novell Messenger (chat). Both of these form TCP connections to a server and then (depending on whether I'm actively used them) they may sit idle for a time.  If the connection is no longer available when they want to do work again, they "stall" while trying / retrying the dead connection.  Or in chat, other people may see me as "online" but then they try to reach me and I never get it.  To them I'm just not responding.  Those applications can recover eventually, but in the meantime I'm frequently delayed for 30 to 60 seconds. Often the whole windows desktop stalls while these are trying to recover, too.

Another example is FTP for file transfers.  FTP sessions use one TCP connection for "control" (commands) and when you transfer a file, it opens a second TCP "data connection" for that purpose.  If you are transfering a file which takes more than 60 seconds, the data connection is okay (as it is not idle) but the control connection gets killed by the DIR601 because it is idle until the data connection finishes its job.

While I understand that this is a "bottom line" router, this is fundamental communication.  And even the router's doc claims it will allow established connections to be idle for 7800 seconds before terminating them.  I'm only seeking capability for which the router is supposedly designed.  Within a few days I will either have DLINK authorize a replacement or I will return it to the store and go another way.

I just reread the above. It kind sounds like I'm ranting or something.  I'm not... this is just intended to relate facts and what my plans are.  No hard feelings, and I thank you FN for taking time to respond.

[FurryNutz]

Hey frustration is understood man and can relate.

Novell is pretty high end business application and I would presume that these routers would probably not fit your needs when using Novell man. Not sure if even the DGL-4500 or DIR-825 could as I've never used Novell with a home end router before. It's always been corporate business class routers for that.

I would recommend, if you have the time and if you want to, try the DGL-4500, DIR-825 or DIR-655. The only diff between the 825 and 655 is that the 655 doesn't have 5Ghz radio. The DGL-4500 has both however you can only run either or radios, not both at the same time. I currently have all 3 and enjoy them greatly. However I don't use Novell so really not sure if either one of these routers would work. I can ask some resources and see what DLink might recommend using for Novell applications. They might have something.

Let me know.

[salahx]

I've been going over the source code (Ironic that the source code is packaged in the proprietary RAR Format). Its based on a 2.6.15 kernel, which is over 5 years old. Netfilter has since been completely revamped and the source looks totally different to what it did then...

However back then the TCP timeout stuff should be in net/ipv4/netfilter/ip_conntrack_proto_tcp.c. A quick glance shows ip_ct_tcp_timeout_established is set to 5 days. Those timeout are stored in a structure array tcp_timeouts which is only reference in 1 place in that file, on line 1069. tcp_timeouts[3] is 5 days, but the one right above it ip_ct_tcp_timeout_syn_recv IS 60 seconds (which is consistent with what we've been seeing), which makes me thing there might be an off-by-one error.  The router does seem to be properly transitioning states correctly (according http://192.168.0.1/internet_sessions.asp) However the state machine here is pretty complicated, i need to study it for a few hours....

This also explains why no 6rd support - 6rd support wasn't added until Linux 2.6.33.

[salahx]

Viola, I found it! Turns out it not a kernel bug at all. Back then, there's a sysctl to change the nat timeout

Took the source code, and running "strings Matrix/projects/DIR-615WW_E4/apps/rc/firewall.o" I see the folowing:

echo "2048" > /proc/sys/net/ipv4/ip_conntrack_max
echo "1024 65000" > /proc/sys/net/ipv4/ip_local_port_range
echo "65" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo 50 > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo "60" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 5 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 3 > /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore

The offending line is in BOLD. The documentation the router states the following Support->Status->Internet Sessions

Time Out
The number of seconds of idle time until the router considers the session terminated. The initial value of Time Out depends on the type and state of the connection.

300 seconds
   UDP connections.
240 seconds
    Reset or closed TCP connections. The connection does not close instantly so that lingering packets can pass or the connection can be re-established.
7800 seconds
    Established TCP connections.


So it SHOULD state:
echo "7800" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo "300" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo "240" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close

Some of those other values look suspicious as well. These are the default values:

echo -n "256" > /proc/sys/net/ipv4/ip_conntrack_max ( 1/16384 of RAM / (sizeof struct list_head) * 8 - the the dir-615, 32 MB (33554432 bytes) of ram, struct list_head is 2 pointers, on this arch, that's 8 bytes) so 33554432 / 16384 /8 * 8
echo -n "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo -n "600" > /proc/sys/net/ipv4/netfilter/ip_conntrack_generic_timeout
echo -n "432000" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo -n "10" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo -n "60" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo -n "120" > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo -n "30" > /proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout

2048 seems about right for  ip_conntrack_max, no comment on the others.

[dpartrid]

Excellent research, salahx.  By the way, I see that the strings you found also show:
echo "65" > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

And I have noticed that most (but not all) of my udp traffic seems to result in a 65 second timeout in the same Status > Internet Sessions screen that I was watching my TCP timeouts.  So that point matches up exactly with my experience, too.

I had talked with DLINK support over the phone... they were stumped and thought I had a defective unit, and offered a replacement.  I had my doubts that this was a one-unit glitch (it seemed very programatic), but was willing to try anyway.  However, they failed to send me the email (or maybe they failed to correct my address, which I told them was slightly off when they read it back to me).  So I was not able to arrange for a replacement and eventually returned this DIR601 to the store and got a Belkin N150 instead.  The Belkin doesn't have as many bells and whistles in the administration menus (no status screen showing my connections, and no way to reserve certain DHCP assignments for certain MAC addresses), but it works great with idle TCP connections.  And my wireless seems faster.  I've been using it a week and have only seen one problem, one time (which isn't necessarily the router's fault... not sure):  It had assigned an address to one of my wired desktops, supposedly with a "forever" lease, but a day later when I woke up that desktop it had a IP conflict with another desktop which somehow had obtained the same address.  So for anything where I need a truly permanent assignment, I'm configuring statically at the PC, outside of the DHCP range.