Re: [Openlte-discuss] Connecting OpenLTE to Moto G3
An open source 3GPP LTE implementation.
Status: Alpha
Brought to you by:
bwojtowi
Menu
▾
▴
Re: [Openlte-discuss] Connecting OpenLTE to Moto G3
|
From: Mikhail G. <gm...@gm...> - 2015-09-21 20:48:20
|
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
>>
>
>
|
