I did a google search for 'WSAECONNRESET datagram bug'
and got some interesting hits, e.g.
I wonder if there might be some connection with the cipe problems...
Jan Olderdissen wrote:
> I installed and tested release 11 today. The good news is that there no
> longer are blue screens when disabling the driver. The issue with "port
> unreachable" killing the service seems to have disappeared as well. Sadly,
> I'm not getting any valid packets across, with the exception of pings. If I
> attempt to FTP across the link, the packets being returned contain lots of
> zeros and not much else. Not even the IP header is correct. I don't get it.
> Tomorrow I'll go back to release 9 which I used before to make sure it
> behaves differently.
> -----Original Message-----
> From: Damion Wilson [mailto:dwilson,AT,ibl,DOT,bm
> Sent: Saturday, March 09, 2002 09:29
> To: Sandino Araico Sánchez
> Cc: Juan Antonio Ruiz Zwollo; cipe-l,AT,inka,DOT,de; Jan Olderdissen
> Subject: Re: CIPE-Win32 transfer hangs
> In which case I have a major problem. Here's the dilemma :
> The socket read routine wants to queue a read request that will get
> later on, i.e. when the peer eventually sends an unsolicited packet.
> the read request returns a WSAECONNRESET status which I (must) ignore if I
> ever going to successfully queue the read request. If the socket has indeed
> become invalid, I will continue to get this status back and never queue the
> pending read.
> If this is so, then Windows sockets is more flawed than I thought because it
> would require that I dismantle the socket and its managing structures.
> The pre11 I released last night ignores the WSAECONNRESET's so try it out
> guys and tell me if it goes into an infinite loop there. If necessary I'll
> put a status message there.
> I hate this. Datagram sockets are not supposed to maintain any connection
> state because they are connectionless. There should not be lingering
> between SendTo's and RecvFrom's. Period.
> On Saturday 09 March 2002 12:29 am, you wrote:
> > Jan Olderdissen wrote:
> > > This is making more and more sense. I haven't tried to log the error
> > > as you suggested because the machine I can do this on is not currently
> > > hooked up to anything. However, check out the return code WSAECONNRESET
> > > from WSARecvFrom(). The description states: "The virtual circuit was
> > > reset by the remote side executing a hard or abortive close. The
> > > application should close the socket as it is no longer useable. On a
> > > UPD-datagram socket this error would indicate that a previous send
> > > operation resulted in an ICMP "Port Unreachable" message."
> > Ok. This enforces my suspect that the Windows cipe is sending a small
> > packet which kills the Linux cipe. The Windows cipe is not able to
> > differentiate between the other end being dead and UDP packets being lost
> > because of a network problem.
> Message sent by the cipe-l,AT,inka,DOT,de mailing list.
> Unsubscribe: mail majordomo,AT,inka,DOT,de, "unsubscribe cipe-l" in body
> Other commands available with "help" in body to the same address.
> CIPE info and list archive: