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):

wireshark-screenshot-success2

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):

wireshark-screenshot-failed2

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.