Hello, Please forgive me if Im a bit imprecise in my terminology, I am new to this arena. Im working with a networked RIP printing software in our University printing lab and we've run into a problem where the software sporadically but consistently fails to connect to the networked epson plotter. The company that produces the software informs me that there must be some sort of network issue or software conflict to prevent the connection, and Im trying to diagnose what that conflict might be. According to the provider, the RIP will ping the printer address 5 times to see if it can connect to the device. The print job itself is sent to the printer via TCP on port 1. In our case, if the software can't connect it throws an error, and only a complete system reboot seems to get things working again. I'd like to know if Wireshark can help me ascertain if the issue Im running into is a problem on the printer side or on the workstation side, and I need something that will help me observe the problem in action as the fault is intermittent. If the issue is on the workstation side, I need to know what else might be operating on tcp port 1 that would prevent communication to the printer (is it possible for an app to hog a port like this?). Failing that I need to figure out if the RIP itself is just locking up and refusing to try again until after a reboot. Also, is Wireshark the best tool for this kind of exploration, perhaps there is something simpler. Im a bit daunted by how feature rich it is, most of which I'm completely ignorant as to what it means/does. This is what I know about the software/environment:
If your at all curious as what other steps I've taken to diagnose the problem read on. Otherwise many thanks for your thoughts. What I've done to narrow down the issue with no success:
asked 07 Feb '14, 05:15  orionrush edited 07 Feb '14, 05:16 |
2 Answers:
TCP port 1 is actually assigned to tcpmux (RFC 1078). But honestly, I have not seen that in any environment in the last 25 years!?! Are you sure it's TCP port 1? If you wan to use Wireshark to analyze the problem, you should try to capture the traffic at both sides (client and printer) at the same time. See the Ethernet Capture Setup Wiki for instructions (switch mirror port, etc.). As soon as you have those two capture files, you can look at them yourself, or you can post the files somewhere (google drive, dropbox, cloudshark) and publish the link here, so we can have a look at them. Hint: If it is really TCP port 1 that's being used, there could be firewall issues as well, as that port is used rather seldom, and although it is possible to open firewall for that port, some firewalls might not be able to handle it correctly, i.e. an IDS/IPS module might believe there is an attack going on and thus it blocks the communication. A Firewall can also be on the client itself in the form of a personal firewall, AV with IDS/IPS capabilities and Endpoint Security Software (Symantec and the like)!! Did you check that? Regards answered 07 Feb '14, 05:30  Kurt Knochner ♦ edited 07 Feb '14, 05:33 |
Troubleshooting intermittent/sporadic problem/issue is never an easy task. The challenge is to catch it when it happens. Before you do anything, what I suggest to do is:
Hint: When capturing the traffic to profile the traffic, I would try to capture all traffic except for broadcast & multicast and then slowly clean up the packet capture and not restrict the capture only to the printers alone. This is to make sure that you check if there is any other process (such as any DNS resolution, etc) that is actually happening at the background which might be related. Just my 2 cents. answered 07 Feb '14, 05:57  hunghoong The more I learn about the process, the more I realise Im probably not the best man for this job. My initial instinct when we moved into the lab was to try to operate everything on my own unmanaged switches, to totally separate from the network to see if there was in fact any wider firewall issues. Our IT folks went a bit nuclear when the subject came up however, so I put the switches on the floor, kicked them to the centre of the room and backed away slowly with hand's raised. . . . I just have to trust them I guess when they tell me that all the restrictions have been lifted for this initial setup. (07 Feb '14, 06:28) orionrush |
I will go back and confirm with colorbyte, but it struck me as odd as well. I've just checked and sure enough in the compiled app there is a tcpmux unix executable. If Im understanding the memo you've linked to, tcpmux seems to be to create a custom service name or alias. Perhaps they are using it so their own printing protocol is not interfered with, or steps on any other services.
We're not using Endpoint, Symantec etc on the boxes themselves, though I do have the standard OSX fire wall in place, with stealth mode enabled. I'll try to disable these to see if there is any improvement. I wouldn't expect theses setting to sometimes work, sometimes not however.
well, then they are probably using really tcp port 1. Why not....
As I said, you need to capture in parallel at the client and in front of the printer (or print server), to figure out what's going wrong.
a system reboot of what exactly? The imageprint system or the networked printer or the print spooler system (if there is one)?
BTW: what is the error message?
The error message is ImagePrint code 527, meaning the print spooler simply couldn't connect to the printer - Not very insightful. As far as a reboot, I should have been more clear, I meant the entire OS. Restarting the GUI for and RIP or its print spooler (these have separate interfaces) dosen't help. This hints to me that there is a process that has been spawned that continues to be locked up after the spooler GUI has been shut down. After the OS reboots you can fire up the RIP and get a few more prints through to the spooler, until it locks up again. Reboot, a few more prints. Reboot a few more prints - all day long. No fun at all!