Re: [ECOS] Problems when aborting tftp transfers

[Andrew Lunn <andrew at lunn dot ch>]

> > Does the M$ end send an error packet to terminate the transfer or
> > simply stop sending data packets?
> 
> I don't know what ctrl-c does(I haven't got the equipment wired up so I
> can't test right now), but surely terminating the process would cause an
> error packet not to be transferred?

In the unix world, i would expect the application to trap ^C so that
it can do a clean shutdown. I don't know if M$ does this. Anyway, this
is probably not the real problem, its only an optimization. Since TFTP
is based on UDP, the error packet can get lost so the real method is
based on timeouts. It should give up after 30 seconds.

> > > - at this point the tftp server goes back to the main loop and sees
> > > multiple tftp transfer initiation requests from the aborted transfer
> > > session. 
> > 
> > Initiation requests? You mean WRQ packets from the tftp client you
> > have just killed? 
> 
> Yes.
> 
> I really don't speak PPP, TCP/IP, Windows and tftp well enough to pick
> this apart without more study.
> 
> Perhaps this is something that was lingering in the PPP channel or
> tcp/ip stack... 

That does not make sense. 

We need a trace of packets being transfered to be able to understand
this further. Use windump or something similar on the M$ box to get a
packet capture so we can see what is going on.

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss