This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/nextepc@lists.osmocom.org/.
Sukchan Lee acetcom at gmail.comHi Harald, For the most part, you need to see the UNION definitions in src/mme/mme_context.h as below. 348 union { 349 struct { 350 ED3(uint8_t spare;, 351 uint16_t overflow;, 352 uint8_t sqn;) 353 } __attribute__ ((packed)); 354 uint32_t i32; 355 } ul_count; Therefore, increasing SQN will also increase ul_count.i32. Let me add the comments in src/mme/nas_security.c /* If SQN exeeds 1 bytes and turn in once again, Overflow is increased */ 197 if (mme_ue->ul_count.sqn > h->sequence_number) 198 mme_ue->ul_count.overflow++; /* Always set SQN from UE's SQN as below */ 199 mme_ue->ul_count.sqn = h->sequence_number; Let me know if I have misunderstood anything. Thanks a lot! Best Regards, Sukchan On Sat, Jul 13, 2019 at 10:19 PM Harald Welte <laforge at gnumonks.org> wrote: > Hi Sukchan and list, > > I'm currently reading the MME code and I'm having some trouble > understanding > the handling of the uplink counter for NAS security. > > I only see mme_ue->ul_count.i32 ever being set to '0' when a new security > context is used. But I don't see it ever being incremented? I only see > ul_count.sqn incremented, but then the nas_mac_calculate() always gets > ul_count.i32 passed as input. > > So I'm somehow not understanding how the MAC can ever verify on any uplink > message beyond/after the first one which establishes a new security > context. > > What am I missing? Thanks for your insight! > > -- > - Harald Welte <laforge at gnumonks.org> > http://laforge.gnumonks.org/ > > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/nextepc/attachments/20190714/7b61647c/attachment.htm>