[srsran-users] NAS Short MAC invalid issue

Tue Nov 15 14:55:59 UTC 2022

Hi

EPC logs show this warning.

022-11-15T14:46:18.649845 [S1AP   ] [I] Received Initial UE message -- 
Service Request
2022-11-15T14:46:18.649847 [NAS    ] [I] Service request -- S-TMSI 
0x8ec877b5
2022-11-15T14:46:18.649849 [NAS    ] [I] Service request -- eNB UE S1AP Id 2
2022-11-15T14:46:18.649851 [S1AP   ] [D] Found IMSI 999700123450001 from 
M-TMSI 0x8ec877b5
2022-11-15T14:46:18.649910 [NAS    ] [W] Short integrity check failure. 
Local: count=27, [22 d5 1a ff], Received: count=27, [2c 36]
2022-11-15T14:46:18.649911 [NAS    ] [I] Service Request -- Short MAC 
invalid
2022-11-15T14:46:18.649913 [S1AP   ] [D] Saved UE context corresponding 
to MME UE S1AP Id 2
2022-11-15T14:46:18.649914 [S1AP   ] [D] Added UE with MME-UE S1AP Id 2 
to eNB with association 515
2022-11-15T14:46:18.649915 [S1AP   ] [D] Sending message to eNB with 
SCTP association 515. MME UE S1AP ID 2, eNB UE S1AP ID 2
2022-11-15T14:46:18.649920 [S1AP   ] [D] Transmitting S1AP PDU. eNB SCTP 
association Id: 515
2022-11-15T14:46:18.649965 [NAS    ] [W] Service Request -- Short MAC 
invalid. Sending service reject.
2022-11-15T14:46:18.649965 [NAS    ] [I] Service Reject -- 
eNB_UE_S1AP_ID 2 MME_UE_S1AP_ID 2.
2022-11-15T14:46:18.649967 [S1AP   ] [D] Waiting for S1-MME or S11 Message

Im happy to try add logs etc.

Thanks for looking.

Joe

On 11/15/22 07:36, Pedro Alvarez wrote:
> Hi Joe --
>
> I think there is a bug in the UE that you might be triggering if you 
> create a 5min blackout in the DL.
>
> Basically, in the Attach Request, Service Request (and I think the TAU 
> request too), you are not supposed to increment the NAS COUNT until 
> the RRC is in the RRC Connected state.
> This is because if those messages are lost, the sync between the UE 
> and MME will be lost.
>
> See the following from the standard TS 24.301 V14.10.0, section 4.4.3 
> "Handling of NAS COUNT and NAS sequence number":
> > The NAS sequence number part of the NAS COUNT shall be exchanged 
> between the UE and the MME as part of the
> > NAS signalling. After each new or retransmitted outbound security 
> protected NAS message, the sender shall increase
> > the NAS COUNT number by one, *except for the initial NAS messages if 
> the lower layers indicated the failure to
> *>*establish the RRC connection (see 3GPP TS 36.331 [22]).*
>
> Could you check if the NAS COUNT matches when you do the blackout, please?
> If that is not the case, we will have to do further debugging.
>
> Regards, Pedro.
>
>
>
>
>
>
> On Tue, Nov 15, 2022 at 10:28 AM J Giovatto 
> <jgiovatto at adjacentlink.com> wrote:
>
>     On 11/13/22 04:23, Andre Puschmann wrote:
>     > Hi Joe,
>     >
>     > On 11/11/22 19:52, J Giovatto wrote:
>     >> I ran into this case where if after a successful attach (rinti
>     0x46)
>     >> the ue looses the link with the enb for 5 minute with a constant
>     >> uplink ping (1pps) to the epc.
>     >>
>     >> Upon re-establish link (rinti 0x47) the ue does attach but con no
>     >> longer complete the ping. I believe that uplink traffic is
>     required
>     >> to cause this, w/o traffic
>     >
>     > I am assuming you run this with ZMQ radios. Could you please check
>     > that you've configured both UE and eNB to use the same EARFCNs?
>     Note
>     > that it's possible to have different values configured and the ZMQ
>     > radios will still connect.
>     >
>     > For reestablishment or anything else related to mobility we need to
>     > make sure the that the EARFCN values are correct and match because
>     > they are parameters in all security related functions.
>     >
>     > Please check and run again, if the issue is still present,
>     please send
>     > full logs for all three components.
>
>     Yes running zmq, I have confirmed that earfcn = 2850 and only
>     earfcn =
>     2850 is in play.
>
>     I have attached a patch for zmq that will create a 5 min DL blackout
>     that you can try.
>
>     Seems like it ony happens with UL pending traffic (ping the epc).
>
>     Thanks for looking.
>
>
>     Joe
>
>
>     >
>     >
>     >> Maybe this is related to issue #960 ?
>     >
>     > I don't think it is related to
>     > https://github.com/srsran/srsRAN/issues/960
>     >
>     > But have a look at the above and we check further if needed.
>     >
>     > Thanks
>     > Andre
>
>
>     _______________________________________________
>     srsran-users mailing list
>     srsran-users at lists.srsran.com
>     https://lists.srsran.com/mailman/listinfo/srsran-users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20221115/f3baacf0/attachment-0001.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/20221115/f3baacf0/attachment-0001.sig>