apt-blog.net IT民工养成计划 PT博客

Insion同学之前发来一段可以在MacOS/BSD编译运行获取网卡MAC地址的代码，于是整理了一下，让几个802.1x Client都能支持MacOS/BSD了。

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

联想的认证协议是我写的这几个802.1x实现里面相对简单的版本，没有太多古古怪怪的信息头信息尾部。

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

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。

zRuijie4GZHU Google Code：http://code.google.com/p/zruijie4gzhu/

其实这个项目的目标不是非常明确，至少到目前为止，能在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可扩展的特点，基本上每个品牌的认证方案都会互不相同。从商业角度考虑，当使用了某个品牌的认证系统后，很可能就不能使用其他牌子的交换机了；而对用户来说，这不仅带来了以后维护的问题，还因为各个厂商开发的EAP客户端的投入不同，质量良莠不齐，占用内存大、限制多（比如有些为了防止用户开代理，加入多网卡检测，结果用户就不能使用虚拟机、手机GPRS Modem等）、不支持非Win平台。

这就是我们研究这些厂商自定义的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字节的信息以供验证。 ...
[阅读全文...]

EAP（Extensible Authentication Protocol），是一个普遍使用的认证机制，详细介绍可见Wikipedia。本文介绍的，是被广泛使用在国内高校校园网的认证机制使用的EAP协议，暂不具体地说明某个品牌的私有协议如何如何，而是从整体角度看EAP协议如何工作，从一个第三方Supplicant客户端的开发者角度解释EAP的通信机制。在后续的章节将继续介绍PT接触过的几种认证协议中，国内的“标准践踏者们”如何实现各种变态的认证协议。

文中出现的术语和名词，基本参考了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博客的后续文章。

在湖南人文科技学院imagelife同学的邀请和帮助下，通过分析wireshark的抓包编写出来的的认证客户端。由于之前有了写ZDClient的经验，似乎上手比较快…… 联想的协议似乎更简单，没有神州那样在报文里面附上一大堆ip阿网关阿DNS这些恶作剧的东西，所以直接拿了ZDC的代码来删删删，然后根据他们整理出来的一份协议的简单分析，已大概整理出了雏形。

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

欢迎大家帮忙测试使用！

• 改善DHCP模式下的认证IP处理方法：
  若程序能够从网卡获得IP，则使用网卡的真实IP
  只有获取不到IP时才使用伪IP 169.254.216.45
• 在使用伪IP的情况下，当接受到第一个REQUEST IDT KEEP ALIVE报文后，尝试再次获取网卡IP与MASK并写入RESPONSE数据帧缓冲区替换伪IP，之后发出的RESPONSE数据帧将包含真实IP
• 只有当用户同时指定了IP和MASK才使用用户设定值，否则由程序处理IP
• 修正一些stderr、stderr的滥用

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

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

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

神州数码客户端ZDClient升级到0.4，完善DHCP模式的认证

经过跟武汉大学的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位的包了！