#29 – User authentication failed问题总结_esm failure

作者：人工智能uu | 2024-07-20 01:34:15

踩

esm failure

问题描述：

问题分析：

Cause #29 – User authentication failed

PAP和CHAP

ESM information response信令发送PAP和CHAP

总结：

问题描述：

【日本市场反馈】软银云卡注册不成功

【预置条件】
设备信息：
测试环境：现网
测试地点：日本
测试版本：
【问题描述】
日本软银云卡注册不成功
前方反馈该卡在别的设备是OK的
【出现概率】
必现
【恢复手段】
换卡

问题分析：

Cause #29 – User authentication failed

看modem日志注册不成功是因为attach被拒29，此设备为展锐平台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>

3GPP 24.301上对被拒原因#29的描述：

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.

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].

被拒原因#29具体原因是什么目前还没有经验，但可通过对比测试进一步分析。

PAP和CHAP

同一设备抓到了DOCOMO（44010）注册成功的日志，但通过对比OTA的modem日志并没有发现异常。AP侧同事提供的设置PDP context的AT指令的参数有所不同：

softbank(44020):

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

DOCOMO(44010):

AT+CFGDFTPDN=1,2,"mineo-d.jp","mineo@k-opti.com","mineo"

这条AT指令参数的含义通过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

可以看出44020和44010的主要参数不同的是nAuthProt，即鉴权协议不同。先通过通用的android平台的代码找下对这个参数的描述：

ril.h的RIL_REQUEST_SETUP_DATA_CALL命令里有：

* ((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.

这就可看出44020使用的鉴权协议是PAP，44010使用的鉴权协议是CHAP。

PAP和CHAP具体是什么，在网上搜到了相关介绍：

PAP和CHAP协议介绍

1. 前言
PAP和CHAP协议是目前的在PPP(MODEM或ADSL拨号)中普遍使用的认证协议，CHAP在RFC1994中定义，是一种挑战响应式协议，双方共享的口令信息不用在通信中传输；PAP在RFC1334中定义，是一种简单的明文用户名/口令认证方式。

2. PAP
PAP全称为：Password Authentication Protocol（口令认证协议），是PPP中的基本认证协议。PAP就是普通的口令认证，要求将密钥信息在通信信道中明文传输，因此容易被sniffer监听而泄漏。

PAP协商选项格式：
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

对于PAP，参数为：
Type = 3，Length = 4，Authentication-Protocol = 0xc023(PAP)

PAP数据包格式：
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字节，表示PAP包的类型
1 认证请求
2 认证确认
3 认证失败
Identifier：ID号，1字节，辅助匹配请求和回应
Length：2字节，表示整个PAP数据的长度，包括Code, Identifier, Length和
Data字段。
Data：可能是0字节或多个字节，具体格式由Code字段决定，成功或失败类型包中长
度可能为0。

对于认证请求（Code = 1）类型，PAP包格式为：
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code（Code = 1）,Identifier和Length字段含义如前面所述，响应包的Identifier字段值和挑战包中的相同，Identifier字段必须每次认证时改变。

Peer-ID-Length：长度1个字节，表示Peer-ID域的长度

Peer-ID：可为0到多个字节长，表示认证对方的名称。

Passwd-Length：长度1个字节，表示Password域的长度

Password：可为0到多个字节长，表示认证的口令，明文

对于认证确认（Code = 2）和认证失败（Code = 3）类型，PAP包格式为：

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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

其中：
Code,Identifier和Length字段含义如前面所述，响应包的Identifier字段值和认证请求包中的相同。

Msg-Length：长度1个字节，表示Message域的长度

Message：可为0到多个字节长，具体内容由应用实际实现时确定，RFC中没有限制其
内容，推荐使用可读的ASCII字符表示信息内容。

3. CHAP

CHAP全称为：Challenge Handshake Authentication Protocol(挑战握手认证协议)，主要就是针对PPP的，除了在拨号开始时使用外，还可以在连接建立后的任何时刻使用。

CHAP协议基本过程是认证者先发送一个随机挑战信息给对方，接收方根据此挑战信息和共享的密钥信息，使用单向HASH函数计算出响应值，然后发送给认证者，认证者也进行相同的计算，验证自己的计算结果和接收到的结果是否一致，一致则认证通过，否则认证失败。这种认证方法的优点即在于密钥信息不需要在通信信道中发送，而且每次认证所交换的信息都不一样，可以很有效地避免监听攻击。

CHAP缺点：密钥必须是明文信息进行保存，而且不能防止中间人攻击。

使用CHAP的安全性除了本地密钥的安全性外，网络上的安全性在于挑战信息的长度、随机性和单向HASH算法的可靠性。

CHAP选项格式：
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 |
+-+-+-+-+-+-+-+-+

对于CHAP，参数固定为：

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

CHAP数据包格式：
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字节，表示CHAP包的类型
1 挑战
2 响应
3 成功
4 失败

Identifier：ID号，1字节，辅助匹配挑战、响应和回答，每次使用CHAP时必须改变

Length：2字节，表示整个CHAP数据的长度，包括Code, Identifier, Length和
Data字段。

Data：可能是0字节或多个字节，具体格式由Code字段决定，成功或失败类型包中长度
可能为0

对于挑战（Code = 1）和响应（Code = 2）类型，CHAP包格式为
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

其中：
Code,Identifier和Length字段含义如前面所述，响应包的Identifier字段值和挑战包中的相同。

Value-Size：此字段1字节表示Value的长度

Value：至少是一个字节，可变长，按网络序传输，挑战/响应信息在此字段中说明，
挑战信息必须是随机的，在每次认证时改变，挑战信息是由应用在实际实现
中自己定义的，RFC中并没有规定挑战信息的具体格式；

响应值按下面的公式进行计算：
Response=HASH(Identifier+secret+Challenge)

其中“+”号表示将各数据在内存中串起来，其中HASH算法可以使用MD5，所以计算出来的HASH值是固定的，16字节长。

Name：至少一个字节，用来标志所传的这个包，必须是以'/0'或“/r/n”结束，
Name字段的长度可根据Length和Value-Size计算出来。

对于成功（Code = 3）或失败（Code = 4）类型
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-

Code,Identifier和Length字段含义如前面所述，Identifier字段和挑战/响应信息一致。

Message可以是0字节，也可以是多个字节，内容可以根据实际应用自己确定。

4. 结语

PAP和CHAP在目前的PPP应用中都在使用，CHAP相对要复杂一些，但安全性也高一些。在PPP具体实现中通常是同时使用，在Linux下PPP的实现中，如果服务器要求的PAP认证失败，会再次要求用CHAP认证。
————————————————
版权声明：本文为CSDN博主「Robust516」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/Robust516/article/details/1368965

ESM information response信令发送PAP和CHAP

PAP和CHAP的内容是通过哪条OTA信令发给网络的呢，检查了OTA log并没有发现相关内容。又找了些高通平台的国内日志也没发现，想国内运营商可能不怎么用这个参数，需要找个日本的日志再确认下，终于找到了：

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]

以前看国内的日志多，ESM information response里只有APN的内容，现在终于看全了。

再看问题日志44020和44010的ESM information response里都没有PAP或CHAP的相关内容，可以猜出：44010的卡能注册上网络应该是DOCOMO的网络对鉴权协议没有要求，而softbank(44020)的网络对鉴权协议有要求，没有相关内容不让attach。

然后44020的物理卡注册上的日志也抓到了，ESM information response里确实有了PAP的相关内容，红色部分就是44020的卡注册成功比注册失败多出来的内容：

44020的卡改用CHAP协议注册也成功了：

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 53 af
                               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>

软银卡注册被拒29的原因就是少了鉴权协议的内容，后面再遇到被拒29就可直接查鉴权协议、用户名、密码这些了。

AP同事通过各种测试确定了正确写鉴权协议、用户名、密码这些的AT命令，问题得到了解决。

总结：

attach，PDP、PDN、PDU激活被拒原因为：

Cause #29 – User authentication failed

时，基本就是鉴权协议、用户名、密码这些有问题，重点排查这些。

声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop】