[srsran-users] NAS Short MAC invalid issue

Pedro Alvarez pedro.alvarez at srs.io
Tue Nov 15 16:22:48 UTC 2022


Accidentally did not hit "reply all", sorry Joe for getting this email
twice...
---

I think the quickest way to get to the bottom of this is to take a
systematic approach to narrow down the problem.
My approach when facing an integrity issue is usually the following:

1 - Double check the message. This is usually the most common issue, the
message itself gets corrupted and  integrity fails because of this.
2 - Double check the keys. If they don't match then check the inputs for
them.
3 - Double check the MAC-I parameter inputs.

While the logging in the PDCP is made to get this information quickly, the
NAS needs some patches to get this info.
Could you try out this patch please Joe? Both the EPC and UE NAS at debug,
everything else at warning.

Note also, that the count printed by the EPC is estimated, so it is
possible that there is still a mismatch in the count.
We need to check the UE's and the EPC's logs to rule that out.

On Tue, Nov 15, 2022 at 3:20 PM J Giovatto <jgiovatto at adjacentlink.com>
wrote:

> On 11/15/22 05:19, Andre Puschmann wrote:
> > Hey,
> >
> > On 14/11/22 17:02, J Giovatto wrote:
> >> Yes running zmq, I have confirmed that earfcn = 2850 and only earfcn
> >> = 2850 is in play.
> >
> > Ok, good.
> >
> >>
> >> I have attached a patch for zmq that will create a 5 min DL blackout
> >> that you can try.
> >
> > Well, 5min, this is long and likely longer than the max time the UE
> > will do a reestablishment. But that depends on your configs of course.
> Ill try to find the min duration for this to happen but 5min is a sure
> thing.
> >
> > For this to replicate I would appreciate you open an issue in github
> > and post all configs and full logs. Also instead of patching the code
> > could you try to replicate this with the channel emulator, there is a
> > RLF option that should do exactly what you need.
>
>
> I tried to set the enb to do just that but the link never broke thinking
> 30 on and 300 sec off
>
> [channel.dl.rlf]
> enable        = true
> t_on_ms       = 30000
> t_off_ms      = 300000
>
> >
> > This would also be helpful to do a git-bisect in case it's a
> > regression introduced by a commit.
>
>
> Sure thing, Thanks
>
> >
> > Thanks
> > Andre
> >
> >>
> >> 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/6ab047f5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-nas-improve-logging-to-help-debugging-integrity-issu.patch
Type: text/x-patch
Size: 2481 bytes
Desc: not available
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20221115/6ab047f5/attachment.bin>


More information about the srsran-users mailing list