Hi Vassili,

on Thu 14-10-1999 17:26 Vassilis Papathanassiou wrote:
>on Wed 06-10-1999 11:20 Ronald Andersson wrote:
>
>>>I need to investigate it in much greater detail.
>>
>>Please do, as this is fairly new code, and not much debugged.
>>
>Ok, I did, up to now (and this includes TCP v1.28) we still have more
>transmitions and not only retransmitions, since I've temporarily disabled
>the retransmition part of code (from timer_work in TOOL.C). Must be a
>bug there also (probably in calculations in do_arrive), as 'real'
>retransmitions occur with a defined pattern, without any reason.

That sounds interesting, but still a bit vague.


>My real problem is that I can't tell (for the moment) if IP delivers
>double packets on its own or TCP transmits some packets by mistake
>(eg FORCE flag set when it shouldn't), and thus the remote TCP has
>to ack them.

From what I have seen the packets must be sent by TCP.  There is no
way the IP parts can decide to resend a TCP packet the way it is
being done.  A bug of that kind would probably resend a packet with
the same IP identifier instead, which never happens.

Inappropriate use of the FORCE flag is the thing most suspected by
me for some of the resending.


>At least I've verified (setting breakpoints at my_TCP_send() etc) that
>BNeT does NOT send excessive packets and (thanks to do_output in the
>same routine) TCP does the same. But the reply to a single packet
>going out, is multiple packets coming in. Still, it's rather complicated
>to find out where they're coming from. I mean that setting a breakpoint
>to TCP_handler, verifies multiple input but at this time I can't check
>if the remote TCP actually sends them or the local IP reads them twice!

Also, it is very difficult to breakpoint at one end without affecting
retransmission timeouts at the other end, which may invalidate some
of the results.  (Possibly why you disabled retransmission ?)

I beleive that inappropriate window updates are one reason for extra
ACK sending.  Left edge advances do not demand new ACK packets to be
sent to the other party, and as long as outstanding unacked data has
been sent the Nagle rules make extra ACK packets superfluous, but the
routines that set the FORCE flag don't care about such things.


>Anyway, rereading the above, I think I'm not informative enough, I'm
>writing a test program now (and a debug TCP version) which will tell
>us exactly where the problem is.

Good.  I look forward to the results of that.


>>Key routines leading to 'do_arrive':
>>------------------------------------
>[ snip: routines explanation ]
>
>Thanks Ronald, they were very helpful to understand the internals.
>Still, there are a lot of things that seem OK to me but obviously
>something is not :-(

Join the club...  :-)

That is what I have been thinking ever since I started helping Peter
with TCP debugging.  Some stuff looks right, but if you modify it
that has no effect.  So posssibly that code is never reached at all.

This goes for several of the switch clauses in 'do_arrive' in particular,
due to the complex structure of that function, with its many exit points.

-- 
-------------------------------------------------------------------------
Regards:  Ronald Andersson                  mailto:dlanor@ettnet.se
http://dlanor.atari.org/    ICQ:38857203    http://www.ettnet.se/~dlanor/
-------------------------------------------------------------------------
