The Xerox 7232 color laser printer we’re leasing at work has a very vague problem causing communication failures all the time. When you boot it, it works fine. After a while it starts getting slow. And if you wait even longer, it doesn’t work at all anymore. This happens within a few minutes.
The problem seems to occur faster when you print from certain machines on the network. However, given enough time, none of them work anymore. The machines are a mix of Windows 2000 and Windows XP machines and there is no correlation between the OS and the degree of communication difficultly.
The problem has nothing to do with this existing Microsoft knowledge base item, as I will show with network traffic logs.
When the printer just starts and works fine, the communication is as follows: the client sends a [SYN] packet, the printer responds with [SYN, ACK] to which the client sends another [ACK]. At this point, the connection is established and the client starts sending data packages. After two packages the printer sends an [ACK] back. As the Microsoft’s knowledge base article states, TCP sends [ACK]’s every two packets, so this is normal. This repeats a number of times until the printer starts printing.
The following TCP/IP analysis shows it clearly (192.168.1.205 is the client, 192.168.1.103 is the printer. Don’t pay attention to the source port network name):
When the communication problems begin, the difference is that after the first two data packets are sent, the printer doesn’t send the expected [ACK] packet. The client keeps sending retransmissions until the printer eventually sends a [RST] (reset):
The printer obviously doesn’t adhere to TCP/IP standards. Xerox technical support likes to claim that the problem is in our network, because the fault doesn’t (easily) happen when they connect a laptop to the printer with a crosslink cable, but this evidence clearly shows the printer is at fault. Even if it starts doing this because of some invalid data packet our client PC’s might send, it’s still faulty behavior. To such an extent even, that if any server or client machine would have this problem, it would be classified as a security risk, because it is then susceptible to denial of service attacks.
I found out what the problem was. It was another device in our network after all.
Our Fox Davo phone switch decided to allocate two additional IP addresses to itself, without asking. One of them conflicted with the printer.
It’s a bit odd that this printer has problems with it, whereas the old Xerox 232 didn’t. The only theory I have at the moment, is that this new machine must be faster in responding to ARP requests than the phone switch, whereas the old printer was slower. If the printer informs the clients that it has IP address x after the phone switch does, it may be enough to let the clients have an accurate ARP table.
Every time I say I am SOOO sure of something I really ask myself: is it 100%?
The wireshark investigations were key, but you drew the wrong conclusion – that there was something wrong with the printer. You can’t always blame the symptom (the printer here) as the problem.