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 10 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 10 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 10 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 10 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.