联系博主
Email or Gtalk:
'Unix/Linux' Category
-
ZDClient 0.5版发布
五月 22, 2009改善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模式的认证
五月 21, 2009神州数码客户端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位的包了！
-
神州数码客户端ZDClient升级到0.3，支持武汉大学的校园网
五月 20, 20090.3更新-客户端默认版本号更新为3.5.04.1013fk-修正对SUCCESS数据包的识别-后台运行改为在认证成功后主程序返回-根据状态区分用户名、用户配置信息错误与密码错误的两种提示-在接收和发送Keep Alive报文时提示当前线程的pid-改善pcap的抓包过滤器，只抓发往本机的报文 在姚老大的群里面找到武汉大学的同学micheal帮忙测试了ZDClient，昨天晚上把他们的官方客户端的数据包抓了过来看，原来版本是3.5.04.1013fk，比我们的新！不过奇怪的是广州大学的认证服务器除了用户名密码别的似乎什么都不认证，我怎么乱填都能认证成功 = .= 顺便提醒一下武大的同学，记得在zdcrun里面加上--dhcp参数…… 大家可从项目主页下载最新的源码包：http://code.google.com/p/zdcclient/
-
神州数码客户端ZDClient升级到0.2
五月 19, 2009今天对比了官方拨号器的报文，改进了一下包分析流程。广州大学的方案似乎做很少校验，有些东西乱填都照样能过。同时也把协议版本修改到3.5版本的，之前在Wiki页有武汉大学的同学求助说他们学校的神州数码因为3.5的版本校验没法使用姚琪的版本，在这里召唤武汉大学的同学来帮忙测试ZDClient了，哈哈。 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/
-
神州数码802.1x认证的C语言版客户端
五月 18, 2009一直以来在Linux下要接入神州数码认证用的是姚琦开发的Java版认证工具，不过现在起，使用神码的同学可以把jvm抛弃啦！PT开发出了C语言版的神州数码802.1x客户端！ 项目主页：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，不是我不想睡，而是有问题晾在那里没解决就睡觉的话，就只会整晚失眠了。逃了一天课，终于大功告成，本来还想实现配置文件的功能，不过想想还是算了，很容易就能用脚本来记录。
-
无损转换ext3到ext4，with Ubuntu Jaunty 9.04
四月 29, 2009Ubuntu Jaunty 9.04开始正式支持ext4文件系统，关于ext4，其优点应该早有听闻，对任何用户而言都具有难以拒绝的诱惑：对一般用户而言，有更好的磁盘性能，快速的预分配、删除，更可靠的日志，更迅速的磁盘检查（不会像ext3可能花几分钟来check，ext4经常是瞬间完成的）……更专业的描述可以看看IBM文库的这篇《Migrating to ext4》。 从Ubuntu 8.10升级到9.04，一定程度上是看上其对ext4的支持，不过如果为此重新格式化分区重装系统，对于使用积累较多的系统来说代价太高了点（PT现在用的系统是去年的8.04，后来升级8.10，再到现在的9.04……），不过根据《Migrating to ext4》的说法，从ext3到ext4的无损转换是可能的，而且并不耗时间，就如Kernel Wiki里面的Ext4 Howto提到转换所用的命令，其实也很简单： tune2fs -O extents,uninit_bg,dir_index /dev/DEVe2fsck -fD /dev/DEV 查了下tune2fs的man页，uninit_bg是支持快速check的特性，dir_index则是创建二叉树散列的目录查找，至于extents在man页没提到，Kernel Wiki里面说是ext4专有的特性，完成后用e2fsck check一次，这样就完成ext4的转换了，整个过程的耗时并不多。 不过这样转换出来的分区有点不完美的地方是，原本存放在分区内的文件结构还是ext3的结构，由ext4的机制透明兼容，以后存放的文件才是ext4的格式。本来影响不大的，不过相信会影响众多完美主义者的精神状态，所以很多人宁愿把文件全复制出来，格式化了分区再复回去。 IBM的文章内提到，因为ext4支持了在线的碎片整理，对于转换的ext4，使用e4defrag整理一遍，就是纯种的ext4了，不过到目前为止，e4defrag并未完全可用。不过相信不久的将来，转换到纯种ext4完全可以一气呵成的。 最近有谣言说/boot不能是ext4，不然grub引导不了。事实上Ubuntu 9.04已经完全支持ext4，不然此前怎么会有ext4系统的9.04 21秒引导系统的新闻？不过对于升级过来的9.04，安装在/boot/grub里面的程序还是旧版的，没有自动升级，因此可能出现引导问题，相信这也是谣言的出处，所以升级过来的同学要注意了。可以使用grub-install来重新安装一次grub的文件，就如《Upgrade Ubuntu 8.10 to Ubuntu 9.04 and ext3 to ext4 in 10 Minutes》那样。不过grub-install有点要注意，grub-install复制的文件是以/为起始位置的（特别是使用了--root-directory=DIR参数的），如果boot单独分区，同时在livecd里面单独挂载了出来，很可能新复制过去的文件会多了一层boot目录，变成新旧版的引导文件共存以致没法引导grub……(我也感觉我说得一塌糊涂了……总之boot独立分区的同学使用grub-install注意它究竟安装到什么地方去了，看看相应文件的修改时间)。 对于从ext3升级到ext4的系统，还有重要的一点就是fstab，完成上述的操作后，先运行blkid查看分区的新UUID，用编辑器打开/etc/fstab，替换转换了的分区的UUID，当然还有挂载类型改成ext4。
-
围观一下Linux下歌词新星：lrcShow-X 1.0.0
四月 25, 2009lrcShow-X是基于pyQt、dbus等技术的一个歌词显示工具，比起此前出现过audaciois、amarok等的歌词显示脚本或者插件，lrcShow-X可谓一颗新星，首先其目前为止已经集成了一个歌词显示器需要的所有功能（参考千千静听等成熟的应用），编辑歌词、Mp3内嵌歌词等一个不缺，甚至用到被Ubuntu Jaunty发扬光大的OSD来显示。 虽然说目前并未和哪个播放器合为一体（插件形式），但不是难事，lrcShow-X通过dbus接口支持了audacious、amarok、vlc、exaile、quodlibet、qmmp等播放器，已经有人做到和amarok界面内嵌。 lrcShow-X的优秀表现，很大程度上是其内置了主流的歌词服务器，PT实际使用中觉得sogou搜出来的歌词比较出色。 目前使用lrcShow-X的使用方法略显简陋，需要启动播放器后自己在命令行内运行./lrcShow-X.py，但一点也遮蔽不了其强大的光芒。 ps: 在Ubuntu下使用lrcShow-X需要安装的包： sudo apt-get install python-gobject python-qt4 python-ibus 链接：http://www.sanfanling.cn/read.php?267下载：http://www.kde-apps.org/content/show.php?content=103055
-
通过Wine使用Sogou浏览器的教育网加速代理
四月 14, 2009此前用wireshark嗅探研究过Sogou浏览器的代理功能，没什么头绪，有访客留言说用Process Explorer瞧瞧Sogou的进程，今天有空看了下，果然，有一个子进程是用-proxy参数启动的，打开了本地的8081和8082端口在监听，用其他浏览器连8081，发现就是普通的透明代理，而8082则是一个自动配置代理的PAC（Javascript）。 虽然现在我的Ubuntu下已经有了一堆翻墙用的代理软件（没边、门、eTunnel……），但经常速度不甚理想，而且学校校园网的电信出口经常被挤爆，而教育网出口是空的，所以使用Sogou提供的免费教育网代理是个不错的解决办法。 把Sogou弄到Ubuntu下的Wine环境没有任何难度，把Sogou的安装文件夹全部复制到~/.wine/drive_c/sogou下，运行的很正常： pentie@pentie-desktop:~$ wine "C:\sogou\SogouExplorer.exe" -proxy fixme:win:EnumDisplayDevicesW ((null),0,0x32f3c4,0x00000000), stub! fixme:wtsapi:WTSRegisterSessionNotification Stub 0x1002a 0x00000000 fixme:mountmgr:harddisk_ioctl unsupported ioctl 74080 fixme:mountmgr:harddisk_ioctl unsupported ioctl 2d1400 fixme:mountmgr:harddisk_ioctl unsupported ioctl 2d0c10 PID:8 PORT:8081 CPORT:8082 PAC:http://127.0.0.1:8082/proxy.pac?t=626 RET:SUCCESS 在配置Firefox的FoxyProxy，可以像平常那样添加127.0.0.1:8081作为代理，但既然提供了PAC，不妨试试：在Automatic proxy configuration URL内添入“http://127.0.0.1:8082/”，按Test，说找到PAC，解析成功！确定后右下角也出现FoxyProxy的提示。此时在Firefox中打开的网页都是通过Sogou的免费代理了！不过发觉现在的代理速度没此前那么快了。 Ubuntu中有一个工具可以配置全局代理，gnome-network-preferences，运行它可以轻松的让apt-get、telnet之类的程序通过代理来连接外网。 再一次提醒的是，Sogou浏览器代理是“透明代理”，它会转发你的真实IP，没有任何匿名功能，因为他们的服务器也在国内（北京），因此也不会有翻墙功能。 参考了别人的网志：http://dan.febird.net/2008/12/firefox.html 已知缺陷：在流量和连接数比较大时（比如刷开Google Reader），wine出来的SogouExplorer进程占用大量CPU资源，可能是某链接库匹配问题，以致这个方法的实用性不是很高。
Page optimized by WP Minify WordPress Plugin