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: Pedro B. <pe...@gm...> - 2015-09-21 13:48:06
|
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
>
|
