Bug #6142
closedchannels are opened, but nothing happens, sometimes strange DTAP messages appear
100%
Description
This behavior was observed with osmo-bts-trx. A channel gets assigned, we see measurement reports and rarely some strange DTAP messages. The channel stays open for a while and then closes. (see attached trace)
When libosmocore change Id62c18f49f270449067b25b7104eb8b47f1955ec is reverted, then everything appears to be normal again.
Files
Related issues
Updated by pespin 9 months ago
The issues that pmaier was experiencing are due to the new RSL_IE_OSMO_ABS_FRAME_NUMBER I intruded in RSLms. I didn't see the msgbs are actually forwarded as they come in osmo-bts towards RSL... so the new TLV is also transmitted over the wire...
which is something we should not be doing. So we either fix osmo-bts to properly construct a new msg from the received msg (which may also make sense), or I revert all the RSL_IE_OSMO_ABS_FRAME_NUMBER and indeed use the cb[]. I don't really enjoy any of those, but here we are.
Call path:
l3_cb (libosmocore) lapdm_rll_tx_cb (osmo-bts) abis_bts_rsl_sendmsg (osmo-bts) abis_sendmsg (libosmo-abis)
Updated by pespin 9 months ago
I submitted reverts for now to avoid users experiencing this change:
remote: https://gerrit.osmocom.org/c/libosmocore/+/34182 Revert "lapdm: Append RSL_IE_OSMO_ABS_FRAME_NUMBER to RSLms msgs towards ... [NEW]
remote: https://gerrit.osmocom.org/c/libosmocore/+/34183 Revert "rsl: Introduce new osmocom extension IE RSL_IE_OSMO_ABS_FRAME_NUMBER" [NEW]
Updated by pespin 8 months ago
- Status changed from New to Resolved
- % Done changed from 0 to 100
The offending patches have been reverted in libosmocore, and I submitted to gerrit an extra one to make the mctx public struct updated so that it can be used from l3_cb to obtain the FN:
https://gerrit.osmocom.org/c/libosmocore/+/34185 lapdm: Update public lapdm_msg_ctx upon CCCH data ind
https://gerrit.osmocom.org/c/osmocom-bb/+/34133
Updated by laforge 8 months ago
On Wed, Aug 23, 2023 at 03:41:00PM +0000, pespin wrote:
So we either fix osmo-bts to properly construct a new msg from the received msg (which may also make sense), or I revert all the RSL_IE_OSMO_ABS_FRAME_NUMBER and indeed use the cb[]. I don't really enjoy any of those, but here we are.
your solution "a" wouldn't work for old osmo-bts on new libosmocore, so I guess the cb solution is superior
here.