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