Re: 3110 statemachine handling (patch)

[Osma Suominen]

First of all, I appreciate Bozo's explanation for the reasons why the
current __sm_block_timeout() does resending of unacknowledged frames.
This is a complicated issue and I think we are only now starting to have
the whole picture of the situation, not only from the existing and
working drivers' point of view but also for the nk3110 and dancall
drivers.

On Mon, 24 Feb 2003, BORBELY Zoltan wrote:

> We should try to call sm_incoming_acknowledge() function in the send
> function of the appropriate link drivers. It will disable this retransmit
> feature. If we won't retransmit unacknowledged frames in the fbus
> and m2bus drivers, the moving and duplication phonebook entries problems
> will reappear.

This is _not_ a solution for the 3110. The situation in which the
retransmission of non-acked messaged breaks the 3110 driver is when the
phone sends several messages in a row. Like this, when requesting a
large SMS message from the phone: (ignore the asterisk for now)

-> 0x25 request SMS
<- ack 0x25
<- 0x2c SMS header
-> ack 0x2c
   *
<- 0x27 SMS data #1
-> ack 0x27
<- 0x27 SMS data #2
-> ack 0x27
<- 0x27 SMS data #3
-> ack 0x27

So the sequence is not such that the driver and phone take turns in
communication, but rather the phone may answer with up to 4 messages for
a single request.

Now let's assume that sm_block() is used to wait for the first SMS data
message, right after the SMS header has been received, marked with the
asterisk *. The way __sm_block_timeout() is written, it will wait for
100 ms, and if no 0x27 arrives in that time (the probability for that to
happen seems to be around 50-50), it will resend the 0x25 request,
because the statemachine is not in the GN_SM_MessageSent state but in
the GN_SM_Initialized state (remember, no message was sent, we are just
waiting for a followup on the SMS header)  and thus the condition in the
do...while() loop of __sm_block_timeout() is always false. This was the
reason for my oneline patch to __sm_block_timeout(), which I later
reverted, because I decided not to use sm_block() at all in this
situation because it was not terribly suitable anyway (think what
happens if a frame is lost).

If the 0x27 frame does not arrive in 100ms and the 0x25 request is
resent, the phone will start over etc...no good things happen. Of course
the same sequence repeats when waiting for the later SMS data messages.

-Osma

-- 
*** Osma Suominen *** address@hidden *** http://www.iki.fi/ozone/ ***