RE: CIPE-Win32 transfer hangs|
Jan Olderdissen <jolderdissen,AT,ixiacom,DOT,com>|
Sun, 10 Mar 2002 18:45:12 +0100|
Which leads to the obvious question what we're going to do about it. How
does closing and reopening the socket after the error occurs grab you?
From: Damion Wilson [mailto:dwilson,AT,ibl,DOT,bm
Sent: Saturday, March 09, 2002 19:21
To: dank,AT,kegel,DOT,comJuan Antonio Ruiz Zwollo; Jan Olderdissen; Sandino
Subject: Re: CIPE-Win32 transfer hangs
And this provides details right from the mouth of the horse.
On Saturday 09 March 2002 09:36 pm, you wrote:
> 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...
> - Dan
> 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.
> > Jan
> > -----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
> > satisfied
> > later on, i.e. when the peer eventually sends an unsolicited packet.
> > However,
> > the read request returns a WSAECONNRESET status which I (must) ignore if
> > I am
> > 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
> > 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
> > 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
> > state because they are connectionless. There should not be lingering
> > statuses
> > between SendTo's and RecvFrom's. Period.
> > DKW
> > 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
> > code
> > > > 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
> > > > 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:
> > <URL:http://sites.inka.de/~bigred/devel/cipe.html>