OpenBTS OML sequencing / startup problems

[Harald Welte]

Hi zecke,

one of the things that I've been thinking about earlier today while talking
with Roch was the fact that we do the A-bis OML overlapping / asynchronously,
i.e. if we send a 'set attribute ...' or 'opstart' message, we never wait
for the acknowledgement before sending the next message.

While this might be efficient and compliant with the specification, it is
likely to expose bugs like race conditions in software that has never been
tested against it.

So one of the ideas would be to make the abis_nm.c layer queue up messages
during abis_nm_sendmsg() and determine based on the messagetype if it is
a message that we're expecting an ACK/NACK as response.  If yes, delay
transmission of further enqueued OML messages until such ACK/NACK is
received.  Of course, there probably should also be a timer whose expiration
should generate at least a log file entry (and after which we continue with
the next message from the queue)

I'm not sure if you feel in the mood for implementing something like this
or not.  I can also stop with GPRS work and have a look at it.

This request/response tracking would probably also be useful once we extend
our ability to send OML messages from e.g. external applications.  We could
then notice who submitted the message and deliver the result back to the
caller without having to consider re-ordering or something like that.

Regards,
	Harlad

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)