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

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

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 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
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 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.





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