Feature #1605
openlogging / ring buffer for ALERT messages from A-bis OML from the BTS side
70%
Description
OML ALERT messages are currently not really used much. They should be used more from the BTS side, and the BSC component in the NITB should not only log them somewhere but possibly even keep an in-memory ring buffer for each BTS/TRX so one can inspect the most recent errors for those objects via the VTY.
Related issues
Updated by laforge over 7 years ago
- Related to Feature #1857: aggregate and report OML ALERT messages received from BTSs added
Updated by laforge over 6 years ago
- Project changed from OpenBSC to OsmoBSC
- Category deleted (
libbsc)
Updated by laforge over 5 years ago
This is actually slightly similar to the "show last unsuccessful BTS connection attempts". In both cases we want to keep a ring-buffer of most recent events. However, the difference is that for ALERT, we want one FIFO ring buffer per BTS, while for the BTS connection attempts, we want one global ring buffer, and entries should be overwritten in case the same BTS attempts again...
Updated by osmith about 4 years ago
- Description updated (diff)
- % Done changed from 0 to 30
OML ALERT messages are currently not really used much. They should be used more from the BTS side
Nowadays, the BTS seems to make good use of the OML failure reports. Example patch
and the BSC component in the NITB should not only log them somewhere
I've verified that the BSC is logging these messages.
but possibly even keep an in-memory ring buffer for each BTS/TRX so one can inspect the most recent errors for those objects via the VTY.
This is what I'm working on now.
I realized that it is not possible to send OML failure reports from the TTCN-3 testsuite, only RSL error reports. So, for manual testing during development, I've added a test VTY command to osmo-bts-virtual to send an OML failure report to the BSC. (osmo-bts branch: osmith/alert-buffer)
This works, the OML failure reports arrive at the BSC and I found the place to handle them. I've added code to save it to a ring buffer and a VTY command to read it out. While testing, I'm currently getting segfaults when accessing the llist, although it is already initialized.
WIP branch for osmo-bsc: osmith/alert-buffer
Updated by laforge about 4 years ago
On Fri, Mar 20, 2020 at 03:59:03PM +0000, osmith [REDMINE] wrote:
I realized that it is not possible to send OML failure reports from the TTCN-3 testsuite, only RSL error reports.
That's only half true. Since May 2019, library/AbisOML_* contains type
definitions, templates and an "Emulation" part for OML. Even
ts_OML_FailureEvtRep() exists. It's just that none of our existing
tests / testsuites uses it.
I currently don't see a reason why they couldn't be used. Sure, as a
first user you might run into bugs, but I think it should at least be
tried.
Updated by osmith about 4 years ago
laforge wrote:
On Fri, Mar 20, 2020 at 03:59:03PM +0000, osmith [REDMINE] wrote:
I realized that it is not possible to send OML failure reports from the TTCN-3 testsuite, only RSL error reports.
That's only half true. Since May 2019, library/AbisOML_* contains type
definitions, templates and an "Emulation" part for OML. Even
ts_OML_FailureEvtRep() exists. It's just that none of our existing
tests / testsuites uses it.
Cool, I'll try this!
Updated by osmith about 4 years ago
osmith wrote:
While testing, I'm currently getting segfaults when accessing the llist, although it is already initialized.
The wrong BTS pointer is getting passed, fix here: https://gerrit.osmocom.org/c/osmo-bsc/+/17569
Updated by osmith about 4 years ago
- % Done changed from 30 to 60
keep an in-memory ring buffer for each BTS/TRX so one can inspect the most recent errors for those objects via the VTY.
Patch submitted: https://gerrit.osmocom.org/c/osmo-bsc/+/17571
Another patch submitted with what I've been using for manual testing with OsmoBTS: https://gerrit.osmocom.org/c/osmo-bts/+/17573
Automated TTCN-3 test remains.