To: papval@mail.otenet.gr
From: dlanor@oden.se (Ronald Andersson)
Message-ID: <381f5c521672b70@oden.se>
Subject: Bug in your serial patch
X-Mailer: Okami Version 2.1B-9
Date: Tue, 02 Nov 1999 22:43:26 +0100 (MET)
Lines: 96

Hi Vassili,

I have now taken the time to dig into the serial.stx sources, including your
patches to it, and have also proceeded to test that version as well as one
where I have merged your changes into the sources I am working on.  In this
testing I have discovered one bug that garbles data in such a way that the
damaged data is not detected, but is instead accepted as correct, which makes
it a very serious problem.

The garbling itself is not random in its output, but appears to lead to lost
or misplaced data, visible in pictures as misaligned and/or miscolored parts.

The problem does not occur 'of itself' but can occur whenever heavy interrupt
driven activity of other kinds is going on, such as vigorous mouse movement.
So that was how I verified this, by jerking the mouse about while downloading
some large pictures in CAB.  This triggers the problem in almost 100% of such
tests.  Doing the same thing with version 1.15 of serial.stx has no other
effect than slowing down the transfers, as most faulty data is then correctly
rejected by the checksum tests. Somehow the bug in your version bypasses them.

Note that with primitive checksums, such as those used by TCP/IP, misplaced
data does not cause any checksum error when occurring on even byte borders !
It is possible to exchange any 16 bit word sequences within a data block
without affecting either IP or TCP checksums in any way.
(That is a very serious handicap for TCP, which ought to use CRC instead.)

I suspect that the problem lies in 'my_receive' and how it handles the buffer
used for accumulating a datagram, but I have not yet found a definite cause.
I will search on, and try to eliminate the problem of course, and I suggest
you do the same at your end.  One of us should catch it pretty soon I hope.


As for version 1.16 by Peter, I have now checked the diffs from 1.15 and can
verify that they were not significant.  They only concern the addition of
two elements ('pap_ack' and 'pap_nak') to a structure for ppp, and their
initialization by the 'contrl_port' opcode 'CTL_SERIAL_SET_AUTH'.  But
they are not used anywhere, so they do not matter.  I have checked in the
sources of both STNGPORT.CPX and DIALER.APP, and they don't use that code.
As far as I am concerned we can forget that version.

In any case, the new version, with your changes merged into my sources, will
become version 1.17 .  (probably even higher before public release)


One other matter needs to be settled.  Now both you and I have provided
additions to Peter's components, and that makes the usage of the author
fields in modules and other structs tricky.  As such strings must fit in
an alert preceded by the string "by :  " of 6 chars, this leaves only
29-6 == 23 chars for the author string.  "Peter Rottengatter" uses up 18
of those, leaving us with 5 chars which we have hitherto used as " & xx",
with 'xx' standing for the initials of the contributor.

That scheme obviously does not work anymore, when more than one contributor
is involved for the same component, which is already the case for serial.stx,
and will probably soon be true for other components as well.

There are three basic methods of solving this dilemma.

1:  Ignore it, and leave "Peter Rottengatter" intact for all components.
    I don't like this.  It is misleading and contradicts the purpose of
    the structure element.

2:  Like now, add " & xx" but let "xx" be initials of a group instead of
    a person.  Like "ST" as abbreviation for "Sting Team".  Detailed info
    on contributions will of course still be available in history files.
    This would be ok, in a limited way, but far too brief for my taste.

3:  Use "|   &  " to force new line usage in such alerts, which can then
    be followed by other author names, aligned vertically with Peter's.
    This is quite good, but limited by the maximum of 5 alert lines, and
    alerts already existing use two of those for other stuff, giving a max
    limit of two new names added this way.  For maximum compatibility I
    suggest that only one new line be added this way.

I suggest that we combine the methods specified in "2:" and "3:" above,
and add the string "|   &  STinG Development Team", which latter name
will then be what we in future call the group of authors that take part
in this work.  As yet that is just you and me of course, but hopefully
others will join us later.

Naturally it will be okay to use a personal name instead, if only one
person is involved in enhancing a component, but since I am interested
in all of them, I probably will get involved with most eventually...  ;-)

In any case, future versions will always include a history file that
gives some details on who has contributed what to each component, so
that information will always be available, regardless of the method
chosen for what author strings to use.

So, what do you think ?

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