下载了个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/

这就是我们研究这些厂商自定义的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的朋友理解代码。

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

项目主页：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/

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

开发手记

PT的客户端版本虽然是命令行的版本，但是功能和姚琦的Java版功能没多大差别，目前支持自定义接入网卡、支持DHCP、支持程序运行后自动fork到后台，用户名等通过参数传入程序。

Java版的软件虽然一般使用起来没太大区别，但是当系统中没有jvm虚拟机和软件依赖的库，而且电脑又不能上网的时候，这可是相当棘手的问题，我去年就为此在Ubuntu-cn的Wiki写了一篇教程，如何从源里面抓jvm的一堆包回来安装，再折腾一番才能用。况且Java程序占的资源颇大，就那个0.6.1版的客户端，常驻内存有50M！

姚琦的个人网站上面公布了他的客户端软件的源码，之前有下载回来，不过一直没看，早天兴起把文件重新放到Netbeans里面来编译一次，发现能编译却不能认证！好奇之下跟踪了其代码，把带界面的1500多行的程序删减到只剩400行的命令行程序，然后再根据抓数据包的对比，发现是这个版本获取本机地址的代码有问题，在Linux下获取本机IP是错的，这样组成的数据包去认证，当然不行了，具体在这里有人解释。

摸清楚认证过程的来龙去脉后，就打算自己用C来写一个客户端，虽然我有2G内存，但老被占着几十M也不舒服。Java里面用的jpcap，是Java用JNI对libpcap的封装，之前我弄过编译amd64版时候接触过，发现其功能很强大，使用也不复杂，于是对写个原生C语言版的客户端也有了信心。

为了弄清整个程序的工作流程，我进一步优化了Java版的代码，400多行最后剩下200多了，姚学长的编码好像有点太过那个，呃……而且姚学长好像连jpcap的toturial都没有读完，竟然使用一堆if来过滤抓到的数据包，怪不得之前内网传文件达10M速度的时候，客户端占的CPU狂飙了。为捕捉过程设置了驱动级别的过滤器，使用回呼方式抓包，对一些函数流程进行重构，最后这个版本运行的时候占内存不到10M，CPU占用率也低多了。

这两天对着一个libpcap的抓包示例，一步步地将包分析的功能改了出来，然后就是手动创建的报文，其中一个小插曲是用到的MD5算法，在Java中有个内建的digest功能，但C语言哪来这东西，上网找，连续下了几个版本，测试一下，有些算出来的值是错的，有些每次算出来都不一样，气死我了，看来是因为我现在用的是amd64版本的系统，算法里面的数据类型不兼容所致。最后在MD5 Homepage (unofficial)找到了L. Peter Deutsch's的版本才正常。

对着wireshark满是16进制数的窗口用笔划了两天框框彻底搞清楚了协议包的结构，然后在gvim里面倒腾了代码，终于程序完成了。不知为什么，写这个程序有很亢奋的感觉，昨天晚上是搞到3点钟才睡，然后早上7点多就爬了起来继续coding，不是我不想睡，而是有问题晾在那里没解决就睡觉的话，就只会整晚失眠了。逃了一天课，终于大功告成，本来还想实现配置文件的功能，不过想想还是算了，很容易就能用脚本来记录。