I installed release 11 today and it has been working great without a single
hitch; the tunnel does not shut down. How would I notice if goes into an
----- Original Message -----
From: "Jan Olderdissen" <jolderdissen,AT,ixiacom,DOT,com>
To: "'Damion Wilson'" <dwilson,AT,ibl,DOT,bm>; "Sandino Araico Sánchez"
Cc: "Juan Antonio Ruiz Zwollo" <J.Antonio,AT,jaruz,DOT,com>;
Sent: Saturday, March 09, 2002 6:57 PM
Subject: RE: CIPE-Win32 transfer hangs
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
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
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.