Project

General

Profile

Actions
Copy link

Bug #6142

closed

channels are opened, but nothing happens, sometimes strange DTAP messages appear

Added by dexter 8 months ago. Updated 8 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
pespin
Category:
-
Target version:
-
Start date:
08/23/2023
Due date:
% Done:

100%

Spec Reference:

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

trace_23082023.pcapng trace_23082023.pcapng 22.1 KB dexter, 08/23/2023 02:39 PM
osmo-bts-trx_23082023.log osmo-bts-trx_23082023.log 120 KB dexter, 08/23/2023 02:50 PM

Related issues

Related to libosmocore - Bug #3626: LAPDm code pulls both 'l1h' and 'l2h' of msgbResolvedpespin10/04/2018

Actions
Actions
Copy link
 #1

Updated by dexter 8 months ago

(attached log from osmo-bts)

Actions
Copy link
 #2

Updated by dexter 8 months ago

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.

Actions
Copy link
 #3

Updated by pespin 8 months ago

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.

Actions
Copy link
 #4

Updated by pespin 8 months ago

  • Related to Bug #3626: LAPDm code pulls both 'l1h' and 'l2h' of msgb added
Actions
Copy link
 #5

Updated by pespin 8 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)

Actions
Copy link
 #6

Updated by pespin 8 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]

Actions
Copy link
 #7

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

Actions
Copy link
 #8

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.

Actions
Copy link

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)