Re: [Openlte-discuss] Connecting OpenLTE to Moto G3

[Pedro B. <pe...@gm...>]

I believe that this part of the patch is doing it (just copying the seq_num
actually). Anyway the problem with SecurityModeCommand seems to be
"resolved" with the patch, what I do not know is what is supposed to happen
next, that is what I was hoping to see in your pcap / logs.

@@ -1026,15 +1030,15 @@ void
LTE_fdd_enb_mme::parse_service_request(LIBLTE_BYTE_MSG_STRUCT *msg,
                                       user->get_auth_vec()->nas_count_ul,
                                       user->get_c_rnti(),

 LTE_fdd_enb_rb_text[rb->get_rb_id()]);
+        }

-            // Resolve sequence number mismatch
-            auth_vec->nas_count_ul = service_req.ksi_and_seq_num.seq_num;
-            hss_auth_vec           =
hss->regenerate_enb_security_data(user->get_id(), auth_vec->nas_count_ul);
-            for(i=0; i<32; i++)
-            {
-                auth_vec->k_rrc_enc[i] = hss_auth_vec->k_rrc_enc[i];
-                auth_vec->k_rrc_int[i] = hss_auth_vec->k_rrc_int[i];
-            }
+        // Resolve sequence number mismatch
+        auth_vec->nas_count_ul = service_req.ksi_and_seq_num.seq_num;
+        hss_auth_vec           =
hss->regenerate_enb_security_data(user->get_id(), auth_vec->nas_count_ul);
+        for(i=0; i<32; i++)
+        {
+            auth_vec->k_rrc_enc[i] = hss_auth_vec->k_rrc_enc[i];
+            auth_vec->k_rrc_int[i] = hss_auth_vec->k_rrc_int[i];
         }

         // Set the state

Thanks!


--
Pedro Batista

On Mon, Sep 21, 2015 at 5:48 PM, Mikhail Gudkov <gm...@gm...> wrote:

> You need "calc" current ue nas count and regenerate auth vector (every
> service request)
> 21.09.2015 17:47 пользователь "Pedro Batista" <pe...@gm...> написал:
>
> Hello Mikhail, I do not know if I understood you, but you say I need to
>> correct liblte_mme_unpack_ksi_and_sequence_number_ie?
>>
>> I think OpenLTE could have a problem with seq_num, but for the firsts
>> service requests the NAS count fit on the 5 bits, so I though it should
>> work.
>>
>> Did you successfully ran OpenLTE? Can you share a copy of your pcap and
>> log files? I am really curious on what is supposed to happen and what is
>> happening with mine.
>>
>> Thanks!
>>
>>
>> --
>> Pedro Batista
>>
>> On Sun, Sep 20, 2015 at 4:47 AM, Mikhail Gudkov <gm...@gm...> wrote:
>>
>>>
>>> On Sat, Sep 19, 2015 at 12:56 AM, Pedro Batista <pe...@gm...>
>>> wrote:
>>>
>>>> Hello, I have been trying to connect my Moto G3 (from Brazil) to
>>>> OpenLTE. I tried the 00.19.00 version and got one ping to 8.8.8.8, but
>>>> after it all others ping get timeout. For this test I have annexed the log
>>>> files and configuration DB on [1].
>>>>
>>>> From the pcap file I can see the following:
>>>>
>>>> 1) The UE attach to the OpenLTE and all seems compatible with OpenLTE
>>>> up to the UE "Activate default EPS bearer context accept" message.
>>>>
>>>> 2) After it the UE continuously sends
>>>> RRCConnectionReestablishmentRequest which is not implemented on OpenLTE
>>>> until it finally sends a RRCConnectionRequest which is handled by OpenLTE.
>>>> The RRC connection is established and the UE sends a "Service request".
>>>>
>>>> 3) OpenLTE sends a SecurityModeCommand and the UE return a
>>>> SecurityModeComplete.
>>>>
>>>> 4) OpenLTE then sends a "Activate dedicated EPS bearer context request"
>>>> request which is rejected by the UE with the message "Syntactical errors in
>>>> packet filter(s)".
>>>>
>>>> 5) After some time step 2 is repeated.
>>>>
>>>> 6) Then OpenLTE sends a SecurityModeCommand but the UE reject with
>>>> SecurityModeFailure.
>>>>
>>>> Steps 5 and 6 are repeated indefinitely.
>>>>
>>>> -------------
>>>>
>>>> I tracked the error 4 to the following patch, which mainly sets the
>>>> eval_precedence and the UE stop complaining about the "syntactical error".
>>>>
>>>> diff --git a/LTE_fdd_enodeb/src/LTE_fdd_enb_mme.cc
>>>> b/LTE_fdd_enodeb/src/LTE_fdd_enb_mme.cc
>>>> index 35ca6f2..d6fe5a3 100644
>>>> --- a/LTE_fdd_enodeb/src/LTE_fdd_enb_mme.cc
>>>> +++ b/LTE_fdd_enodeb/src/LTE_fdd_enb_mme.cc
>>>> @@ -1767,6 +1771,13 @@ void
>>>> LTE_fdd_enb_mme::send_activate_dedicated_eps_bearer_context_request(LTE_fdd
>>>>      }else{
>>>>          act_ded_eps_bearer_context_req.eps_bearer_id =
>>>> user->get_eps_bearer_id()+1;
>>>>      }
>>>> +    act_ded_eps_bearer_context_req.transaction_id_present
>>>>        = true;
>>>> +    act_ded_eps_bearer_context_req.negotiated_qos_present
>>>>        = false;
>>>> +    act_ded_eps_bearer_context_req.llc_sapi_present
>>>>        = false;
>>>> +    act_ded_eps_bearer_context_req.radio_prio_present
>>>>        = false;
>>>> +    act_ded_eps_bearer_context_req.packet_flow_id_present
>>>>        = false;
>>>> +    act_ded_eps_bearer_context_req.protocol_cnfg_opts_present
>>>>        = false;
>>>> +
>>>>      act_ded_eps_bearer_context_req.proc_transaction_id
>>>>       = 0;
>>>>      act_ded_eps_bearer_context_req.linked_eps_bearer_id
>>>>        = user->get_eps_bearer_id();
>>>>      act_ded_eps_bearer_context_req.eps_qos.qci
>>>>       = 9;
>>>> @@ -1777,19 +1788,19 @@ void
>>>> LTE_fdd_enb_mme::send_activate_dedicated_eps_bearer_context_request(LTE_fdd
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list_size
>>>>       = 3;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[0].id
>>>>        = 1;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[0].dir
>>>>       = LIBLTE_MME_TFT_PACKET_FILTER_DIRECTION_BIDIRECTIONAL;
>>>> -
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[0].eval_precedence =
>>>> 0;
>>>> +
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[0].eval_precedence =
>>>> 1;
>>>>
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[0].filter_size     =
>>>> 2;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[0].filter[0]
>>>>       =
>>>> LIBLTE_MME_TFT_PACKET_FILTER_COMPONENT_TYPE_ID_PROTOCOL_ID_NEXT_HEADER_TYPE;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[0].filter[1]
>>>>       = IPPROTO_UDP;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[1].id
>>>>        = 2;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[1].dir
>>>>       = LIBLTE_MME_TFT_PACKET_FILTER_DIRECTION_BIDIRECTIONAL;
>>>> -
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[1].eval_precedence =
>>>> 0;
>>>> +
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[1].eval_precedence =
>>>> 2;
>>>>
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[1].filter_size     =
>>>> 2;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[1].filter[0]
>>>>       =
>>>> LIBLTE_MME_TFT_PACKET_FILTER_COMPONENT_TYPE_ID_PROTOCOL_ID_NEXT_HEADER_TYPE;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[1].filter[1]
>>>>       = IPPROTO_TCP;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[2].id
>>>>        = 3;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[2].dir
>>>>       = LIBLTE_MME_TFT_PACKET_FILTER_DIRECTION_BIDIRECTIONAL;
>>>> -
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[2].eval_precedence =
>>>> 0;
>>>> +
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[2].eval_precedence =
>>>> 3;
>>>>
>>>>  act_ded_eps_bearer_context_req.tft.packet_filter_list[2].filter_size     =
>>>> 2;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[2].filter[0]
>>>>       =
>>>> LIBLTE_MME_TFT_PACKET_FILTER_COMPONENT_TYPE_ID_PROTOCOL_ID_NEXT_HEADER_TYPE;
>>>>      act_ded_eps_bearer_context_req.tft.packet_filter_list[2].filter[1]
>>>>       = IPPROTO_ICMP;
>>>>
>>>> It seems like the error 6 is due incorrect NAS COUNT UL the following
>>>> patch makes it go away.
>>>>
>>>> diff --git a/LTE_fdd_enodeb/src/LTE_fdd_enb_mme.cc
>>>> b/LTE_fdd_enodeb/src/LTE_fdd_enb_mme.cc
>>>> index 35ca6f2..d6fe5a3 100644
>>>> --- a/LTE_fdd_enodeb/src/LTE_fdd_enb_mme.cc
>>>> +++ b/LTE_fdd_enodeb/src/LTE_fdd_enb_mme.cc
>>>> @@ -194,6 +194,7 @@ void
>>>> LTE_fdd_enb_mme::handle_nas_msg(LTE_FDD_ENB_MME_NAS_MSG_READY_MSG_STRUCT *n
>>>>      LIBLTE_BYTE_MSG_STRUCT *msg;
>>>>      uint8                   pd;
>>>>      uint8                   msg_type;
>>>> +    bool                    from_auth_response = false;
>>>>
>>>>      if(LTE_FDD_ENB_ERROR_NONE ==
>>>> nas_msg->rb->get_next_mme_nas_msg(&msg))
>>>>      {
>>>> @@ -221,6 +222,7 @@ void
>>>> LTE_fdd_enb_mme::handle_nas_msg(LTE_FDD_ENB_MME_NAS_MSG_READY_MSG_STRUCT *n
>>>>              break;
>>>>          case LIBLTE_MME_MSG_TYPE_AUTHENTICATION_RESPONSE:
>>>>              parse_authentication_response(msg, nas_msg->user,
>>>> nas_msg->rb);
>>>> +            from_auth_response = true;
>>>>              break;
>>>>          case LIBLTE_MME_MSG_TYPE_DETACH_REQUEST:
>>>>              parse_detach_request(msg, nas_msg->user, nas_msg->rb);
>>>> @@ -377,7 +379,8 @@ void
>>>> LTE_fdd_enb_mme::handle_nas_msg(LTE_FDD_ENB_MME_NAS_MSG_READY_MSG_STRUCT *n
>>>>          }
>>>>
>>>>          // Increment the uplink NAS count
>>>> -        nas_msg->user->increment_nas_count_ul();
>>>> +        if (!from_auth_response)
>>>> +            nas_msg->user->increment_nas_count_ul();
>>>>
>>>>          // Delete the NAS message
>>>>          nas_msg->rb->delete_next_mme_nas_msg();
>>>> @@ -486,6 +489,7 @@ void
>>>> LTE_fdd_enb_mme::parse_attach_complete(LIBLTE_BYTE_MSG_STRUCT *msg,
>>>>      switch(msg_type)
>>>>      {
>>>>      case
>>>> LIBLTE_MME_MSG_TYPE_ACTIVATE_DEFAULT_EPS_BEARER_CONTEXT_ACCEPT:
>>>> +        user->increment_nas_count_ul();
>>>>
>>>>  parse_activate_default_eps_bearer_context_accept(&attach_comp.esm_msg,
>>>> user, rb);
>>>>          break;
>>>>      default:
>>>> @@ -1026,15 +1030,15 @@ void
>>>> LTE_fdd_enb_mme::parse_service_request(LIBLTE_BYTE_MSG_STRUCT *msg,
>>>>
>>>>  user->get_auth_vec()->nas_count_ul,
>>>>                                        user->get_c_rnti(),
>>>>
>>>>  LTE_fdd_enb_rb_text[rb->get_rb_id()]);
>>>> +        }
>>>>
>>>> -            // Resolve sequence number mismatch
>>>> -            auth_vec->nas_count_ul =
>>>> service_req.ksi_and_seq_num.seq_num;
>>>> -            hss_auth_vec           =
>>>> hss->regenerate_enb_security_data(user->get_id(), auth_vec->nas_count_ul);
>>>> -            for(i=0; i<32; i++)
>>>> -            {
>>>> -                auth_vec->k_rrc_enc[i] = hss_auth_vec->k_rrc_enc[i];
>>>> -                auth_vec->k_rrc_int[i] = hss_auth_vec->k_rrc_int[i];
>>>> -            }
>>>> +        // Resolve sequence number mismatch
>>>> +        auth_vec->nas_count_ul = service_req.ksi_and_seq_num.seq_num;
>>>> +        hss_auth_vec           =
>>>> hss->regenerate_enb_security_data(user->get_id(), auth_vec->nas_count_ul);
>>>> +        for(i=0; i<32; i++)
>>>> +        {
>>>> +            auth_vec->k_rrc_enc[i] = hss_auth_vec->k_rrc_enc[i];
>>>> +            auth_vec->k_rrc_int[i] = hss_auth_vec->k_rrc_int[i];
>>>>          }
>>>>
>>>>          // Set the state
>>>>
>>>> After it I ran OpenLTE again (the logs are annexed in [2]) and I see
>>>> steps 1-3 with the same behavior, but it follows with
>>>>
>>>> 4p) OpenLTE then sends a "Activate dedicated EPS bearer context
>>>> request" request which is accepted by the UE, but on OpenLTE MME log file I
>>>> got the message "Not handling Activate Dedicated EPS Bearer Context Accept".
>>>>
>>>> 5p) After some time steps 2-3 are repeated without errors.
>>>>
>>>> 6p) OpenLTE sends a "Activate dedicated EPS bearer context request"
>>>> request but there is no response from the UE.
>>>>
>>>> Steps 5p and 6p are repeated indefinitely.
>>>>
>>>> Thanks!
>>>>
>>>> [1]
>>>> https://drive.google.com/file/d/0BwRZi_IlQaUvQnFHd3VFckZOVDhOWW4yb1N6VGFoWXJ4dkc4/view?usp=sharing
>>>> [2]
>>>> https://drive.google.com/file/d/0BwRZi_IlQaUvTDBhWWFKUDBMc3RwaWx0TTJjeVFTTjFnbkdR/view?usp=sharing
>>>> --
>>>> Pedro Batista
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Openlte-discuss mailing list
>>>> Ope...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/openlte-discuss
>>>>
>>>>
>>> Nas count is 24 bit long and service_req.ksi_and_seq_num.seq_num is only
>>> 5 bit long. You need to restore other bits in service request
>>>
>>
>>