联系博主
Email or Gtalk:
'Programming' Category
-
完成一个LCD4Linux的USB屏幕
九月 6, 2009暑假之前就注意了LCD4Linux这个Project，简单说，这就是个硬件版conky的驱动服务，用户自己DIY各式各样的硬件屏幕，自己编写驱动、编写各种插件来控制输出到屏幕上的信息，LCD4Linux就是这样一个平台，也是一个geek味道非常浓郁的、可玩性相当高的一个Project。 图片里面是LCD4Linux项目页里面收集的部分人实现的一些屏幕，有像我这样一块小小的1602，也有用块10多寸的液晶屏作成很拉风的监控屏，甚至，挂一个户外广告那样的LED阵列，你也可以转换成VGA信号输出给大屏幕的电视机，或者弄个天线发射出外太空都是可能的…… 这个项目的可玩性就在于硬件的多样性，很可能每个人实现的屏幕都不一样，而作为开源项目，geek们只需或多或少地修改一下别人的驱动就可让屏幕跑起来了。 我实现的这块，是用了一块通用AVR单片机，通过USB接口直接取电和传输的数据的架构，硬件和协议参考的是LCD2USB项目。其原来用的是atmega8芯片，而我手边只有atmega48，算是类似吧，但换换IO口还是在所难免的。 实现一个系统，同时也藉此了解一下相关的技术（不然还真的很难做得出来），首先是USB，USB我们天天在用，但是学校的《微机接口》之类的课程可从来不涉及这些“时髦”技术的，虽然USB已经流行了10多年了。通过V-USB库，在AVR单片机上实现USB设备还真没什么难度，只需要填写设备ID设备名称之类的，然后再实现协议处理函数就完了，在Linux下使用是直接支持，一插上运行lsusb就能认出（Win下需要另外装驱动）。我第一个实验USB就是接了几个二极管开关，用libusb的python binding， pyusb，很容易就控制几个灯。（想起The Big Bang Theory S1E9开头那一段，再import个SimpleHTTPServer，然后让单片机连接几个继电器，就能像他们那样让别人用浏览器来开关我的台灯了，哈！） 其实单纯几个LED都能够作为LCD4Linux的一个设备了，比如能够用来做邮件提醒、pidgin消息之类。同样是用V-USB，有个德国人做了个叫USB-LED-Fader的东东，同样是几个LED，人家可实现了每个灯在pwm控制下以独立的方式闪亮，要知道，atmega8只有两个pwm channel，而USB-LED-Fader里面没有用硬件pwm，而是用io口来输出的，为了实现独立波形，还实现了一个message queue，俨然一个操作系统了……所以他的固件编译出来4K多，即使我修改后也刷不进去mega48里面，就没得看看他的效果了。不过赞一下的是，这个项目虽然是玩具级别的，但是人家的电路、电路板、固件代码（注释）、文档、上位机控制（包括win版、win驱动）通通一应俱全，非常规范和详细，俨然一个商业项目。 将USB模块跟显示屏驱动模块合起来并没什么难度，几个月前我自己写过这个1602的驱动程序，虽然当时花了好几天，但实际上都只是很简单的几个函数。不过这次，因为接上USB后这块28针的mega48就没那么多io给我挥霍了，此前的驱动用的都是8位数据线，现在只能用4位，分两次传送。不过还好，这类HD44780的驱动几乎满地都是，一般外国人写的不像国内一些网站上面的，扔几个函数在那里就完事，LCD2USB的代码里面用的是Peter Fleury的LCD Library，封装得很漂亮，不过原来的代码只能讲4位数据线连接在一组io口的高四位上，而接上外置晶振后的mega48仅剩的带高位PortD，刚好又是几个pwm波输出，我打算另外再扩展协议让LCD2USB带有几个漂亮的提示灯，就重写了一下LCD的两个底层函数，当然不是仅仅重写，不然对不起原来那些漂亮的代码，用了宏定义来设置数据线是接在HIGHER_BIT or LOWER_BIT。 其实相比之下，LCD4Linux最精彩的地方在于它的驱动、插件的编写，新版里面其也支持了Python，意味着做个硬件版twitter器不是什么难事了！不过LCD4Linux本身的安装让我困扰了一天，大概作者没有时间吧，这个项目的主代码很几年没更新了，一个版本更新的跨幅有好几年，以致稍旧点的版本在新版本的内核里面编译不了，比如有个rdtscl的宏调用，在新内核里面被移除了……这个问题在LCD4Linux的SVN里面的版本倒是解决了，但是因为autotool的更新，编译过程又出错，折腾了半天，发现原来autoconf检查python的模块ac_python_devel 因为莫名的原因会让configure文件出错，下载一个新版的ax_python_devel.m4覆盖掉就好了。另外发现AUR里面的lcd4linux-svn包是“弃婴”，于是“收养”了回来更新，添加了个编译的patch，现在Archer们直接yaourt lcd4linux就可以编译安装了，O.O . 还是一句，LCD4Linux的可玩性非常高，说技术性嘛，不算高也不算低吧，召唤大家一起玩一起交流哈……
-
深入了解校园网802.1x认证的EAP协议(3)——联想802.1x认证细节
八月 24, 2009联想的认证协议是我写的这几个802.1x实现里面相对简单的版本，没有太多古古怪怪的信息头信息尾部。 我们学校并没有使用过联想协议的认证系统，而是受了一位网友的邀请才写的，所以我连联想官方客户端的样子都没看到过，一直是由那网友抓包后发送过来，而我猜测地将其套入到此前我写的神州数码的认证程序里面，经过几天的调试，确实能用，虽然并不完全了解认证报文的每个细节。 PT实现的联想Linux客户端项目主页：http://code.google.com/p/zlevoclient/ 以下的说明是基于EAP协议过程的补充描述，如果不清楚EAP，可先读深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程。 认证过程报文的细节描述： EAPOL-Start、EAPOL-Logoff设置长度为0的协议包头，然后紧接6个意义不明的字节（可能是版本号之类），直接复制即可： {0x00, 0x00, 0x2f, 0xfc, 0x03, 0x00}; EAP-RESPONSE-Identity长度为5（头部） + username_length，无特别，跟EAP标准一致， EAP-RESPONSE-MD5_Challenge长度为6（头部） + 16（MD5值） + username_length，在MD5值之后，先紧接用户名，然后是4字节的本机IP地址，以及9个意义不明的字节，直接复制：{0x00, 0x00, 0x2f, 0xfc, 0x00, 0x03, 0x01, 0x01, 0x00}; 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。
-
油猴脚本：Twitpic in itweet！
八月 17, 2009油猴脚本 Thumbnails in iTweet 安装：http://userscripts.org/scripts/show/55788 作用：自动在itweet的twitpic/flic.kr的连接后插入预览图。 油猴：Firefox插件，原名GreaseMonkey，安装。 最近越来越浸入twitter圈的生活了，每天一打开浏览器就是itweet跟google reader，手机上就用opera mini开着dabr。 注意到新版的dabr能够将包含的twitpic链接信息的显示出缩略图，很不错的功能，想要是itweet也有就好了！ 于是抄起久违了的javascript写了个油猴脚本。刚开始实现的版本很简单，只是载入页面后扫描页面元素，用正则判断a元素的href，符合twitpic的就在它里面append个Child……但是效果很不理想，要知道itweet是纯ajax的应用，整个document的内容是一直变化的，必须要跟原来的程序互动起来才能实现完美效果……itweet主要用了jQuery和一些插件来实现各种功能，虽然之前没玩过jQuery，看了itweet.js里面的一些代码和jQuery官方的文档，被其灵活的selector震撼了！web类的应用就应该这样嘛……相信HTML5也会有类似的选择器，太强大了。 使用jQuery改写后的代码简洁多了，每个函数都是3、5行的样子，凑合起来效果还算理想，同时相应用户点击的链接，以及在后台使用一个10s的定时器检查和更新图片的url。 搜索关键词#SZTwitParty看深圳推友聚会的页面，好壮观哇，哈哈！
-
Win32版本的锐捷客户端zRuijie4GZHU
七月 29, 2009花了几天时间，将zRuijie4GZHU的代码用Win32 API封装好了。 怎么突然给“万恶“的Windows开发程序呢，呵呵算是一时冲动好了，因为此前对Windows的API基本一无所知，虽然大二的时候C++的课程教了一点MFC，不过离开底层API来说MFC，真的很腾云驾雾，转眼就全忘记了，交课程报告时候用VS的Wizard大概地弄个两个窗口，甚至说不清一个控件是怎么被创建的……画上去的？嘿嘿…… 这次做Win的程序算是为了了解一下Win下面的模式，程序使用纯SDK API来写。开着虚拟机，开始的时候用Dev CPP来做，但没一会就忍不了那个编辑器的白痴了，还好Devcpp提供了项目的Makefile，于是用Notepad++来弄代码，开着个cmd窗口来编辑；最后还是把代码弄到Linux来，装了个mingw来cross，用gvim来写代码才有快感。程序的resources使用ResEd来做，很不错的小东西，用wine来跑一点问题都没，哈。 写win32过程我想最多的就是GTK，感觉Win32那些API很有考古的感觉，比如说指针类型，不知道有没有人统计过究竟微软发明了多少个类型，LPSTR，LPCSTR，INT_PTR，LPVOID TMD匈牙利命名法，就不能用好看一点的名称～ 对比起来，win32最原始的地方应该是消息处理过程吧，看着形态怪异的DlgProc，很郁闷的感觉；GTK只需要按事件类型来注册回呼函数，所以我写的的Proc基本都是用函数把处理过程引了出来。 代码依然扔在Google Code：http://code.google.com/p/zruijie4gzhu/
-
低调发布个锐捷客户端：zRuijie4GZHU
七月 8, 2009zRuijie4GZHU 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 /* * [...]
-
深入了解校园网802.1x认证的EAP协议(2)——神州数码认证细节
七月 4, 2009各地的校园网认证有很多种品牌，正因为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字节的信息以供验证。
-
深入了解校园网802.1x认证的EAP协议(1)——EAP的总体流程
六月 9, 2009EAP（Extensible Authentication Protocol），是一个普遍使用的认证机制，详细介绍可见Wikipedia。本文介绍的，是被广泛使用在国内高校校园网的认证机制使用的EAP协议，暂不具体地说明某个品牌的私有协议如何如何，而是从整体角度看EAP协议如何工作，从一个第三方Supplicant客户端的开发者角度解释EAP的通信机制。在后续的章节将继续介绍PT接触过的几种认证协议中，国内的“标准践踏者们”如何实现各种变态的认证协议。 文中出现的术语和名词，基本参考了RFC 3748的相关描述，以及Wireshark软件对相关报文的解释用词。 认证过程简述： 主机向服务器（多播或广播地址）发送EAPOL-Start 服务器向主机发送EAP-REQUEST-Identity要求验证身份的请求 主机向服务器发送EAP-RESPONSE-Identity回应 服务器向主机发送EAP-REQUEST-MD5_Challenge要求验证密码的MD5校验值 主机向服务器发送EAP-RESPONSE-MD5_Challenge回应 服务器向主机发送EAP-Success 保持连接的通信... 当然这只是一般过程，如果在任何时候服务器发来EAP-Failure数据包，都表示整个认证过程终止。 Supplicant主机 服务器 ----------- ------------- |------------------------------>| | 1. EAPOL-Start | | | |<------------------------------| | 2. EAP-REQUEST-Identity | | | |------------------------------>| | 3. EAP-RESPONSE-Identity | | | |<------------------------------| | 4. EAP-REQUEST-MD5_Challenge | | | |------------------------------>| | 5. EAP-RESPONSE-MD5_Challenge | | | |<------------------------------| [...]
-
Linux程序已运行实体的检测以及其PID的获得
五月 25, 2009程序中经常需要有这么一个功能：只允许本程序的单个实例运行，即不能多次运行一个程序。检测某个进程是否在运行，在shell中可以很轻松的用命令ps -A|grep xxx找出来，但对于程序来说，该怎么检测呢？我参考了aecium程序的方法：同样调用ps -A|grep xxx。也许会存在更先进的方法，比如dbus、系统信号量之类的技术，总之这个不会是最好的方法，不过且看看其技巧。 首先要获得当前进程的名字以便传给grep，一般通过main的argv[0]可得到运行时的程序名，不过要注意的是，通过路径运行的程序如./a.out，argv[0]也是./a.out的。 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 41 42 43 44 45 46 47 48 49 [...]
Page optimized by WP Minify WordPress Plugin