Diagnosing socket "Connection reset by peer"

[loial]

I have a sockets client that is connecting to a printer and occassionally getting the error "104 Connection reset by peer"

I have not been able to diagnose what is causing this. Is there any additional traceing I can do(either within my python code or on the network) to establish what is causing this error?

Currently I am simply trapping socket.erruor

Python version is 2.6

 

[Matt Jones]

This typically indicates that the "peer" at the other end of the tcp
connection severed the session without the typical FIN packet. If you're
treating the printer as a "blackbox" then there really isn't anything you
can do here except catch the exception and attempt to reconnect.

*Matt Jones*

 

[Dave Angel]

<SNIP>

.... Is there any additional traceing I can do(either within my python code or on the network) to establish what is causing this error?

Try using Wireshark. It can do a remarkable job of filtering,
capturing, and analyzing packets. It can also read and write pcap
files, which you could either save for later analysis, or send to
someone who might help. (Note - unfiltered pcap files can be very large
on a busy network, but if you can quiet other traffic, you may not need
to filter at all.)

 

[Jorgen Grahn]

Try using Wireshark. It can do a remarkable job of filtering,
capturing, and analyzing packets. It can also read and write pcap
files, which you could either save for later analysis, or send to
someone who might help.

Or use tcpdump, which has a text interface so you can show the problem
in a text medium like Usenet.

(Note - unfiltered pcap files can be very large
on a busy network, but if you can quiet other traffic, you may not need
to filter at all.)

Or simply filter. It's not hard -- the capture filter
"host my-printer-hostname-or-address" is enough.

/Jorgen

 

[Jorgen Grahn]

This typically indicates that the "peer" at the other end of the tcp
connection severed the session without the typical FIN packet.

I.e. by sending a RST (reset) instead. Yes, that's what "Connection
reset by peer" means. I don't think there are any other causes for
this signal.

A server application can cause a reset explicitly, or if it crashes
the OS will send one for it, as part of the resource cleanup.

Also, if you're behind a cheap NATing gateway, I think it may send
fake RSTs if it has lost track of the TCP session.

If you're
treating the printer as a "blackbox" then there really isn't anything you
can do here except catch the exception and attempt to reconnect.

Yes. Note that there *may* be some uncertainty re: "did the printer
process the last request before the reset or not?" E.g. I wouldn't
endlessly retry printing a 100-page document in that case.

/Jorgen

 

[Grant Edwards]

Or use tcpdump, which has a text interface so you can show the problem
in a text medium like Usenet.

There's also tshark, which is sort of a command-line version of
wireshark.

http://www.wireshark.org/docs/man-pages/tshark.html

Or simply filter. It's not hard -- the capture filter "host
my-printer-hostname-or-address" is enough.

Indeed. Even a simple filter can make life several orders of
magnitude easier. If filtering by IP address isn't enough, the next
step is usually to add a port number filter...