<< | Thread Index | >> ]    [ << | Date Index | >> ]

Subject: RE: CIPE-Win32 transfer hangs
From: Jan Olderdissen <jolderdissen,AT,ixiacom,DOT,com>
Date: Sun, 10 Mar 2002 02:43:04 +0100

This is exactly the symptom we were seeing. In release 11, Damion was able
to work around it as far as I can tell. I certainly haven't seen the service
hanging anymore.


-----Original Message-----
From: Dan Kegel [mailto:dank,AT,kegel,DOT,com
Sent: Saturday, March 09, 2002 17:36
To: Jan Olderdissen
Cc: 'Damion Wilson'; Sandino Araico Sánchez; Juan Antonio Ruiz Zwollo;
Subject: Re: CIPE-Win32 transfer hangs

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
> 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
> 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
> become invalid, I will continue to get this status back and never queue
> pending read.
> If this is so, then Windows sockets is more flawed than I thought because
> 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
> statuses
> 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
> 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
> > > 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
> > 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:

<< | Thread Index | >> ]    [ << | Date Index | >> ]