下载了个FreeBSD 7.2在vbox虚拟机里面装了下，发现FreeBSD比Linux好像原始多了［呃，我说安装程序］，分区的时候他不叫Create Partition，叫Create Slice，我对着界面看了半天才猜到，囧；退出那里写着：Q = Finish，Quit就Quit嘛，什么Finish，纠结……但还好，其他的配置跟Linux还是很相像的，调试了一下就有了全可编译的代码了。

代码部分修改倒没多少，就添加了一个专门给BSD系系统获取MAC的函数，再用maroc判断一下，以及几个头文件，就完事了，有点麻烦的是makefile，发现freebsd默认那个make好像是很古老很古老的版本，我程序里面那个Makefile是用了vim里面c-support插件里面带的Makefile模板，有点复杂，但是freebsd居然不支持！所以整理了个简单的版本，专门给MacOS/BSD编译，也方便别人的修改；另外一个原因是，程序里面转换服务器消息时候用了iconv库，linux里面iconv是系统内嵌库来的，用不着链接的时候给出参数，但MacOS/BSD偏偏就要-liconv……

需要编译MacOS/BSD版本的同学，可以check出项目里面trunk的代码，运行make -f Makefile.bsd来编译。Insion同学已经编译成功，而且在他的主页上有二进制版下载了。

相对的说，可能在MacOS里面编译是最麻烦的，我大概说说流程（实际上我没试过，我可没Mac机器［T.T］）

1.安装gcc，参考这里从http://connect.apple.com/的Dev Tools里面下载Xcode Tools，安装。
2.编译安装libpcap，从http://www.tcpdump.org/release/libpcap-1.0.0.tar.gz下载源码，tar xvfz libpcap-1.0.0.tar.gz解压，进去该目录，./configure、make、make install安装完成；
3.编译802.1x客户端，从所用项目内签出源码，在目录内make，没出什么差错的话，已经完成了。然后按Readme.txt的方法安装运行，即可！

项目主页

锐捷：http://code.google.com/p/zruijie4gzhu/
联想：http://code.google.com/p/zlevoclient/
神州数码：http://code.google.com/p/zdcclient/

我们学校并没有使用过联想协议的认证系统，而是受了一位网友的邀请才写的，所以我连联想官方客户端的样子都没看到过，一直是由那网友抓包后发送过来，而我猜测地将其套入到此前我写的神州数码的认证程序里面，经过几天的调试，确实能用，虽然并不完全了解认证报文的每个细节。

PT实现的联想Linux客户端项目主页：http://code.google.com/p/zlevoclient/

以下的说明是基于EAP协议过程的补充描述，如果不清楚EAP，可先读深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程。

认证过程报文的细节描述：

1. EAPOL-Start、EAPOL-Logoff
   设置长度为0的协议包头，然后紧接6个意义不明的字节（可能是版本号之类），直接复制即可：
    {0x00, 0x00, 0x2f, 0xfc, 0x03, 0x00};
2. EAP-RESPONSE-Identity
   长度为5（头部） + username_length，无特别，跟EAP标准一致，
3. EAP-RESPONSE-MD5_Challenge
   长度为6（头部） + 16（MD5值） + username_length，在MD5值之后，先紧接用户名，然后是4字节的本机IP地址，以及9个意义不明的字节，直接复制：{0x00, 0x00, 0x2f, 0xfc, 0x00, 0x03, 0x01, 0x01, 0x00};
4. EAPOL-KEEP-ALIVE
   当认证成功后，需要每60秒发送一次该报文，否则会断线；
   该报文的b:EAPOL 报文类型为0xFC，帧长值为12，其携带信息的前8字节在实际中似乎是随机变化，找不出其规律，不过实际上全部设0也可；后4字节则是本机IP。

在部分版本中，如吉林大学珠海学院，每隔5分钟（可能就在第五个EAPOL-KEEP-ALIVE发出之后）服务器会重新发来EAP-REQUEST-Identity，程序需要正确应答，特别要设置各个应答报文中的e:EAP通信id。

关于服务器返回的数据包，Success和Failure通常包含有中文编码的信息，标志是，EAP报文结束后，紧接0x00002ffc（大概0x18、0x19），其后接着是一个字节的报文长度，再后就是gb2312编码的中文信息。

由于协助我测试的湖南人文科技学院的网友他们的系统是纯手工设置网卡IP的，所以我也不清楚是否有像其他品牌的协议那样有动态静态IP位之类的信息位，如果发现这个版本的程序不能通过认证，可以自己抓包分析，或邮件联系PT。

其实这个项目的目标不是非常明确，至少到目前为止，能在Linux下的使用的锐捷兼容客户端已经有mystar、 ruijieclient、mentoHust（还有很多，单纯Google Code上以“锐捷”为标签的就一堆了……），还有基于QT、pygtk开发的图形界面程序，可谓百花齐放，再开发一个版本出来理由似乎不太充分，只是为了一些美中不足：比如最有实力的mentoHust，其能支持到锐捷最新的3.7版本的协议，却不是开源方案；mystar则是年久失修，已经不能兼容现在的协议（不过其留下的代码让后来的开发者得到很大的指引，在此对作者Rijndael&byhh表示敬意）；至于此前一直使用的Ruijieclient，其实也有点问题，一直掉线，查看上网明细，每次在线都只有1分29秒就被踢了，说明协议兼容问题。虽说Ruijieclient有“智能重连”功能，但是重连跟掉线是两回事，不能说会重连就说解决了掉线问题，花心思研究协议才是正道。

也许也就在于类似问题的出发点不同吧，虽然PT加入了Ruijieclient的项目，但一直没有参加过代码开发，毕竟一提出任何意见就互相反对的人之间很难合作，所以考完试后就花了一天时间，把锐捷协议移植到PT的“z-框架”下。虽然分析下来这个兼容问题是小事情，就是所谓的serial number的初始值以及success key的提取位不对，不过我实在不喜欢Ruijieclient的框架了，而且对自己熟悉的“z-框架”代码维护起来有快感的多。

“z-框架”是指PT依次开发神州数码、联想、锐捷几个客户端一直沿用下来的一些模式，所以zRuijie4GZHU的代码理论上跟其他锐捷相关程序是没什么相似的。除了从mystar里面沿用过来的两个数组照样copy外，PT把mystar开发时候通过反汇编得出来的Alog、Blog算法函数都重写了一次，比原来汇编式的代码的效率和可读性要高得多（分析过程中发现原来有几行的代码是多余的），两个函数摘抄在本文后面，希望对其他的锐捷开发者有用。

zRuijie4GZHU的目标应该跟Ruijieclient这些不同，Ruijieclient是面向通用的锐捷协议，要做到全球通用其实难度不小的，而zRuijie4GZHU，也正如其名，是为广州大学的锐捷而兼容的，如果能在其他学校使用，那估计是意外。

PT的开发理念是K.I.S.S，zRuijie4GZHU没有什么复杂概念，比如DHCP，只有是和不是DHCP模式，没有什么0、1、2、3模式，更没有配置文件，软件是执行文件和脚本的统一体，缺一不可。

OK，有需要的用户可以查看项目wiki的用户手册吧，下面是PT改写的锐捷Ablog和Blog算法函数：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

/*
 * ===  FUNCTION  ======================================================================
 *         Name:  Alog
 *  Description:  revert bit order and converse each bit.
 *  REWRITTEN BY PT.
 * =====================================================================================
 */
uint8_t
Alog(uint8_t val)
{
    int i;
    u_char result = 0;
    for (i = 0; i < 8; ++i)
        result |= (((val << (7 - i)) & 0x80) >> i);
 
    return ~result;
}
 
/*
 * ===  FUNCTION  ======================================================================
 *         Name:  Blog
 *  Description:  Calculate circle check sum.
 *  REWRITTEN BY PT.
 * =====================================================================================
 */
void
Blog(uint8_t circleCheck[2])
{
    if (!blogIsInitialized)
        return;
    uint8_t h_byte = 0, l_byte = 0;
    int i;
    for (i = 0; i < 0x15; ++i) {
        uint8_t index = h_byte ^ sCircleBase[i];
        h_byte = Table[index * 2 + 1] ^ l_byte;
        l_byte = Table[index * 2];
    }
    circleCheck[0] = h_byte;
    circleCheck[1] = l_byte;
}

这就是我们研究这些厂商自定义的EAP协议的意义。

PT实现的神州数码Linux客户端项目主页：http://code.google.com/p/zdcclient/

以下的说明是基于EAP协议过程的补充描述，如果不清楚EAP，可先读深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程。

神州数码的私有信息尾结构神州数码协议里面最特别的地方是有一段46字节的信息，其位于EAP报文后，属于EAPOL报文的尾端部分，在发往服务器的EAP_RESPONSE_IDENTITY和EAP_RESPONSE_MD5_Challenge两种报文里面都需要附上该46字节的信息以供验证。

在PT的神州数码验证程序zdclient里面，zdclient.h定义了这个信息结构：

struct dcba_tailer {
    bpf_u_int32     local_ip;
    bpf_u_int32     local_mask;
    bpf_u_int32     local_gateway;
    bpf_u_int32     local_dns;
    u_char          username_md5[16];
    u_char          client_ver[13];
};

当然这个结构体只有45字节，实际上在其附到EAP报文时，46字节的首字节用以表示认证所使用的DHCP模式，但由于其加入到上面这个结构体中会引起内存对齐问题，所以暂且让这个DHCP位不属于这个结构。

DHCP位只有0和非0两个状态，前者表示静态，非DHCP模式，后者则是DHCP模式。

这里所谓的DHCP模式并不跟操作系统给网卡获得IP那个DHCP概念等价。在常见的DHCP模式中，完成了认证之后需要重新运行dhclient之类的DHCP客户端来更新网卡的IP，但实际上并不一定如此，实际上是否需要更新得看具体环境，比如广州大学这里，我们需要让程序以DHCP模式认证，但并不需要更新IP，因为系统启动后已经自动获得了。

在不同的验证系统，对信息体的校验的严紧度也不同（估计在服务器可配置）。一般静态IP模式下，需要正确的local_ip段来验证用户是否属于特定子网、端口，但是在动态DHCP模式下，在认证之前网卡是没有合法IP的，因此可以模仿Windows系统发送一个169.254.x.x的伪IP。至于网关和DNS地址，在实际使用中发现填不填影响不大，可留为0。用户名MD5就是用户名字符串的16字节MD5值；剩下的13字节则是包含认证客户端的版本号信息，也是一个普通的字符串，目前已知的版本号包括`3.5.04.1013fk'、`3.5.04.1110fk'、`3.5.04.0324'等……有些网络环境会验证这个字符串，如果客户端版本不合适，就发出相应警告，比如目前武汉大学的认证系统只能使用`3.5.04.1013fk'、`3.5.04.1110fk'两个比较新的版本号来登录，但此前广州大学的神数系统对版本号通吃。

程序里面对这个结构的初始化代码是这样的：

    u_char local_info_tailer[46] = {0};
 
    local_info_tailer[0] = dhcp_on;
 
    struct dcba_tailer *dcba_info_tailer =
                (struct dcba_tailer *)(local_info_tailer + 1);
 
    dcba_info_tailer->local_ip          = local_ip;
    dcba_info_tailer->local_mask        = local_mask;
    dcba_info_tailer->local_gateway     = local_gateway;
    dcba_info_tailer->local_dns         = local_dns;
 
    char* username_md5 = get_md5_digest(username, username_length);
    memcpy (dcba_info_tailer->username_md5, username_md5, 16);
    free (username_md5);
 
    strncpy ((char*)dcba_info_tailer->client_ver, client_ver, 13);

然后我们构建一个IDENTITY报文。帧的目的地址是802.1x标准的多播地址01-80-c2-00-00-03（这里没登出Ether帧头部信息）。

    u_char eap_resp_iden_head[9] = {0x01, 0x00,
                                    0x00, 5 + 46 + username_length,  /* eapol_length */
                                    0x02, 0x01,
                                    0x00, 5 + username_length,       /* eap_length */
                                    0x01};
    eap_response_ident = malloc (14 + 9 + username_length + 46);
 
    data_index = 0;
//以太网帧头
    memcpy (eap_response_ident + data_index, eapol_eth_header, 14);
    data_index += 14;
//EAP帧头
    memcpy (eap_response_ident + data_index, eap_resp_iden_head, 9);
    data_index += 9;
//用户名
    memcpy (eap_response_ident + data_index, username, username_length);
    data_index += username_length;
//尾信息
    memcpy (eap_response_ident + data_index, local_info_tailer, 46);

分别把以太网报文头、EAP头、用户名、信息尾复制到一个数组内，这就是我们最后要发送的报文了。

不过观察神州官方版客户端发出的报文，DCBA信息体并不一定总紧跟eap报文，其在RESPONSE MD5 Challenge 报文里面就基本位于报文的最后，开始于0xa8，中间留空了一大堆0。在zdclient里面没有这样处理，一样紧跟在eap报文后。

注意EAPOL和EAP的长度字段，如果不算46字节的信息尾，它们是相等的，这在解释EAP报文时候提到过。

当成功认证了之后，服务器大概每隔20多秒会重新发来一个REQUEST IDENTITY报文，这个REQUEST IDENTITY和认证过程中的REQUEST IDENTITY只有一个字节的差别，就是eap_id字段，认证时为0x01，保鲜阶段为0x03，zdclient里面对两个报文使用同一个缓冲区，加了个hack，发保鲜报文时候就把这个位置改成0x03。

整个EAP认证过程中需要发出去的报文也只有四种，至于剩下的两个START和OFF，都只有几个字节，不涉及神州数码的信息尾字段，跟标准里面一样。

服务器的反馈信息

我们除了构建这些发出去的报文外，其实对服务器返回的信息兴趣不大，因为只需要判断其中的几个状态位，就知道下一步该干什么了。但是神州数码的反馈报文里面通常除了这些信息尾外，在SUCCESS和FAILURE报文里面通常都会包含一段中文文字，告诉用户是什么问题或者什么通知。

这些信息PT是通过盯着抓来的报文盯出来的，因为其使用GB2312编码的中文，通常使用含高位的ASCII值，看到一堆数值都大于0x80，尝试着放到Python里面按GBK解码，才发现的。

用来搜索报文内的中文信息的python函数：

def searchgbk(byte_array):
    for i in range (len (byte_array)):
        print "[%02x] %s" % (i, byte_array[i:].decode('gbk', 'ignore'))

最后总结出中文信息的规律：
在报文的特定位置出现0x12的首导符，紧跟着一个字节表示该信息的长度，之后便是该信息。0x12出现的位置有：[0x2A]、[0x42]、[0x9A]、[0x120]

最后的完整过程可见print_server_info函数的实现，print_server_info获得字符串的地址后送入转码函数，由iconv的API转换成UTF-8编码的字符串后才由printf输出。

zdclient的报文“驱动式”实现

回顾神州数码协议的整个流程，可知基本上客户端基本上都是在服务器发来了请求报文之后才需要发出应答报文（颇有颠倒了客户-服务角色的意味），其实这样对验证服务器的压力挺大的，不过这不关我们事，而且这也方便了我们对客户端程序的设计。所以zdclient采用了“报文驱动式”的流程，就是说，除了一开始发送一个上线请求，以后接收到什么就应答什么，其他时间一直在无限循环里面loop，睡觉。

libpcap提供了回呼(callback)机制，就是设定了某个回呼函数，只有当网卡接收到特定报文时候才进行中断响应。zdclient里面的get_packet函数就是回呼函数，所有工作都是有它驱动完成的。希望这一点有助于阅读和以后再次开发zdclient的朋友理解代码。

文中出现的术语和名词，基本参考了RFC 3748的相关描述，以及Wireshark软件对相关报文的解释用词。

认证过程简述：

1. 主机向服务器（多播或广播地址）发送EAPOL-Start
2. 服务器向主机发送EAP-REQUEST-Identity要求验证身份的请求
3. 主机向服务器发送EAP-RESPONSE-Identity回应
4. 服务器向主机发送EAP-REQUEST-MD5_Challenge要求验证密码的MD5校验值
5. 主机向服务器发送EAP-RESPONSE-MD5_Challenge回应
6. 服务器向主机发送EAP-Success
7. 保持连接的通信...

当然这只是一般过程，如果在任何时候服务器发来EAP-Failure数据包，都表示整个认证过程终止。

 Supplicant主机                  服务器
 -----------                 -------------
    |------------------------------>|
    | 1.  EAPOL-Start               |
    |                               |
    |<------------------------------|
    | 2. EAP-REQUEST-Identity       |
    |                               |
    |------------------------------>|
    | 3. EAP-RESPONSE-Identity      |
    |                               |
    |<------------------------------|
    | 4. EAP-REQUEST-MD5_Challenge  |
    |                               |
    |------------------------------>|
    | 5. EAP-RESPONSE-MD5_Challenge |
    |                               |
    |<------------------------------|
    | 6.       EAP-Success          |
    |                               |

在以太网中，EAP协议当然也是通过以太网帧的格式来传送，帧类型为0x888e，在基于pcap的抓包程序中，可使用"ether proto 0x888e"来抓取。

Ethernet-Header：
################################################
#  0              5               11       13  #
# +----------------+----------------+--------+ #
# |DST--MAC        |SRC--MAC        |0x888e  | #
# +----------------+----------------+--------+ #
################################################


当用作802.1x应答帧时，常使用802.1x分配的多播地址01-80-c2-00-00-03作为目的地址。

从Wiki的简介得知，EAP协议不仅可用于本文关注的以太网环境中，还可在无线WLAN、令牌环网中应用，而这些链路帧是各不相同的，这就是为什么有EAPOL类型的数据帧，用以抽象EAP协议报文。

EAPOL-报文结构
############################################
#  0                           14 15       #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        #
# | Ethernet-Header           |a|b|        #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        #
#    17                                    #
# +-+-+-------------                       #
# |c  |Packet Body                         #
# +-+-+-------------                       #
############################################
a:EAPOL 协议版本
b:EAPOL 报文类型
c:EAPOL 帧长度

a类型说明：通常为常量0x01

b类型取值：
EAPOL-Packet :   0x00
EAPOL-Start:     0x01
EAPOL-Logoff:    0x02

各种EAP协议的信息交互，封装在EAPOL-Packet类型的EAPOL报文内。至于EAP报文的格式，基本就是如下所示。

EAP-报文结构
#########################################
#  0                            15      #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     #
# |                               |     #
# +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     #
#   17 18 19 21 22                      #
# +-+-+-+-+-+-+-+--------------         #
# |   |d|e|f  |g|EAP Body               #
# +-+-+-+-+-+-+-+--------------         #
#########################################

d:EAP通信类型
e:EAP通信id
f:EAP数据长度
g:EAP协商类型

d类型取值：
EAP-Request:  0x01
EAP-Resopnse: 0x02
EAP-Success:  0x03
EAP-Failure:  0x04

e类型说明：
通常由服务器发来的报文指定，在连续的报文内使用这个id来协商或者计算MD5值的数据之一。

g类型取值：
Identity:        0x01
MD5_Challenge:   0x04

一个EAP Supplicant客户端程序主要的任务就是处理服务器发来的数据帧和组织回应服务器的数据帧。除了根据上述的“c:EAP通信类型”和“f:EAP协商类型”位来识别协商类型外，更需要根据这些报文内的其他数据来组织回应数据帧。

下面是需要程序构建的数据包的大概细节：

（需要注意EAPOL帧和EAP帧的两处长度位置，前者的长度是不算EAPOL头的4个字节的，而后者则包含自身头部的5个字节，所以这两个长度的值可能是一致的，但具体可能有扩展信息放在EAPOL帧尾部，则前者比后者大。）

1.EAPOL-Start、EAPOL-Logoff
通常是比较简单的数据包，只需填好相应的位，没有其他附加消息，EAPOL-Start、EAPOL-Logoff两种报文长度为0，通常建立起来两个报文的长度就只有18字节。

2.EAP-REQUEST-Identity
服务器发来的这个报文也比较简单，可能唯一有用的数据是“e:EAP通信id”位，需要给发送回去的报文中把相应位设置为该值，虽然这很可能是常数。

Identity格式
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP Header      |  Username
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.EAP-RESPONSE-Identity
只需要设置“d:EAP通信id”位，然后在EAP头后紧接用户名的ASCII码信息。有些品牌的协议中，则顺带在此数据包开始校验客户端的IP、版本号等信息。

4.EAP-REQUEST-MD5_Challenge
服务器请求MD5校验的报文中包含了重要的信息，首先也是“e:EAP通信id”位，后一个报文也需要设置该位；
在EAP报头后紧接一个一位的长度值L（常量0x10），表示紧跟其后的重要数据的长度，其后的16位值则需要用来计算下一个报文中的信息，我们称之为attach-key。

MD5_Challenge格式
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP Header      |L|MD5-Key/Value
+-+-+-+-.....-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.EAP-RESPONSE-MD5_Challenge
首先需要设置“d:EAP通信id”位，然后构建一个这样的字节数组［(e:EAP通信id)(用户密码的ASCII)(attach-key)]，这个字节的长度当然是(1+用户密码长度+16)，然后送入MD5计算函数中，获得16位的计算结果，再把这16位计算结果填入报文。报文格式跟请求的类似，在包头后紧接一位长度值，当然是0x10，然后是16位的计算结果。

一个客户端程序所做的事情通常就是这么多，而因为EAP协议的“Extensible”的特性，几乎我们见到的每个品牌的协议都有所扩展，而且各不相同，所以各个品牌之间的客户端甚至交换机等设备都可能完全不可兼容的，其协议很可能在上述的报文中都添加一个信息尾，用来校验各种信息，具体的情况请留意PT博客的后续文章。

项目主页：http://code.google.com/p/zlevoclient/

欢迎大家帮忙测试使用！

使用起来应该没太大变化，只是让协议更接近官方客户端的过程。现在主页上同时有二进制包和源代码包下载。

项目主页：http://code.google.com/p/zdcclient/

连续一个星期每天一个版本，= .=有点不可思议的说……

经过跟武汉大学的michel同学不断的折腾和测试，终于搞清楚他们学校动态DHCP的流程了，“Windows启动后，提示本地连接受限”，到认证后才开始获取IP，这才是动态DHCP模式，所以使用ZDClient的dhcp后，需要运行系统的DHCP客户端重新获取一次IP（通常是dhclient），这一点功能在启动脚本dhcp_zdc_run.sh内已经包含。

现在在Google Code上面的项目已经正式启动，终于用上svn的服务器了，不用把桌面搞的一团糟。

大家可从项目主页下载最新的源码包：http://code.google.com/p/zdcclient/

之前的网盘链接已经作废。

特别感谢一下刘群同学的关注，给我编译i386的binary，我似乎终于搞定在amd64使用32位的包了！

在姚老大的群里面找到武汉大学的同学micheal帮忙测试了ZDClient，昨天晚上把他们的官方客户端的数据包抓了过来看，原来版本是3.5.04.1013fk，比我们的新！不过奇怪的是广州大学的认证服务器除了用户名密码别的似乎什么都不认证，我怎么乱填都能认证成功 = .=

顺便提醒一下武大的同学，记得在zdcrun里面加上--dhcp参数……

大家可从项目主页下载最新的源码包：http://code.google.com/p/zdcclient/

0.2 更新
-整理代码
-进一步完善包解析、发送过程细节，加入遇到为止包时的提示
-区分EAP_RESPONSE_IDENTITY和EAP_RESPONSE_IDENTITY_KEEP_ALIVE发送的包
-加入自定义客户端版本号的功能参数--ver，并能校验版本号长度
-默认版本号改成3.5.04.0324
-修改--help内About ZDClient的文字
-在认证是提示协议版本信息
-增加可检测root权限的启动脚本

大家可从项目主页下载最新的源码包：http://code.google.com/p/zdcclient/