Search the Community

I recently ran across a bizarre problem and I thought others might benefit from what we seem to have found. SYMPTOMS: Our initial "symptom" of the issue was an intermittent problem with various networked HP Laserjet printers (specifically LJ P2055DN, LJ P4015DN) whereby they would lock up, stop processing jobs, not even respond to button presses on the front panel. Remove the network cable and BOOM, the printer would begin responding to button presses, menu navigation, could even print out a configuration page. Plug the network cable back in and BOOM, instantly locked up again. Three different printers, same issue. The lockups would eventually subside on their own, only to happen again at a later date. TROUBLESHOOTING: Tried all of the typical stuff with the printers, thinking they were the root cause. Firmware updates, cold resets, different drivers etc. The problem came and went mysteriously. Once we realized that three separate networked printers on the same VLAN were exhibiting the same strange behavior (albeit sporadically) we began to focus on the network. I began working with one of our network admins who asked me to call him the next time we received a complaint with one of the printers, which I did. He was able to observe that two different systems on the VLAN were spewing an excessive amount of IPv6 multicast listener discovery packets during the printer lockup; I believe he said a rate above 16,000 packets/s originating from two separate boxes on our network. Armed with the IPs of the trouble making boxes, I set out to track them down. I expected to find a compromised system or someone using P2P software, maybe a box with Bonjour going nuts with multicast traffic…something. What I found was that the two systems were both relatively new Dell Optiplex 9020’s installed in classroom podiums. That immediately confused me because our classroom systems are locked down (no end users are administrators, managed patches etc) and the deployment applications are plain vanilla! Ran some scans, used some Sysinternals tools to look for anything malicious and/or chatty that would explain the multicast traffic and came up with ziltch. These systems were clean. The network admin had provided me with charts showing when the traffic spikes took place on both boxes, so I decided to check the Windows eventlogs to see if I could find a correlation between the network activity and a user or application. I was surprised to find with 100% certainty that as far as Windows was concerned, both systems had entered a sleep state for the entire duration of the IPv6 multicast listener discovery packets. It wasn’t even close really, both systems had gone to sleep and remained asleep during the whole thing. A quick google search of "optiplex 9020 sleep multicast" turned up several posts from around the web reporting the exact same behavior. Opti 9020s with Intel I217-LM nics causing network issues - Desktop General Hardware Forum - Desktop - Dell Community Dell Optiplex 9020 blasting "ICMPv6 Multicast Listener Discovery during S1 sleep - Spiceworks The Dell Optiplex 9020 DDOS ICMPv6 Multicast Listener Discovery - [H]ard|Forum CONCLUSION: From what I gathered from reading, Dell Optiplex 9020 systems with the Intel I217-LM NIC with a BIOS revision prior to A05 were exhibiting this strange behavior – randomly flooding the VLAN with IPv6 multicast traffic for a period of time while the systems were in a sleep state. This past summer, we had purchased Optiplex 9020’s to replace all of our classroom podium systems (about 30 in the building that had the printer issues, all on the same VLAN). I can’t yet confirm that upgrading to A05 will correct the problem (just figured this out with the network admin this morning) but others have seen some success. They do mention thought that WOL doesn’t work in A05. SUMMARY: If you’re experiencing unexplained lockups or sluggish performance from networked devices like printers, access points, NAS’s etc, have a network admin check for unexplained IPv6 multicast traffic, especially if you have Dell Optiplex 9020’s (possibly other devices with an Intel I217-LM NIC) on your network with an early BIOS revision as they may be sporadically spewing IPv6 multicast traffic (while in a sleep state) causing adverse effects on other devices.

Hi, I am having a problem which has been ongoing for months and I just cannot sort it. I am using Print Management on my server (running Server2016). When a client prints, the job is sent to the Print Server and then passed out to the printer (Konica Minolta BizHub454). Occasionally (at least 2 or 3 times a week) I will be informed that the printer is not working. On inspection, there will be a long list of jobs in the print queue with the earliest job "stuck". None of the other jobs will even get to the printer so because of one job, the printer is unusable. The way i am fixing this is to stop the Print Spool service and delete the files in the Windows/system32/spool/printers folder. Then re-starting the print spooler clears the queue and all is working again. Trouble is, I work part time and so if the problem happens when I'm not here, it causes chaos. Anyone any ideas what may be causing this and how to cure it?