Commit c383e50b authored by Cedric Roux's avatar Cedric Roux
Browse files

This commit rejects an UE that connects by sending RRCConnectionRequest with S-TMSI.

The observed behavior (samsung phone, lte dongle, sequans box) is that the UE
keeps connecting over and over again.
parent 477104ec
......@@ -2110,6 +2110,67 @@ do_RRCConnectionReestablishmentReject(
return((enc_rval.encoded+7)/8);
}
//------------------------------------------------------------------------------
uint8_t
do_RRCConnectionReject(
uint8_t Mod_id,
uint8_t* const buffer)
//------------------------------------------------------------------------------
{
asn_enc_rval_t enc_rval;
DL_CCCH_Message_t dl_ccch_msg;
RRCConnectionReject_t *rrcConnectionReject;
memset((void *)&dl_ccch_msg,0,sizeof(DL_CCCH_Message_t));
dl_ccch_msg.message.present = DL_CCCH_MessageType_PR_c1;
dl_ccch_msg.message.choice.c1.present = DL_CCCH_MessageType__c1_PR_rrcConnectionReject;
rrcConnectionReject = &dl_ccch_msg.message.choice.c1.choice.rrcConnectionReject;
// RRCConnectionReject
rrcConnectionReject->criticalExtensions.present = RRCConnectionReject__criticalExtensions_PR_c1;
rrcConnectionReject->criticalExtensions.choice.c1.present = RRCConnectionReject__criticalExtensions__c1_PR_rrcConnectionReject_r8;
/* let's put a wait time of 1s for the moment */
rrcConnectionReject->criticalExtensions.choice.c1.choice.rrcConnectionReject_r8.waitTime = 1;
#ifdef XER_PRINT
xer_fprint(stdout, &asn_DEF_DL_CCCH_Message, (void*)&dl_ccch_msg);
#endif
enc_rval = uper_encode_to_buffer(&asn_DEF_DL_CCCH_Message,
(void*)&dl_ccch_msg,
buffer,
100);
AssertFatal (enc_rval.encoded > 0, "ASN1 message encoding failed (%s, %ld)!\n",
enc_rval.failed_type->name, enc_rval.encoded);
#if defined(ENABLE_ITTI)
# if !defined(DISABLE_XER_SPRINT)
{
char message_string[20000];
size_t message_string_size;
if ((message_string_size = xer_sprint(message_string, sizeof(message_string), &asn_DEF_DL_CCCH_Message, (void *) &dl_ccch_msg)) > 0) {
MessageDef *msg_p;
msg_p = itti_alloc_new_message_sized (TASK_RRC_ENB, RRC_DL_CCCH, message_string_size + sizeof (IttiMsgText));
msg_p->ittiMsg.rrc_dl_ccch.size = message_string_size;
memcpy(&msg_p->ittiMsg.rrc_dl_ccch.text, message_string, message_string_size);
itti_send_msg_to_task(TASK_UNKNOWN, Mod_id, msg_p);
}
}
# endif
#endif
#ifdef USER_MODE
LOG_D(RRC,"RRCConnectionReject Encoded %d bits (%d bytes)\n",
enc_rval.encoded,(enc_rval.encoded+7)/8);
#endif
return((enc_rval.encoded+7)/8);
}
uint8_t do_RRCConnectionRelease(
uint8_t Mod_id,
uint8_t *buffer,
......
......@@ -218,6 +218,16 @@ do_RRCConnectionReestablishmentReject(
uint8_t Mod_id,
uint8_t* const buffer);
/**
\brief Generate an RRCConnectionReject DL-CCCH-Message (eNB).
@param Mod_id Module ID of eNB
@param buffer Pointer to PER-encoded ASN.1 description of DL-CCCH-Message PDU
@returns Size of encoded bit stream in bytes*/
uint8_t
do_RRCConnectionReject(
uint8_t Mod_id,
uint8_t* const buffer);
/**
\brief Generate an RRCConnectionRequest UL-CCCH-Message (UE) based on random string or S-TMSI. This
routine only generates an mo-data establishment cause.
......
......@@ -963,6 +963,49 @@ rrc_eNB_generate_UECapabilityEnquiry(
}
//-----------------------------------------------------------------------------
void
rrc_eNB_generate_RRCConnectionReject(
const protocol_ctxt_t* const ctxt_pP,
rrc_eNB_ue_context_t* const ue_context_pP,
const int CC_id
)
//-----------------------------------------------------------------------------
{
#ifdef RRC_MSG_PRINT
int cnt;
#endif
eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size =
do_RRCConnectionReject(ctxt_pP->module_id,
(uint8_t*) eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.Payload);
#ifdef RRC_MSG_PRINT
LOG_F(RRC,"[MSG] RRCConnectionReject\n");
for (cnt = 0; cnt < eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size; cnt++) {
LOG_F(RRC,"%02x ", ((uint8_t*)eNB_rrc_inst[ctxt_pP->module_id].Srb0.Tx_buffer.Payload)[cnt]);
}
LOG_F(RRC,"\n");
#endif
MSC_LOG_TX_MESSAGE(
MSC_RRC_ENB,
MSC_RRC_UE,
eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.Header,
eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size,
MSC_AS_TIME_FMT" RRCConnectionReject UE %x size %u",
MSC_AS_TIME_ARGS(ctxt_pP),
ue_context_pP == NULL ? -1 : ue_context_pP->ue_context.rnti,
eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size);
LOG_I(RRC,
PROTOCOL_RRC_CTXT_UE_FMT" [RAPROC] Logical Channel DL-CCCH, Generating RRCConnectionReject (bytes %d)\n",
PROTOCOL_RRC_CTXT_UE_ARGS(ctxt_pP),
eNB_rrc_inst[ctxt_pP->module_id].carrier[CC_id].Srb0.Tx_buffer.payload_size);
}
//-----------------------------------------------------------------------------
void
rrc_eNB_generate_RRCConnectionReestablishmentReject(
......@@ -3627,8 +3670,15 @@ rrc_eNB_decode_ccch(
} else {
rrcConnectionRequest = &ul_ccch_msg->message.choice.c1.choice.rrcConnectionRequest.criticalExtensions.choice.rrcConnectionRequest_r8;
{
AssertFatal(rrcConnectionRequest->ue_Identity.present == InitialUE_Identity_PR_randomValue,
"unsupported InitialUE-Identity in RRCConnectionRequest");
if (rrcConnectionRequest->ue_Identity.present != InitialUE_Identity_PR_randomValue) {
LOG_E(RRC,
PROTOCOL_RRC_CTXT_UE_FMT" RRCConnectionRequest with S-TMSI not supported yet, let's reject the UE\n",
PROTOCOL_RRC_CTXT_UE_ARGS(ctxt_pP));
rrc_eNB_generate_RRCConnectionReject(ctxt_pP,
rrc_eNB_get_ue_context(&eNB_rrc_inst[ctxt_pP->module_id], ctxt_pP->rnti),
CC_id);
break;
}
AssertFatal(rrcConnectionRequest->ue_Identity.choice.randomValue.size == 5,
"wrong InitialUE-Identity randomValue size, expected 5, provided %d",
rrcConnectionRequest->ue_Identity.choice.randomValue.size);
......
  • when you say "keeps connecting over and over again" how does it connect? Again with S-TMSI or with the initial procedure?

  • Hi Florian,

    We've been talking about this for a day now.

    The conclusion is this:

    1. THere is no way to signal the UE anything in the RRC layer (RRCConnectionReject does not hold any cause information).
    2. If we do the reject what this patch does, there is a chance that a UE will stuck in this state and keep retrying with S-TMSI, cause the specs. does not tell explicitly what to do, so there is a high chance that the behavior of the UE in a consecutive RRCReject event will be implementation (vendor) dependent.
    3. Because of this what we can do is to send an explicit (MME originated) Detach with the "Re-Attach required" required flag set. This also not guarantees that the UE will not try with the S-TMSI again, it needs testing, but still it seems a better way.
    4. But in the end there is a high chance that we will need to implement S-TMSI handling anyway, cause even if its optional, it seems there is no proper way to handle this through signalling.

    Regards, Csaba

  • Hi Csaba, thanks for this clarification.

  • Yes, "keeps connecting over and over again" means the UE does it over and over with S-TMSI, at least the ones I tried (with the sequans right now for example). This really was just a test. I still prefer it than the Assert because the eNB does not crash anymore here. But yes, as Csaba says, we need to handle this case properly.

  • "I still prefer it than the Assert because the eNB does not crash anymore"

    Totally aggree with that.

Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment