Our 2330dn has recently decided not to communicate with anyone outside of it's local network. It used to work just fine. It is connected as a wired ethernet printer (not wireless).
This is a local network (192.168.3.30) connected to our corporate office with a VPN. This past Monday the servers in the corporate office were no longer able to print to the local 2330dn printer.
Printing from a computer in the same subnet as the printer works fine. We can also open the web interface from a computer in the local subnet.
Printing from a computer in the remote network does not work. We can still print from the remote network to other printers on the local network. We cannot print or open the web interface or ping this particular 2330dn from the remote network. Using wireshark (and a non-switching hub) we can see that the requests from the remote network reach the 2330dn and that it is just not responding to them. We tried changing the IP address of the 2330dn, but still had no success.
From the network settings page:
The TCP/IP Settings:
The IPv6 settings
On TCP/IP page of the web interface for the printer, the box for Restricted Server List just has a bunch of commas (,,,,,,,,,) in it.
Any help or insight into why this particular printer is now being so selective in who it communicates with would be appreciated.
Thanks for the reset instructions. Yes, they reset the printer but it still was snobbish and refused to communicate with the remote office.
Thank you incredibly much for the comment about SNMP. The community name was still public, there were no traps set, the Enabled, Allow SNMP Set, and Enable PPM Mlib options were all set.
I disabled SNMP and the printer began communicating properly. I can't think of anything I need from the SNMP interface on the printer, so I'll just leave it turned off and be happy until something else goes errant.
Since the printer performs correctly on your local network and did work from the remote network..... and just stopped recently..... I'd say you need to point your finger at the corporate entity and see what changed there and at that time.
But to verify, was anything done in your locale before the stoppage? Updates? New s/w? anything?
BTW..... excellent info provided in your post. I've got a good network background, but I'm gonna pass this on to a colleague of mine who's a network guru. He might see something I've missed.
Thanks for the reply.
I'm pretty sure it's a printer issue. We unplugged the 2330dn and temporarily replaced it with an older 1700n. We gave the 1700n the same IP address and netmask that was being used by the 2300dn and had no problems reaching the 1700dn. We could use telnet to connect to both ports 80 (the setup web pages) and 9100 (the printer printing port).
When we unplugged the 1700n and plugged the 2330dn back in we were again unable to get the printer to respond to any traffic from the remote network.
I'm just hoping that there's someone from Dell that's seen this before and has a scripted answer or possibly someone that can tell me how to reset the printer network stack to the factory settings. The printer reset to defaults option doesn't seem to affect the network settings.
But, it's still under a long warranty so I'll be on the phone to Dell later this week if the solution doesn't appear to me soon.
To reset the factory defaults for the 2330dn, follow this procedure:1. Power off the printer2. Press and hold the "check" and "right" buttons while powering on the printer. CONTINUE to HOLD these buttons until the memory config is displayed, then you can release.
You are now in the "Configuration Menu"3. Press the "right" button until Factory Defaults is displayed, then press the "check" button.4. Using the "right" or "left" buttons, select Restore Base (Base Printer defaults) or Restore STD Net (Standard Network port defaults), then press the "check" button.
The printer will pause, then display "Submitting Changes", then restart.
I always recommend printing a Configuration setting page both before and after so you can compare settings.
BTW..... has anyone fooled with the SNMP names? I've seen some pretty weird things happen if these are changed.
Go figure..... Anyway, glad it's working now.
I thought I would make this my first post as we have spent an inordinate amount of time on this issue.
To tie the solution down even further, I will explain the background. Same issue, same setup, can print to the printer on the local network but not from a remote network via the VPN. This was working fine for the first month or so of installation but recently has been very up and down and looked like a dodgy network config or a device on the network with conflicting IPs as we use a separate DHCP server on the local LAN and the remote LAN ...
I managed to visit the site and move all the equipment off onto another subnet as my colleague was convinced this would solve the issue. We did, it did not resolve the issue. In addition, a "tracert" to this printer from the remote lan to the local lan identified another device which seemed to route successfully to another printer on the local lan (Dell 1720dn) but not the 2330dn. This made me think it was this device but we identified it as one end of the VPN tunnel. After following your advice and disabling SNMP on the 2330dn, resetting the Print Server, this did not solve the problem.
The only other change I thought I would try was to disable IPv6 autoconfiguration. The factory defaults were DHCP for both IPv4 and IPv6. A recent replacement router has been installed at the far end, This added another factor into the mix.
Turning off IPv6 auto config sorted this issue out for our configuration but I think the issue only showed when we replaced the router with an IPv6 capable device at the far end.
My thoughts, for what they are worth but we are sorted now and hope that this article helps troubleshoot a similar configuration.
Great Comments !!
So, in essence, disabling IPV6 at the printer "contributed" to resolving this issue?(I've encountered anecdotal evidence of this also having unpredictable consequences with other customers as well)
Are you able to put the original router back in place to find out if the problem is still resolved?
Cheers for that ... Always good to get feedback !
We are unable to replace the router with the old one as it was causing loads of issues and this being a live customer network, it is probably not a good idea. Although I am convinced it had something to do with the new router going in and causing a few headaches, network wise, potentially IPv6 related.
The reason I say this is that they have another remote site which doesn't have any issues. They are using the same Vigor router but an older model with older firmware (which I don't think supports IPv6).
Hope this helps