Re: statemachine flaws/weaknesses

[Ladislav Michl]

On Tue, Feb 25, 2003 at 10:29:54AM +0100, Pawel Kot wrote:
> >>> address@hidden 25 February 2003 01:10:56 >>>
> > There were some problems which I wanted to solve:
> > * The "moving and duplicating phonebook entries" problem. When the
> >   phone takes too long time to respond (it's more usual when you
> >   are using m2bus) the phone retransmits its reply. gnokii isn't
> >   able to suppress this message and it can cause a lot of very
> mystical
> >   problem. I managed to reproduce this bug: when I connected a 6110
> >   to a Sun with an mbus cable gnokii --monitor segfaults in a
> minute.
> 
> Sorry, I don't buy it. If I understand you correctly, you say that
> phone sends the reply twice when it takes too long because we
> retransmit the request. Am I correct? If so we set *incorrect* timeout
> value in the initial request.

it is also possible that computer is not fast enough to ack incoming
frame. in such case phone will repeat last frame. the only solution is
to check if no retransmisions occures after we send ack.

> But I agree that some retransmission schema is *required* but at the
> moment it is *unconditional*. And that's *bad*. Probably the fbus
> and mbus drivers do need it. But other link drivers (atbus for my
> knowledge so far, and 3110-fbus and cbus according to Ladis and
> Osma) do NOT need it. Moreover they are broken with such policy.

in fact cbus also needs retransmissions, but it have to be done with
precise timing. and atbus can also live with some kind of retransmission
policy, but it doesn't know what acks are.

> And as I wouldn't care so much about nk3110 and duncall drivers
> in 0.5.0 release (they were broken for "ages", but it would be
> really nice to have them working properly again), but I *do* care
> about atgen driver.

disable them, put all headers in place and release :-) the rest can wait
easily. this will probably force us to have "stable" and "head" branch
in cvs...

> Try to send an SMS (quite long SMS, when the network is busy)
> with AT driver and the current policy. You'll get an error and a
> message sent twice when you have unluck.

i vote for fixing (even) dirty of AT driver.

        ladis