Cellular Network Infrastructure » Radio Access Network » OsmoBTS

Maybe that is worth to mention: osmo-bts-trx/osmo-trx run on a separate machine. There I reverted the patch in libosmocore. The core-network runs on a machine that runs with current master libosmocore.

That's probably due to some patch in osmo-bts handling lapdm indications in a "lazy" or "too-smart" way doing too many assumptions on the msgb. I'll have a look.

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)

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]

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.