D-Link Forums
The Graveyard - Products No Longer Supported => Routers / COVR => DIR-655 => Topic started by: steveng57 on September 01, 2008, 02:20:47 PM
-
Doing anything with a remote printer with this version of the firmware is so slow as to be unusable. File copy and a few other things seem to be be a little slower as well.
I had to resort to rolling back to version 1.11 of the firmware. I've seen this briefly mentioned on a few other thread and I have posted a bug to DLink. Does anyone know the status of this problem. It is really quite significant. Printing is a necessity and it really was a troublesome execise when I had to troubleshoot this issue in haste in order to print my boarding passes the other day.
-
Keep in mind that 1.20 is still beta.
I've also upgraded to 1.20 b07 without any problems (A2 hardware, but that seems irrelevenat when looking at the material changes between hardware vesions). I've even flashed back to 1.11 a few times to see if I could reproduce...but no luck (strange way of putting it though ::)).
Issue seems to be depending on certain settings. Perhaps a good idea to post them in order to compare...
-
Same problem here. Oddly, my XP clients work okay, it's the Vista ones that have the problem with 1.20. But it goes away if I revert to 1.11.
-
The remote resources being accessed are on Vista and Windows Servers (2008 and 2003/WHS) and they all seem to suffer from the problem to some degree or other. I have a shared printer on Vista and another on Windows Server 2008 and they are both so slow as to be unusable.
I have A2 of the hardware. Nothing all that funky about how I have it configurd.
- WPA2 personal for security
- Wireless N and G only (B is disabled)
- set to 20/40 automatic.
The delays happen whether over wired or wireless connections.
-
It seems that most of the problems have been with Vista and Server. I am wondering if this may have something to do with IPv6 being enabled on those machines. I am running Vista (ethernet connection) with a network printer hooked into one of the lan ports of the router and it has no issues printing. I have unchecked the IPv6 in the NIC card properties on this machine since the router doesn't do IPv6. Have been running the 1.20 since it first came out in the betas and have never had an issue printing or transfering files between machines.
-
My problem free PC uses Vista Ultimate, my laptop Vista Premium Home. Both have no issues whatsoever. Both have IPv6 working...
-
Keep in mind that 1.20 is still beta.
I've also upgraded to 1.20 b07 without any problems (A2 hardware, but that seems irrelevenat when looking at the material changes between hardware vesions). I've even flashed back to 1.11 a few times to see if I could reproduce...but no luck (strange way of putting it though ::)).
Issue seems to be depending on certain settings. Perhaps a good idea to post them in order to compare...
1.20 is on the public DLink download site as the current build foir this router, so it doesn't appear to be beta. I have exactly the same printer problem as reported here, whereas everything was running fine with 1.11. If it isn't resolved soon, I will need to revert to 1.11.
My config, as far as it's relevant, is an HP printer USB-connected to an HP EX475 Windows Home Server ans shared out; other computers on the network are Vista Ultimate, and now takes ages to do anything at all with the shared printer; in 1.11, it was as near as instantaneous. I have not yet tried disabling IPv6, but will do so now. I doubt that it will have an impact.
(update 5 minutes later: I disabled IPv6, and it made absolutely no difference)
-
I certainly looks like the 1.20 is out of Beta. It is on the general download site with no special markings or indicators.
Also, by the preponderance of people with issues here, I don't think that hails of "it works for me" are all that helpful. While they might provide insight that there are circumstances that the propblem doesn't occur, the volume of those having issues would certainly indicate that this issue is broad and needs addressing. If there is something that you all that have printing working with 120 and Vista and all that you are doing differently than the rest of us that you could share, maybe we can help DLink isolate the problem.
I used to be a big fan of DLink, but moved away from them about 2 years back because of bugs in their firmware. I came back because I read good reviews about this product, but now am begiinng to regret my decision. I've only had this thing about 2 months and already need to run to forums for help. Linksys isn't perfect, but I never had these challenges with them. This is a pretty common scenario to have troubel with. Printing is still used by most.
-
I totally agree with adamde. The moment I revert my firmware from 1.20 to 1.11 I got my shared printer worked very well. I had to call HP technical department to help me out with my printer on a network but none worked. I did lots of settings and downloaded many programs but none helped.
Thanks to adamde and I really appreciate it.
To, DLink technical support : Do something with firmware 1.20 it needs to be fixed.
-
I totally agree with adamde. The moment I revert my firmware from 1.20 to 1.11 I got my shared printer worked very well. I had to call HP technical department to help me out with my printer on a network but none worked. I did lots of settings and downloaded many programs but none helped.
Thanks to adamde and I really appreciate it.
To, DLink technical support : Do something with firmware 1.20 it needs to be fixed.
Looking at the forum I have a feeling D-link already knows...1.11 works quite good so there's no use pushing them, is there?
-
Has anyone tried the 1.21 beta that was just released in the "beta code" section to see if it resolves this problem? There are no release notes.
-
Again these are beta firmware still going to have bugs. Coding still going on by the engineers so you may or may not have issues but beta still a bump or two. 1.11 is were most users are at now.
-
Still, give it a shot and give us feed back.
-
Does anyone know if this has been fixed with version 1.21? my experience with 1.20 was pretty bad and don't want a repeat of that...
-
Following up on this thread --
I just yesterday came across this. I'd been trying to figure out what had happened to our printer's network response time for months -- unfortunately the firmware upgrade happened at the same time as a lot of other changes, including a few changes to settings, and so I never suspected the DIR-655 as the culprit (and when going back to factory default settings didn't fix the problem, I assumed it was Vista being stupid).
However, now that I've downgraded to the 1.11 firmware again, the printer responds as quickly over the network as it does on the machine it's directly plugged into. Prior to downgrading, it took several minutes to open up the print settings window, and several more to actually print the document. Nothing else was affected -- file sharing with the print server, for example, was lightning fast.
I was running the latest firmware prior to this; and I had tried going through every set of options in the router and changing them, to see if I had changed a setting that could affect the printer speed. None of the changes helped -- I'm still hoping that D-Link will fix this issue in their next release, but seeing now that they didn't address it between September 01st and the later release of 1.21 doesn't exactly fill me with confidence or optimism.
-
You probably need to seek for other causes of the delayed printing. Since 1.21 there have not been many (none?) complaints about this. For myself, I have no problems or delays using my two printers (HP deskjet and Samsung Laser). You might want to reflash 1.21 and do a clean setup.
-
SYNOPSIS
With 1.21 it takes a long while for the printer's dialog box to appear when printing from the client computer. Then it takes a long while to begin printing. Once the operation successfully begins, it completes at normal speed.
- DIR-655 at default settings
- Connected (regardless if wired or wireless), any recent default-installed DHCP-served Windows computer capable of Microsoft Networking acting as a Printer server (may affect file serving in a similar way).
- Connected (regardless if wired or wireless), any recent default-installed DHCP-served Windows computer capable of Microsoft Networking acting as client.
NOTICE: I am not experiencing this problem, but I think I realize one or two things that might be coming together to affect this. I am not from D-Link, so follow the rule of Internet Help -- If you try this and it breaks everything, neither myself nor anyone else is responsible!
If I'm right, this problem is actually caused by a behavior of Microsoft Networking that, in some cases, tries to locate LAN resources using a DNS query. This behavior is appropriate in some configurations not popular on simple home networks, but is not appropriate when the DNS server is a public one. Causing the delay being seen by some is a bug in DNS Relay in 1.2x firmwares that causes a long delay any time a DNS query fails.
SUGGESTION
Will those affected please try the following:
1. Disable Setup - Network Settings - DNS Relay
2. Disable Advanced - QOS Engine - Automatic Uplink Speed.
3. On the same page, set the appropriate Manual Uplink Speed for your ISP.
4. Power off/Power on to reboot the DIR-655.
5. Ensure your computers are configured to accept DHCP assignments. Or, if they are static-addressed, configure your DNS servers to match the DNS servers displayed on the DIR-655 Status - Device Info - WAN screen.
6. Reboot all client machines in your network.
Does this improve the problem? If so, then the broken DNS Relay feature in 1.2x firmware was causing the delay -- but the strange thing is that DNS should not be consulted at all in this case! These machines are all on your LAN. So, if you saw the delay, then a misconfiguration in your systems is causing the WAN's DNS to be consulted.
If you continue to operate with this misconfiguration, you are probably making DNS queries that reveal the existence and names of your local machines to points outside of your LAN. This is more of a resource waste than a serious security concern, but for both reasons you should address it. Furthermore, if your ISP's DNS server is one that always sends you to a page with advertising or helpful search information if you mistype a web-page name, a WAN DNS query to find a LAN machine will seem successful, and that false success will prevent machines on your local network from ever finding one another.
To correct the root cause of that problem in most home networks (networks without WINS servers or LAN-side DNS servers):
1. Under DIR-655 Setup - Network Settings - DHCP Server Settings, choose NetBIOS Node Type: Broadcast Only
2. Ensure your computers are configured to accept DHCP assignments, and/or follow step 3.
3. Most users can skip this entire step as they get their IP addresses and other configuration automatically from DHCP, but if steps 1 & 2 alone did not help, or any of your computers are (a) individually manually configured for static-addressing (you will likely know), or (b) someone has already forced your machine to be a particular Microsoft Networking NodeType, or (c) you have a particular bug (KB938248) involving DHCP client privileges, then you must manually configure that computer for correct operation. This is done by modifying the Registry as described in http://support.microsoft.com/kb/314053/ -- this change is both safe and reversible.
1. Click Start, type regedit in the Start Search box, and then press ENTER.
2. Locate and then click the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\Parameters
3. If the Value "NodeType" appears, skip to step 5.
4. On the Edit menu, point to New, and then click DWORD Value. Type NodeType, and then press ENTER.
5. Right-click NodeType, and then click Modify.
6. In the Value data box, type the desired value, and then click OK.
Note: To use Broadcast name resolution, set this value to 1.
7. Exit Registry Editor.
8. Restart the machine.
(Should you ever want to reverse these changes, simply follow the above steps but change the NodeType back to the previous value -- or to restore the default behavior of obtaining the NodeType from DHCP, delete the entire NodeType key.)
4. Even if you performed these steps, you should keep DNS Relay and WAN automatic uplink speed detection disabled for now as these settings relate to known reported bugs in 1.21 which are awaiting fixes.
-
Great synopsis, funchord.
-
Funchords -- yes, this DID eliminate the delay in printing under v1.21 firmware, so that's almost certainly the culprit here. For the time being, I'm going to stick with the v1.11 firmware anyway -- I've had to change the DHCP settings a couple of times for remote networking, and I'm happier sticking with a firmware flash I know I can use or change without being concerned about the consequences too much (I confess to laziness here, pure and simple -- I like things to be as easy as I can make them).
Fortunately, the changes from 1.11 to 1.2x don't seem to have affect my networking much anyway, so stepping back hasn't caused any problems for me. It's nice to know what was causing the problem though, so thanks for the reply -- I'll be keeping an eye on the DNS Relay bug to see when it's resolved, and adding one more item to my Reasons Why Vista Is [take your pick of an insult] list. Vista isn't the biggest mistake I've made in the last five years, but it's probably the most annoying one.
-
Funchords -- yes, this DID eliminate the delay in printing under v1.21 firmware, so that's almost certainly the culprit here.
Awesome -- great to have confirmation.
ATTN: D-Link -- here's one more reason this bug needs to be fixed.
-
Thanks for sharing all this info, Funchords. So often we discover a quick workaround without actually tracking down the root cause, and it helps to have a deeper understanding of the issue.
Unfortunately, my initial Google search missed your post and I've wasted hours with D-Link Tech Support via both email and the phone. Of course, they professed no knowledge of this problem until I pointed them to this thread.
I've been a software developer for almost 20 years, and I'm still amazed at the lack of communication between tech support and the product development teams. Admittedly, they're probably located at opposite sides of the globe, but I wish they could sync up on hot issues like this quicker.