Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #45717 > unrolled thread

Diagnosing socket "Connection reset by peer"

Started byloial <jldunn2000@gmail.com>
First post2013-05-22 01:46 -0700
Last post2013-05-22 19:55 +0000
Articles 6 — 5 participants

Back to article view | Back to comp.lang.python


Contents

  Diagnosing socket "Connection reset by peer" loial <jldunn2000@gmail.com> - 2013-05-22 01:46 -0700
    Re: Diagnosing socket "Connection reset by peer" Matt Jones <matt.walker.jones@gmail.com> - 2013-05-22 06:46 -0500
      Re: Diagnosing socket "Connection reset by peer" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-05-22 19:54 +0000
    Re: Diagnosing socket "Connection reset by peer" Dave Angel <davea@davea.name> - 2013-05-22 08:50 -0400
      Re: Diagnosing socket "Connection reset by peer" Jorgen Grahn <grahn+nntp@snipabacken.se> - 2013-05-22 19:44 +0000
        Re: Diagnosing socket "Connection reset by peer" Grant Edwards <invalid@invalid.invalid> - 2013-05-22 19:55 +0000

#45717 — Diagnosing socket "Connection reset by peer"

Fromloial <jldunn2000@gmail.com>
Date2013-05-22 01:46 -0700
SubjectDiagnosing socket "Connection reset by peer"
Message-ID<038ecc3e-1272-46c0-84d5-556daeffbde0@googlegroups.com>
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





[toc] | [next] | [standalone]


#45724

FromMatt Jones <matt.walker.jones@gmail.com>
Date2013-05-22 06:46 -0500
Message-ID<mailman.1960.1369223210.3114.python-list@python.org>
In reply to#45717

[Multipart message — attachments visible in raw view] — view raw

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*


On Wed, May 22, 2013 at 3:46 AM, loial <jldunn2000@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
>
>
>
>
>
>
> --
> http://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]


#45748

FromJorgen Grahn <grahn+nntp@snipabacken.se>
Date2013-05-22 19:54 +0000
Message-ID<slrnkpq8is.3jn.grahn+nntp@frailea.sa.invalid>
In reply to#45724
On Wed, 2013-05-22, Matt Jones wrote:
> On Wed, May 22, 2013 at 3:46 AM, loial <jldunn2000@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.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]


#45728

FromDave Angel <davea@davea.name>
Date2013-05-22 08:50 -0400
Message-ID<mailman.1963.1369227039.3114.python-list@python.org>
In reply to#45717
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

[toc] | [prev] | [next] | [standalone]


#45745

FromJorgen Grahn <grahn+nntp@snipabacken.se>
Date2013-05-22 19:44 +0000
Message-ID<slrnkpq80d.3jn.grahn+nntp@frailea.sa.invalid>
In reply to#45728
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   .

[toc] | [prev] | [next] | [standalone]


#45749

FromGrant Edwards <invalid@invalid.invalid>
Date2013-05-22 19:55 +0000
Message-ID<knj7rr$7ai$1@reader1.panix.com>
In reply to#45745
On 2013-05-22, Jorgen Grahn <grahn+nntp@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 --

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web