Bug #5971
closedBTS_Tests_LAPDm.TC_sabm_ua_dcch_sapi0_nopayload fails
100%
Description
BTS_Tests_LAPDm.TC_sabm_ua_dcch_sapi0_nopayload fails.
error: Initial SABM/UA must contain L3 payload but BTS accepts without
This is an actual bug in either libosmocore or osmo-bts. The BTS should not accept SABM without L3 payload. It's debatable if LAPDm code should handle it, or the user (BTS).
Updated by jolly 9 months ago
I can't see any point in the specs that does not allow establishment without contention resolution on SAPI 0 @ main DCCH. Otoh, I could not find any use case for normal establishment (without contention resolution).
The BTS just forwards any RLL message towards BSC. The BSC checks for odd establishment cases. This case should be handled by the BSC also.
Updated by laforge 8 months ago
I think all we are arguing over whether it is the LAPDm code (libosmocore.git) or osmo-bts that needs fixing, right?
While I agree that the LAPDm spec (TS 44.006) doesn't forbid the use of main DCCH establishment without contention resolution, it is IMHO clear that it is not permitted in the specific use case of a BTS.
TS 44.018:
Upon seizure of the assigned dedicated channel or group channel, the mobile station establishes the main signalling link on this channel by sending a layer 2 SABM frame containing a layer 3 service request message. The data link layer will store this message to perform the contention resolution. The service request message will be returned by the network in the UA frame.
I don't see any other part of the GSM specs that would permit such a DCCH establishment without contention resolution. In fact, it would be rather dangerous if we permit it.
So as I wrote when filing this bug "It's debatable if LAPDm code should handle it, or the user (BTS).". So if you want to keep LADPm generic, then osmo-bts must reject that case.
