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

--
http://mail.python.org/mailman/listinfo/python-list

[Dave Angel]

On 05/22/2013 04:46 AM, loial wrote:
> <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.)


--
DaveA

[Jorgen Grahn]

On Wed, 2013-05-22, Dave Angel wrote:
> On 05/22/2013 04:46 AM, loial wrote:
>> <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.

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 <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Jorgen Grahn]

On Wed, 2013-05-22, Matt Jones wrote:
> On Wed, May 22, 2013 at 3:46 AM, loial <jldun...@gmail.com> wrote:
>
>> 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

> 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.

[Grant Edwards]

On 2013-05-22, Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Wed, 2013-05-22, Dave Angel wrote:
>> On 05/22/2013 04:46 AM, loial wrote:
>>> <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.
>
> 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

>> (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.

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...

--
Grant Edwards grant.b.edwards Yow! Of course, you
at UNDERSTAND about the PLAIDS
gmail.com in the SPIN CYCLE --