Q/DKBAXXXX-2001 密级：机密
VerTypeUserIPPAP/chapRsvdSerialNoUserPortReqIDErrCodeAttrNumAuthenticatorAuthenticator( cont )Attr... ...
图4-1 增加报文校验之后的Portal协议报文格式
4.2 报文字段说明
?
Ver
Ver字段是协议的版本号，长度为 1 字节，Ver = 0x02。之所以对Version进行升级，是因为对Version 1做了如下的扩充：
? 修改了报文格式，在AttrNum字段之后增加了16个字节的Authenticator字段。 ? 增加对所有协议报文的校验，包括上线流程、下线流程和查询流程。
? 修改了TextInfo属性，使其完全符合TLV格式（version 1曾经出现过不完全符合TLV格式的软件实现版本），不再区分其内容的语言，并且约定：BAS本地产生的提示信息不上报到Portal Server。
?
Type
Type字段定义报文的类型，长度为 1 字节。该版本兼容原协议的全部命令字，同时新增类型为0x08，0x09，0x0a三个命令字：
Type REQ_CHALLENGE 值 0x01 方向 Client --> Server 含义 Portal Server向BAS发送的Challenge请求报文 ACK_CHALLENGE 0x02 Server --> Client BAS对Portal Server请求Challenge报文的响应报文 REQ_AUTH 0x03 Client --> Server Portal Server向BAS发送的认证请求报文 ACK_AUTH 0x04 Server --> Client BAS对Portal Server认证请求的响应报文 REQ_LOGOUT 0x05 Client --> Server Portal Server向BAS发送2005-3-10, 10:32:13
6
Q/DKBAXXXX-2001 密级：机密
Type 值 方向 含义 的下线请求报文 ACK_LOGOUT 0x06 Server --> Client BAS对Portal Server下线请求的响应报文 AFF_ACK_AUTH 0x07 Client --> Server Portal Server向BAS发送的认证成功响应报文 NTF_LOGOUT REQ_INFO ACK_INFO WEB_STATUS_NOTIFY 0x08 0x09 0x0a 0x81 Server --> Client Client --> Server Server --> Client Client --> Server 用户被强制下线通知报文 信息询问报文 信息询问的应答报文 Portal Server定时向BAS发送的状态通知报文 WEB_ACK_STATUS_NOTIFY 0x82 Server --> Client BAS对Portal Server状态通知报文的响应报文 表1 协议支持的命令字
?
Pap/Chap
Pap/Chap字段定义此用户的认证方式，长度为 1 字节，对REQ_CHALLENGE、REQ_AUTH认证请求报文有意义：
Chap方式认证－－－值为0x00； Pap 方式认证－－－值为0x01；
??
把Pap/Chap放在协议报文的目前位置，使得整个报文不太协调。但是考虑到现实的
原因，目前不对该字段进行任何更改。
? ?
Rsv
Rsv目前为保留字段，长度为 1 字节，在所有报文中值为 0；
SerialNo
(1)、SerialNo字段为报文的序列号，长度为 2 字节，由PortalServer随机生成，Portal Server必须尽量保证不同认证流程的SerialNo在一定时间内不得重复，在同一个认证流程中所有报文的SerialNo相同；
(2)、PortalServer发给BAS设备的报文
a、由Portal Server发出的Type值为1、3的请求报文其SerialNo都是随机生成数；
b、由PortalServer向BAS设备发出的Type值为5的报文其SerialNo值分两中情况：当ErrCode为0时，SerialNo值为一个随机生成数；当ErrCode为1时，SerialNo值可能和Type值为1或3的报文相同，具体要看是请求Challenge超时还是请求认证超时；
c、由PortalServer向BAS设备发出的认证成功确认报文（Type值为7的报文）SerialNo和其发出的相应请求报文的SerrialNo相同；比如对于Type值为7的报文其SerialNo值和Type值为3的请求认证报文相同；
2005-3-10, 10:32:13
7
Q/DKBAXXXX-2001 密级：机密
(3)、每一个由BAS设备发给PortalServer的响应报文的SerialNo必须和Portal Server发送的相应请求报文的SerialNo一样，否则PortalServer会丢掉从BAS设备发来的响应报文； 比如Type值为2的报文其SerialNo值必须和Type值为1的报文相同，Type值为4的报文其SerialNo值必须和Type值为3的报文相同，Type值为6的报文其SerialNo值必须和Type值为5的报文相同。
?
ReqID
(1)、ReqID字段长度为 2 个字节，由BAS设备生成，ReqID不会重复。 (2)、在Chap认证方式中：
a、BAS设备在ACK_CHALLENGE报文中把该ReqID的值告诉PortalServer；
b、在REQ_AUTH、 ACK_AUTH、 AFF_ACK_AUTH的报文中ReqID字段的值都和ACK_CHALLENGE报文中此字段的值相同；
c、在REQ_LOGOUT的报文中，若报文表示请求Challenge超时则此字段值为0；否则此字段值和ACK_CHALLENGE报文中此字段的值相同；
d、在ACK_LOGOUT报文中，此字段值和ACK_CHALLENGE报文中此字段的值相同； (3)、在Pap认证方式中：
a、BAS设备在ACK_AUTH报文中把该ReqID的值告诉PortalServer；
b、在AFF_ACK_AUTH的报文中ReqID字段的值都和ACK_AUTH报文中此字段的值相同；
c、在REQ_LOGOUT的报文中，若报文表示请求认证超时则此字段值为0；否则此字段值和ACK_AUTH报文中此字段的值相同；
d、在ACK_LOGOUT报文中，此字段值和ACK_AUTH报文中此字段的值相同； (4)、其它报文中，该字段均无意义，值都为0；
?
UserIP
UserIP字段为Portal用户的IP地址，长度为 4 字节，其值由PortalServer根据其获得的IP地址填写，在所有的报文中此字段都要有具体的值；
?
UserPort
与原协议一致。
UserPort字段目前没有用到，长度为 2 字节，在所有报文中其值为0；
?
ErrCode
ErrCode字段和Type字段一起表示一定的意义，长度为 1字节。 对原协议支持的Type，ErrCode与原协议一致。具体如下：
(1)、对于Type值为1、3、7的报文，ErrCode字段无意义，其值为0； (2)、当Type值为 2 时：
ErrCode＝0，表示BAS设备告诉PortalServer请求Challenge成功； ErrCode＝1，表示BAS设备告诉PortalServer请求Challenge被拒绝；
ErrCode＝2，表示BAS设备告诉PortalServer此链接已建立；
2005-3-10, 10:32:13
8
Q/DKBAXXXX-2001 密级：机密
ErrCode＝3，表示BAS设备告诉PortalServer有一个用户正在认证过程中，请稍后再试； ErrCode＝4，则表示BAS设备告诉PortalServer此用户请求Challenge失败（发生错误）； (3)、当Type值为 4 时：
ErrCode＝0，表示BAS设备告诉PortalServer此用户认证成功； ErrCode＝1，表示BAS设备告诉PortalServer此用户认证请求被拒绝； ErrCode＝2，表示BAS设备告诉PortalServer此链接已建立；
ErrCode＝3，表示BAS设备告诉PortalServer有一个用户正在认证过程中，请稍后再试； ErrCode＝4 ，表示BAS设备告诉PortalServer此用户认证失败（发生错误）； (4)、当Type值为 5 时：
ErrCode＝0，表示此报文是PortalServer发给BAS设备的请求下线报文；
ErrCode＝1，表示此报文是在PortalServer没有收到BAS设备发来的对各种请求的响应报文，而定时器时间到（即超时）时由PortalServer发给BAS设备的报文；
(5)、当Type值为 6 时：
ErrCode＝0，表示BAS设备告诉PortalServer此用户下线成功； ErrCode＝1，表示BAS设备告诉PortalServer此用户下线被拒绝；
ErrCode＝2, 表示BAS设备告诉PortalServer此用户下线失败（发生错误）；
对新增命令报文的ErrCode说明如下：
????
对Type为REQ_INFO时，ErrCode无意义，其值为0； 对Type为NTF_LOGOUT时，ErrCode含义如下：
ErrCode 0 含义 下线 ??对Type为ACK_INFO时，ErrCode含义如下： ErrCode 0 含义 处理成功，但不表示全部消息都被获取了，有多少信息被获得应通过属性来判断，详见下文 1 2 功能不支持，表示设备不支持这一功能 消息处理失败，由于某种不可知原因，使处理失败，例如询问消息格式错误等。 ?
AttrNum
AttrNum字段表示其后边可变长度的属性字段属性的个数，长度为 1 字节（表示属性字段最多可有255个属性），其值在所有的报文中都要根据具体情况赋值；
?
Authenticator
验证字的长度固定为16字节，网络字节顺序。其内容的计算在请求报文和响应报文中略有区别，并且在验证字的计算时，将类型为7（AFF_ACK_AUTH）和类型为8（NTF_LOGOUT）的报文当作请求报
2005-3-10, 10:32:13
9
Q/DKBAXXXX-2001 密级：机密
文，尽管这两种报文不是严格意义上的请求报文（严格的说，AFF_ACK_AUTH更像是响应报文）。验证字的计算是通过MD5算法实现的，其中报文的各个字段以及BAS和Portal Server之间的共享密钥secret都参与了计算。以下分别介绍请求报文的验证字和响应报文的验证字。
1. 请求报文的验证字（Request Authenticator）：
以字节流Ver + Type + PAP/CHAP + Rsvd + SerialNo + ReqID + UserIP + UserPort + ErrCode + AttrNum + 16个字节的0 + request attributes + secret作为MD5的输入，得到的MD5输出就是请求报文的验证字Request Authenticator的内容。
2. 响应报文的验证字（Response Authenticator）：
以字节流Ver + Type + PAP/CHAP + Rsvd + SerialNo + ReqID + UserIP + UserPort + ErrCode + AttrNum + 本响应报文对应的请求报文的16字节的Request Authenticator + response attributes + secret作为MD5的输入，得到的MD5输出就是响应报文的验证字Response Authenticator的内容。
为了完成校验功能，需要注意如下几点：
??
在Server和Client两端需要配置相同的共享密钥Secret，否则无法通过接收方的校
验；
????
双方都使用RFC1321中描述的MD5加密算法；
接收方为了校验所接收到报文的正确性，必须采用和发送方完全一样的计算过程。
如果计算出来的验证字和接收到的报文中的验证字一致，则认为报文合法；否则任务报文错误，可以简单丢弃，但是建议对丢弃报文进行统计。
???? ??????Attr
请求验证字和响应验证字的计算参照了RADIUS计费报文的验证字的计算方法。 目前支持的报文类型存在如下的请求和响应关系： 请求响应
REQ_CHALLENGE <——> ACK_CHALLENGE REQ_AUTH <——> ACK_AUTH REQ_LOGOUT <——> ACK_LOGOUT REQ_INFO <——> ACK_INFO NTF_LOGOUT 无 AFF_ACK_AUTH 无
?
Attr字段（属性字段）是一个可变长字段，由多个属性依次链接而成，每个属性的格式为TLV格式，具体如下（图4-2）：
2005-3-10, 10:32:13
10