[srslte-users] service reject error

[J Giovatto]

Hi Pedro,

Now I see what was happening the service request count is proportional
to the UL packet rate and duration of the outage thats why the longer
outages seemed so relevant initially.

By using "ping -i .2" I can generate more service requests per blackout
period to force the issue.

Kudos to whomever added these console logs to make it more obvious
"Service Request with cause mo-Data"
"RRC connection for Service Request failed"


I adjusted the estimated count logic to account for roll over of the
sender side 5bit ul_count vs the local ul_count.

Seems to work now so far.

Local: count=352, Estimated: count=358, msg[1]=6, prev=0
Service Request -- Short MAC valid
Service Request -- User is ECM DISCONNECTED
UE previously assigned IP: 172.16.0.2
Generating KeNB with UL NAS COUNT: 358


But I not sure this will work for an extended blackout period with a
high UL packet rate where the ul_count rolls over more than once and
exceeds 32 bit size, or if there is way to tell.

Updated patch attached.

Joe



On 6/8/21 12:14 PM, Pedro Alvarez wrote:
> Hi Joe --
>
> Thanks a lot for reporting this. I think the issue here is in the way
> the short MAC integrity is calculated at the MME.
> Basically, the MME (and the UE) need to keep an NAS COUNT, which can
> be decomposed into an overflow counter (16 most significant bits) and
> an NAS sequence number (8 least significant bits).
>
> To check the integrity we should do the following, see section 4.4.3.3:
>
>> The receiver shall use the NAS sequence number included in the received message (or estimated from the 5 bits of the
>> NAS sequence number received in the message) and an estimate for the NAS overflow counter as defined in
>> subclause 4.4.3.1 to form the NAS COUNT input to the integrity verification algorithm.
> We correctly used the received sequence number in the normal integrity
> protection checks, but it seems that the short integrity check is
> incorrect.
> Could you try the attached patch?
>
> On Mon, Jun 7, 2021 at 8:33 PM J Giovatto <jgiovatto at adjacentlink.com> wrote:
>> Hi Folks
>>
>> I was wondering if anyone else has seen this...
>>
>> To reproduce:
>>
>> 1) with a "ping 172.16.0.101 -p aa" running to the epc, break rf link
>> between established ue/enb pair to the epc for 2 minutes or more.
>>
>> 2) re-establish rf link, ping completion never resumes.
>>
>>
>> Log highlights below...
>>
>> epc log ==================================
>>
>> 18:24:17.322551 [NAS    ] [W] Short integrity check failure. Local:
>> count=3, [88 0d ae 3c], Received: count=6, [75 06]
>>
>> ue log ===================================
>>
>> 18:24:17.328535 [NAS    ] [I] Received service reject with EMM cause=0x9
>> and t3446=0
>>
>> 18:24:18.109605 [RLC    ] [I] SRB1 SN=0 outside rx window [1:513] - AM
>> discarding
>>
>> enb log ==================================
>>
>> 8:24:17.323345 [PDCP   ] [I] TX SRB1 PDU, SN=0, integrity=none,
>> encryption=none
>>
>> Thanks
>>
>> Joe
>> _______________________________________________
>> srslte-users mailing list
>> srslte-users at lists.softwareradiosystems.com
>> https://lists.softwareradiosystems.com/mailman/listinfo/srslte-users


-------------- next part --------------
A non-text attachment was scrubbed...
Name: nas_count_ro.patch
Type: text/x-patch
Size: 3623 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20210610/296b77dd/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20210610/296b77dd/attachment.sig>