Bug #6351
closedrlcmac: Bug calculating/encoding 2 LLC frames fitting in 1 CS4 UL Data block
100%
Description
During initial GMM ATTACH + SM PDP ACT procedure, if using CS4 in UL, we end up in a situation where basically the MS, upon receiving GMM Attach Accept, triggers creation of a new UL TBF and wants to send 2 LLC frames one after the other (GMM AttachCompl + SM PDP Act Context Req):
1242 16:09:52.495676 Feb 2, 2024 17:09:52.495676000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 199 ✓ GRE(91223344) Update TLLI 0x91223344 -> 0xe0083f9b 1243 16:09:52.495750 Feb 2, 2024 17:09:52.495750000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 224 ✓ GMME(IMSI-001010000000101:PTMSI-e0083f9b:TLLI-e0083f9b) Tx GMM ATTACH COMPL 1245 16:09:52.495901 Feb 2, 2024 17:09:52.495901000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 228 ✓ modem_llc_prim_down_cb(): Rx GRR-UNITDATA.request ll=[01 c0 0d 08 03 55 1c ea ] 1247 16:09:52.496061 Feb 2, 2024 17:09:52.496061000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 209 ✓ GRE(e0083f9b) Enqueueing LLC-PDU len=8 SAPI=GMM radio_prio=1 1260 16:09:52.497107 Feb 2, 2024 17:09:52.497107000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 201 ✓ PDP(ID-0:NSAPI-6) Tx SM Activate PDP Context Request 1263 16:09:52.497349 Feb 2, 2024 17:09:52.497349000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 321 ✓ modem_llc_prim_down_cb(): Rx GRR-UNITDATA.request ll=[01 c0 11 8a 41 06 03 0e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 01 21 28 09 08 69 6e 74 65 72 6e 65 74 9e 49 7a ] 1265 16:09:52.497473 Feb 2, 2024 17:09:52.497473000 CET 127.0.0.1 45126 127.0.1.1 4729 GSMTAP 210 ✓ GRE(e0083f9b) Enqueueing LLC-PDU len=39 SAPI=GMM radio_prio=1
So it's 1 LLC frame of 8 bytes, and 1 LLC frame of 39 bytes, that's 47 bytes of data in total.
Then, in the pcap we can see that only the Attach Compl is transmitted with UL DATA block BSN=0 and CV=0.
However, the Act PDP Context Req is not included in the encoded BSN=0 UL data block, and ofc no extra block is expected because the MS sent the first one with CV=0.
This happens because our gprs_rlcmac_ul_tbf_calculate_cv() function calculates it can fit both in 1 CS4 UL data block:
20240202172854510 DRLCMAC NOTICE tbf_ul.c:507 TBF(UL:NR-3:TLLI-e172f149) calculate_cv blk_state_init: tx_cs=4 bs_cv_max=15 blk_data_len=50 │ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 20240202172854510 DRLCMAC NOTICE tbf_ul.c:608 TBF(UL:NR-3:TLLI-e172f149) calculate_cv after pq[0][0]: blk_count=0 offset=49 │52: modem4: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 500 20240202172854510 DRLCMAC NOTICE tbf_ul.c:615 TBF(UL:NR-3:TLLI-e172f149) calculate_cv after done: blk_count=0 offset=49 │ link/none 20240202172854510 DRLCMAC NOTICE tbf_ul.c:627 TBF(UL:NR-3:TLLI-e172f149) calculate_cv after adapting: : blk_count=1 offset=0 │root@mssdr-ms:/home/ubuntu# ip addr 20240202172854510 DRLCMAC NOTICE tbf_ul.c:629 TBF(UL:NR-3:TLLI-e172f149) blk_count after adapting: blk_count=1 offset=0 -> x=0 bs_cv_max=15
Taking into account we are in contention resolution, it's 54-4 bytes which can fit. This whole thing needs to be checked for wrong calculations. Starting by the fact that GPRS may not allow to send multiple LLC frames in one RLC/MAC block? Maybe only in EGPRS it's allowed? I need to check.
So what needs to be done:
1- Check if several LLC frames can be put inside 1 RLC/MAC UL data block.
2- If answer is no, fix gprs_rlcmac_ul_tbf_calculate_cv() to return CV=1 in this case.
3- If answer is yes, then check if the size calculations are correct in gprs_rlcmac_ul_tbf_calculate_cv()
4- if everything is fine, then we may have a bug in the block encoder.
The quick hack for now is to avoid using UL CS4, that should prevent this incident to happen since it's the only block size which gprs_rlcmac_ul_tbf_calculate_cv() considers can fit into 1 block.
