Print

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

[EddieZ]

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.

[funchords]

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.

[EddieZ]

Great synopsis, funchord.

[DoctorJest]

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]

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.

[Magendanz]

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.