Problem Description:

【Japanese Market Feedback】Softbank cloud card registration failed

[Preset conditions]
Device information:
Test environment: live network
Test location: Japan
Test version:
[Problem description]
The registration of the Softbank cloud card in Japan is unsuccessful.
The previous feedback is that the card is OK on other devices
[Occurrence probability]
Must appear
[Recovery] means]
change card

problem analysis:

Cause #29 – User authentication failed

According to the modem log, the registration is unsuccessful because the attach is rejected 29, this device is Zhanrui platform 8910:

LTE Lay3 Message Parse:
       Asn.1 Parse:
       NAS Parse:
               NAS Message: NET -> UE
               Protocol discriminator <EPS Mobility management messages>
               Security header type <plain NAS message>
               Message Type <Attach reject>
               EMM Cause
                       EMM Cause <ESM failure>
               ESMMessageContainer
                       ESMMessageContainer IEI <120>
                       length <00 04 >
                       ESMMessageContainer content <02 01 d1 1d >

LTE Lay3 Message Parse:
       Asn.1 Parse:
       NAS Parse:
               NAS Message: NET -> UE
               Protocol discriminator <EPS session management messages>
               EBI <No EPS bearer identity assigned>
               procedure transaction identity <1>
               Message Type <PDN connectivity reject >
               ESM cause
                       ESM cause <User authentication failed>

Description of rejection reason #29 on 3GPP 24.301:

Cause #29 – User authentication failed

This ESM cause is used by the network to indicate that the requested service was rejected by the external packet data network due to a failed user authentication.

Explanation on 3GPP 29.274:

"User authentication failed" is used by the GTP entity to indicate that the request is rejected due to a failure in the authentication/security procedure, or because the required user authentication cannot be performed (when the UE does not support secondary DN authentication and authorization over EPC but such a procedure is mandatory due to local policies in a combined PGW-C/SMF), or is used by a combined PGW-C/SMF for an UUAA-SM during PDN connection establishment procedure as described in clause 5.2.3.3 of 3GPP TS 23.256 [90] or in authorization for C2 procedure as described in clause 5.2.5.3 of 3GPP TS 23.256 [90].

Reason for rejection #29 What is the specific reason? There is no experience yet, but it can be further analyzed through comparative testing.

PAP and CHAP

The same device captured the log of successful registration of DOCOMO (44010), but no abnormality was found by comparing the OTA modem log. The parameters of the AT command for setting the PDP context provided by colleagues on the AP side are different:

softbank(44020):

AT+CFGDFTPDN=1,1,"plus.4g","plus","4g"

DOCOMO(44010):

AT+CFGDFTPDN=1,2,"mineo-d.jp","[email protected]","mineo"

The meaning of this AT command parameter is printed by the log:

/I : AT+CFGDFTPDN: get para pdnType=1 successfully
/I : AT+CFGDFTPDN: get para nAuthProt=1 successfully
/I : AT+CFGDFTPDN: get para apnsize:7 apn:80C6C744 112 108 117 115 46
/I : AT+CFGDFTPDN: get para apn=plus.4g
/I : AT+CFGDFTPDN: get para Usernamesize:4
/I : AT+CFGDFTPDN: get para Passwordsize:2

It can be seen that the main parameter difference between 44020 and 44010 is nAuthProt, that is, the authentication protocol is different. First find the description of this parameter through the code of the general android platform:

The RIL_REQUEST_SETUP_DATA_CALL command in ril.h contains:

* ((const char **)data)[5] is the PAP / CHAP auth type. Values:
* 0 => PAP and CHAP is never performed.
* 1 => PAP may be performed; CHAP is never performed.
* 2 => CHAP may be performed; PAP is never performed.
* 3 => PAP / CHAP may be performed - baseband dependent.

It can be seen that the authentication protocol used by 44020 is PAP, and the authentication protocol used by 44010 is CHAP.

What are PAP and CHAP specifically? I found relevant introductions on the Internet:

Introduction to PAP and CHAP protocols

1. Preface
PAP and CHAP protocols are currently commonly used authentication protocols in PPP (MODEM or ADSL dial-up). CHAP is defined in RFC1994 and is a challenge-response protocol. The password information shared by both parties does not need to be transmitted in communication; Defined in RFC1334, PAP is a simple plaintext user name/password authentication method.

2. PAP
The full name of PAP is: Password Authentication Protocol (Password Authentication Protocol), which is the basic authentication protocol in PPP. PAP is an ordinary password authentication, which requires the key information to be transmitted in clear text in the communication channel, so it is easy to be monitored and leaked by sniffers.

PAP negotiation option format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-
+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For PAP, the parameters are:
Type = 3, Length = 4, Authentication-Protocol = 0xc023(PAP)

PAP packet format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-
+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+
-
+

Code: 1 byte, indicating the type of PAP packet
1 Authentication request
2 Authentication confirmation
3 Authentication failure
Identifier: ID number, 1 byte, auxiliary matching request and response
Length: 2 bytes, indicating the length of the entire PAP data, including Code, Identifier, Length and
Data fields.
Data: It may be 0 bytes or more bytes. The specific format is determined by the Code field.
The length of may be 0.

For authentication request (Code = 1) type, the PAP packet format is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peer-ID Length| Peer-Id
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Passwd-
Length | Password ...
+-+-+-+-+-+-+-+- +-+-+-+-+-+

The meanings of Code (Code = 1), Identifier and Length fields are as mentioned above, the value of the Identifier field in the response packet is the same as that in the challenge packet, and the Identifier field must be changed every time authentication is performed.

Peer-ID-Length: 1 byte in length, indicating the length of the Peer-ID field

Peer-ID: It can be 0 to multiple bytes long, indicating the name of the authentication peer.

Passwd-Length: 1 byte in length, indicating the length of the Password field

Password: It can be 0 to multiple bytes long, indicating the password for authentication, in plain text

For authentication confirmation (Code = 2) and authentication failure (Code = 3) types, the format of the PAP packet is:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg-Length | Message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Among them:
Code, Identifier and Length fields have the same meanings as described above, and the value of the Identifier field in the response packet is the same as that in the authentication request packet.

Msg-Length: 1 byte in length, indicating the length of the Message field

Message: It can be 0 to multiple bytes long, and the specific content is determined by the actual implementation of the application. There is no restriction on its content in the RFC
. It is recommended to use readable ASCII characters to represent the message content.

3. CHAP

The full name of CHAP is: Challenge Handshake Authentication Protocol (Challenge Handshake Authentication Protocol), which is mainly for PPP. In addition to being used at the beginning of dialing, it can also be used at any time after the connection is established.

The basic process of the CHAP protocol is that the authenticator first sends a random challenge message to the other party, and the receiver uses the one-way HASH function to calculate the response value based on the challenge message and the shared key information, and then sends it to the authenticator, and the authenticator does the same The calculation, verify whether the calculation result is consistent with the received result, if they are consistent, the authentication will pass, otherwise the authentication will fail. The advantage of this authentication method is that the key information does not need to be sent in the communication channel, and the information exchanged for each authentication is different, which can effectively avoid monitoring attacks.

Disadvantages of CHAP: The key must be stored in plaintext information, and it cannot prevent man-in-the-middle attacks.

In addition to the security of the local key, the security of using CHAP lies in the length, randomness and reliability of the one-way HASH algorithm of the challenge information.

CHAP option format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Algorithm | +-+-+-+-+-+-+-+
-
+

For CHAP, the parameters are fixed as:

Type = 3，Length = 5，Authentication-Protocol = 0xc223(CHAP)，Algorithm = 5 (MD5)

CHAP packet format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-
+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+
-
+

Code: 1 byte, indicating the type of CHAP packet
1 Challenge
2 Response
3 Success
4 Failure

Identifier: ID number, 1 byte, auxiliary matching challenge, response and answer, must be changed each time CHAP is used

Length: 2 bytes, indicating the length of the entire CHAP data, including Code, Identifier, Length and
Data fields.

Data: It may be 0 bytes or more bytes, the specific format is determined by the Code field, and the length of the success or failure type packet
may be 0

For challenge (Code = 1) and response (Code = 2) types, the CHAP packet format is
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+ |
Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value-Size | Value
. ..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+

Among them:
Code, Identifier and Length fields have the same meanings as described above, and the value of the Identifier field in the response packet is the same as that in the challenge packet.

Value-Size: 1 byte in this field indicates the length of Value

Value: At least one byte, variable length, transmitted in network order, the challenge/response information is described in this field, the challenge
information must be random, and changes during each authentication, the challenge information is determined by the application in actual
implementation Self-defined, the specific format of the challenge information is not stipulated in the RFC;

The response value is calculated according to the following formula:
Response=HASH(Identifier+secret+Challenge)

Among them, the "+" sign means to string all the data in the memory, and the HASH algorithm can use MD5, so the calculated HASH value is fixed and 16 bytes long.

Name: At least one byte, used to mark the transmitted packet, must end with '/0' or "/r/n", the
length of the Name field can be calculated according to Length and Value-Size.

For success (Code = 3) or failure (Code = 4) type
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message ... +-+-+
-
+ -+-+-+-+-+-+-+-+-+-

The meanings of the Code, Identifier, and Length fields are as described above, and the Identifier field is consistent with the challenge/response information.

Message can be 0 bytes or multiple bytes, and the content can be determined according to the actual application.

4. Conclusion

Both PAP and CHAP are used in current PPP applications. CHAP is relatively more complicated, but also has higher security. In the specific implementation of PPP, it is usually used at the same time. In the implementation of PPP under Linux, if the PAP authentication required by the server fails, CHAP authentication will be required again.
————————————————
Copyright statement: This article is an original article of CSDN blogger "Robust516", following the CC 4.0 BY-SA copyright agreement, please attach the original source link and this statement for reprinting .
Original link: https://blog.csdn.net/Robust516/article/details/1368965

ESM information response signaling to send PAP and CHAP

Through which OTA signaling is the content of PAP and CHAP sent to the network? I checked the OTA log and found no relevant content. I also searched for some domestic logs of the Qualcomm platform and found nothing, thinking that domestic operators may not use this parameter very much, I need to find a Japanese log to confirm, and finally found it:

08:36:59.090405 [0xB0E3] LTE NAS ESM Plain OTA Outgoing Message
pkt_version = 1 (0x1)
rel_number = 9 (0x9)
rel_version_major = 5 (0x5)
rel_version_minor = 0 (0x0)
eps_bearer_id_or_skip_id = 0 (0x0)
prot_disc = 2 (0x2) (EPS session management messages)
trans_id = 1 (0x1)
msg_type = 218 (0xda) (ESM information response)
lte_esm_msg
esm_info_res
acc_pt_name_incl = 1 (0x1)
access_point_name
num_acc_pt_val = 11 (0xb)
acc_pt_name_val[0] = 7 (0x7) (length)
acc_pt_name_val[1] = 109 (0x6d) (m)
acc_pt_name_val[2] = 105 (0x69) (i)
acc_pt_name_val[3] = 110 (0x6e) (n)
acc_pt_name_val[4] = 101 (0x65) (e)
acc_pt_name_val[5] = 111 (0x6f) (o)
acc_pt_name_val[6] = 45 (0x2d) (length)
acc_pt_name_val[7] = 100 (0x64) (d)
acc_pt_name_val[8] = 2 (0x2) (length)
acc_pt_name_val[9] = 106 (0x6a) (j)
acc_pt_name_val[10] = 112 (0x70) (p)
prot_config_incl = 1 (0x1)
prot_config
ext = 1 (0x1)
conf_prot = 0 (0x0)
num_recs = 8 (0x8)
prot_or_container[0]
id = 49699 (0xc223) (CHAP)
prot_or_container
prot_len = 37 (0x25)
chap_prot
code = 1 (0x1)
identifier = 0 (0x0)
rfc1994_chap_challenge
value_size = 16 (0x10)
value[0] = 250 (0xfa)
value[1] = 148 (0x94)
value[2] = 250 (0xfa)
value[3] = 250 (0xfa)
value[4] = 250 (0xfa)
value[5] = 148 (0x94)
value[6] = 250 (0xfa)
value[7] = 250 (0xfa)
value[8] = 250 (0xfa)
value[9] = 148 (0x94)
value[10] = 250 (0xfa)
value[11] = 250 (0xfa)
value[12] = 250 (0xfa)
value[13] = 148 (0x94)
value[14] = 250 (0xfa)
value[15] = 250 (0xfa)
name_size = 16 (0x10)
name[0] = 109 (0x6d)
name[1] = 105 (0x69)
name[2] = 110 (0x6e)
name[3] = 101 (0x65)
name[4] = 111 (0x6f)
name[5] = 64 (0x40)
name[6] = 107 (0x6b)
name[7] = 45 (0x2d)
name[8] = 111 (0x6f)
name[9] = 112 (0x70)
name[10] = 116 (0x74)
name[11] = 105 (0x69)
name[12] = 46 (0x2e)
name[13] = 99 (0x63)
name[14] = 111 (0x6f)
name[15] = 109 (0x6d)
prot_or_container[1]
id = 49699 (0xc223) (CHAP)
prot_or_container
prot_len = 37 (0x25)
chap_prot
code = 2 (0x2)
identifier = 0 (0x0)
rfc1994_chap_resp
value_size = 16 (0x10)
value[0] = 117 (0x75)
value[1] = 45 (0x2d)
value[2] = 235 (0xeb)
value[3] = 84 (0x54)
value[4] = 4 (0x4)
value[5] = 196 (0xc4)
value[6] = 210 (0xd2)
value[7] = 221 (0xdd)
value[8] = 165 (0xa5)
value[9] = 140 (0x8c)
value[10] = 130 (0x82)
value[11] = 181 (0xb5)
value[12] = 29 (0x1d)
value[13] = 133 (0x85)
value[14] = 248 (0xf8)
value[15] = 170 (0xaa)
name_size = 16 (0x10)
name[0] = 109 (0x6d)
name[1] = 105 (0x69)
name[2] = 110 (0x6e)
name[3] = 101 (0x65)
name[4] = 111 (0x6f)
name[5] = 64 (0x40)
name[6] = 107 (0x6b)
name[7] = 45 (0x2d)
name[8] = 111 (0x6f)
name[9] = 112 (0x70)
name[10] = 116 (0x74)
name[11] = 105 (0x69)
name[12] = 46 (0x2e)
name[13] = 99 (0x63)
name[14] = 111 (0x6f)
name[15] = 109 (0x6d)
prot_or_container[2]

I used to read a lot of domestic logs, but the ESM information response only contained APN content, and now I have finally read all of them.

Looking at the ESM information response of the problem log 44020 and 44010, there is no PAP or CHAP related content. It can be guessed that the 44010 card can be registered on the network. It should be that the DOCOMO network does not require authentication protocols, and the softbank (44020) The network has requirements for the authentication protocol, and no relevant content is allowed to attach.

Then the log on the physical card registration of 44020 was also captured. The ESM information response did have PAP-related content. The red part is the content of the successful registration of the 44020 card compared to the failed registration:

44020's card is also successfully registered using the CHAP protocol:

LTE Lay3 Message Parse:
       Asn.1 Parse:
       NAS Parse:
               NAS Message: UE -> NET
               Protocol discriminator <EPS session management messages>
               EBI <No EPS bearer identity assigned>
               procedure transaction identity <1>
               Message Type <ESM information response>
               Access point name
                       IE Name <Access point name>
                       IE Length <8>
                       APN value <plus.4g>
               Protocol configuration options
                       IE Name <Protocol configuration options>
                       IE Length <91>
                       Configuration protocol <PPP for use with IP PDP type>
                       0000 spare
                       1ext <1>
                       ID <c2 23 >
                       Length of pro contents <25>
                       contents
                               <01 01 00 19 10 c8 62 b5
                               c7 52 58 b8 5b f0 54 55
                               94 9e 54 c2 25 70 6c 75
                               73 >
                       ID <c2 23 >
                       Length of pro contents <25>
                       contents
                               <02 01 00 19 10 30 53of
                               44 38 2d f7 42 dd e5 3a
                               1c 15 44 39 1d 70 6c 75
                               73 >
                       ID <80 21 >
                       Length of pro contents <16>
                       contents
                               <01 01 00 10 81 06 00 00
                               00 00 83 06 00 00 00 00 >
                       ID <P-CSCF IPv6 Address>
                       Length of pro contents <0>
                       ID <DNS Server IPv6 Address>
                       Length of pro contents <0>
                       ID <IP address allocation via NAS signalling/ReseIPv4 address allocation via DHCPv4/Reserved>
                       Length of pro contents <0>
                       ID <P-CSCF IPv4 Address>
                       Length of pro contents <0>
                       ID <DNS Server IPv4 Address>
                       Length of pro contents <0>

The reason why the Softbank card registration was rejected 29 is that the content of the authentication agreement is missing. If you encounter rejection 29 later, you can directly check the authentication agreement, user name, and password.

Through various tests, AP colleagues have determined the correct AT commands for writing the authentication protocol, user name, and password, and the problem has been solved.

Summarize:

attach, PDP, PDN, PDU activation is rejected because:

Cause #29 – User authentication failed

When this happens, basically there are problems with the authentication protocol, user name, and password. Focus on troubleshooting.

#29 – User authentication failed problem summary

Problem Description:

problem analysis:

Cause #29 – User authentication failed

PAP and CHAP

ESM information response signaling to send PAP and CHAP

Summarize:

Guess you like