[srslte-users] service reject error

Thu Jun 10 17:26:45 UTC 2021

Hi Pedro,

Yes the patch is working but only for a limited number of service
requests it seems.

So using zmq with a ue dl loss set as follows:
[channel.dl.rlf]
enable        = true
t_on_ms       = 45000
t_off_ms      = 60000

and a 1 pps uplink ping running from the ue to exercise the service request

Type <t> to view trace
RACH:  tti=341, cc=0, preamble=38, offset=0, temp_crnti=0x46
User 0x46 connected
Disconnecting rnti=0x46.
RACH:  tti=6741, cc=0, preamble=40, offset=0, temp_crnti=0x47
User 0x47 connected
Disconnecting rnti=0x47.
RACH:  tti=6901, cc=0, preamble=8, offset=0, temp_crnti=0x48
User 0x48 connected
Disconnecting rnti=0x48.
RACH:  tti=3381, cc=0, preamble=12, offset=0, temp_crnti=0x49
User 0x49 connected
Disconnecting rnti=0x49.
RACH:  tti=7221, cc=0, preamble=43, offset=0, temp_crnti=0x4a
User 0x4a connected
Disconnecting rnti=0x4a.
RACH:  tti=5301, cc=0, preamble=49, offset=0, temp_crnti=0x4b
User 0x4b connected
Disconnecting rnti=0x4b.
RACH:  tti=5381, cc=0, preamble=45, offset=0, temp_crnti=0x4c
User 0x4c connected
Disconnecting rnti=0x4c.
RACH:  tti=661, cc=0, preamble=50, offset=0, temp_crnti=0x4d
User 0x4d connected
Disconnecting rnti=0x4d.
RACH:  tti=8661, cc=0, preamble=12, offset=0, temp_crnti=0x4e
User 0x4e connected
Disconnecting rnti=0x4e.
RACH:  tti=1301, cc=0, preamble=13, offset=0, temp_crnti=0x4f
User 0x4f connected
Disconnecting rnti=0x4f.
RACH:  tti=3381, cc=0, preamble=47, offset=0, temp_crnti=0x50
SCTP Association Shutdown. Association: 0

17:08:56.647856 [NAS    ] [I] Integrity check ok. Local: count=0,
Received: count=0
17:08:56.887503 [NAS    ] [I] Integrity check ok. Local: count=1,
Received: count=1
17:09:39.709587 [NAS    ] [I] Local: count=2, Estimated: count=4, msg[1]=4
17:09:39.709666 [NAS    ] [I] Integrity check ok. Local: count=2,
Received: count=4
17:10:20.656646 [NAS    ] [I] Local: count=5, Estimated: count=7, msg[1]=7
17:10:20.656845 [NAS    ] [I] Integrity check ok. Local: count=5,
Received: count=7
17:10:51.399264 [NAS    ] [I] Local: count=8, Estimated: count=10, msg[1]=10
17:10:51.399424 [NAS    ] [I] Integrity check ok. Local: count=8,
Received: count=10
17:11:32.335865 [NAS    ] [I] Local: count=11, Estimated: count=13,
msg[1]=13
17:11:32.336105 [NAS    ] [I] Integrity check ok. Local: count=11,
Received: count=13
17:12:03.036583 [NAS    ] [I] Local: count=14, Estimated: count=16,
msg[1]=16
17:12:03.036885 [NAS    ] [I] Integrity check ok. Local: count=14,
Received: count=16
17:12:13.207314 [NAS    ] [I] Local: count=17, Estimated: count=17,
msg[1]=17
17:12:13.207525 [NAS    ] [I] Integrity check ok. Local: count=17,
Received: count=17
17:12:43.993119 [NAS    ] [I] Local: count=18, Estimated: count=20,
msg[1]=20
17:12:43.993281 [NAS    ] [I] Integrity check ok. Local: count=18,
Received: count=20
17:13:18.847265 [NAS    ] [I] Local: count=21, Estimated: count=26,
msg[1]=26
17:13:18.847495 [NAS    ] [I] Integrity check ok. Local: count=21,
Received: count=26
17:13:55.711499 [NAS    ] [I] Local: count=27, Estimated: count=29,
msg[1]=29
17:13:55.711607 [NAS    ] [I] Integrity check ok. Local: count=27,
Received: count=29
17:14:36.641715 [NAS    ] [I] Local: count=30, Estimated: count=0,
msg[1]=0        <<< here estimated goes to 0 ???
17:14:36.641797 [NAS    ] [W] Short integrity check failure. Local:
count=0, [6c 7f 67 12], Received: count=0, [99 78]

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 --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20210610/f75de30c/attachment.htm>
-------------- 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/f75de30c/attachment.sig>