转载:开源路由器固件上Bug的故事(二)

花了很大的气力讲了开放源代码第三方家用无线路由器固件的基本情况和绕过这个 bug 的办法。绕过 bug 在很多时候不失为一种有效的选择,特别是像之前我遇到的情况:开发组在一年内都没有对 bug report 作出任何响应。所以在失望之余也只好另辟奚径了,再用俗话说一遍就是“惹不起,躲得起”。

下面把话说回来,毕竟文章的主题是 Bug 的故事,所以还是要接着往下说。只是后面的东西更偏向于技术,所以比较枯燥一点。

3. Bug 的认定和定位

这个 Bug 之所以让我记恨于心,的确是因为它太复杂了:从 bug 的发现认定,到 bug 定位和 bugfix,由于没有正式的官方支持,OpenSource Community 这种散兵游勇的开发全靠分散在各地的个人,每一步的进展都很艰难。

这个 Bug 造成的问题是目的MAC地址为 00-80-C2-00-00-03 的 802.1X 多播认证包被无线路由器丢弃(不会转发到 WAN 口),这样在路由器上运行的 Supplicant 程序在发出 logon request 之后便再也收不到回复。问题其实很明显,因为使用同一个程序,把网线插到 PC  上便能通过认证,显然就是路由器处理的问题。

那为什么说 bug 认定是一件麻烦事呢?因为后来才确定这个 bug 只存在于 Broadcom® 公司的 Roboswitch™ 系列交换芯片中。早期的 Linksys WRT54G 路由器使用的是 ADM6996L 交换芯片(ADMTek 已经被 Infineon 收购),在进行认证的时候是没有问题的。所以这个问题在此型号的机器上无法重现,再加上大家都从软件角度来思考(其实这是个硬件问题)。最后导致了两种声音:一种声音坚定地说自己遇到了 OpenWRT 的 bug,另一种声音说,这个 bug 在我的机器上无法重现,不能认定。这两种声音可以在 OpenWRT Trac 上的 Ticket 1862

看到。

 接下来有人发现“It has also worked for me on WRT54G 1.0-2.0. On WRT54G 4.0 it does not work.”,大家这才意识到这是 BCM5325 交换芯片搞的鬼。后来的 BCM5352 和 BCM5354 芯片内部都集成了一个交换模块,因此也理所当然地继承了这个 bug 。

修订:根据 jacky235 的消息,8230-4 和 WZR-G108 使用了 BCM5325A2KQM 交换芯片,但可以通过认证。而 OpenWRT Ticket 1862 上出现问题的是 BCM5325E 交换芯片,此芯片支持额外的管理功能和 802.1x EAPOL filtering 。所以将出问题的交换芯片定位到 BCM5325E 上面。集成了交换芯片的 BCM5352 和BCM5354 依然有问题,这个我自己可以证实。

此 Bug 的产生机理是什么呢?其实话说回来,这本来是 Braodcom 设计出来的 feature ,目的是为了使交换芯片的工作模式更加灵活一些,可是 Broadcom 的保守和封锁让这个 feature 在这里适得其反。(关于bug 和feature 的辩证关系,请看 atppp 的文章

)如果芯片工作在 Default Mode ,那么会丢弃 802.1x 认证多播包 00-80-c2-00-00-03 ,如果芯片工作在 Frame-Management Mode ,则会把此包转发到 Frame Management Port 。如此简单的逻辑

4. Bugfix 和当前问题

这个 bug 的修复就更棘手了。人们总算搞清楚了问题的所在,但就是没办法去修复它。因为你无论是 Google、Yahoo 还是百度都找不到详细的 BCM5325 芯片资料。所有宣称有 Datasheet 的网站上下载回来的只有两页纸的 Product Brief。这东东在 Broadcom 自己的网站上就能下载到,无非就是花一页纸吹了一下自己这个芯片有如何如何的 feature 云云,然后再花了一页纸作 Overview,扔一个架构图上去完事儿,真是印证了 Brief 这个词。

后来我才从某个网页上无意得知,Broadcom 的 Datasheet 一般是不公开的。只在有渠道的代理商那儿有,只有从人家那儿拿货然后签订一个保密协议,人家才会给你一份 PDF 文档。当然给你的文档是没法传播的:每一页纸上面都斜贯着长长的一串水印——谁泄露出去了谁承担责任。Broadcom 这招的确狠,可也给 bugfix 工作设置了最大的屏障。

针对这个 bug 给出解决方案的是 Jouke Witteveen。他的解决方案没有去 patch OpenWRT,而是给 wpa_supplicant 上的 wired Driver 作出了修正。他提出了一个新的 roboswitch driver 专门用于 Roboswitch 上的 802.1X 认证。我现在寝室里用的 Buffalo WHR-HP-G54 上就使用此程序通过了学校的 802.1X 认证。然后再运行一个 mytunet 来打开网关上的出校访问权限。这样就可以在全天时间使用无线网络了。(熄灯停电时除外……)

这个 bugfix 我用了大半年了,还是比较顺利的。只是最近在恩山无线论坛

上看到了很多人受困于 H3C 和锐捷的私有 802.1X 认证。于是有人打算在路由器上运行 Linux 版的认证程序从而通过校园网认证。无奈的是这个 bug 再一次阻止了一大部分人的企图…… 很多人新买的路由器比如 WHR-HP-G54、WL-520gU、WHR-G125 等都有 roboswitch 的身影,移植过来的认证程序在 PC 上跑跑当然可以,可惜是没有针对性地解决 Broadcom roboswitch 的问题。自然也逃不过此 bug 的追杀,恩山上铩羽而归的人不在少数。

幸运一些的人有两种可能。一种是使用的 Belkin 7231-4p(不管有没有经过恩山无线的改版)它使用了 ADM6996L 交换芯片,没有此问题。另外一种是像 felix021

同学那样的,虽然路由器是使用 BCM5354 芯片的 WL-520gU,但校园网认证协议使用广播包(MAC为 FF-FF-FF-FF-FF-FF)而不是多播包。所有的交换模块接到了广播包当然是无条件转发。因此也能顺利通过认证。

不幸运的该怎么办呢?    可以移植 Jouke Witteveen 在 roboswitch 中使用过的方法,在私有协议的认证程序中加入 Broadcom 芯片的支持,则有希望通过认证了。我已经跟 Jouke Witteveen 取得联系,他毫无保留地提供了一份 leaked document 给我作参考,十分感谢。

转载:开源路由器固件上Bug的故事(二)》有3个想法

  1. 李建邦

    你好 我也最近也纠缠着rg100a/ha910上面的BCM5325芯片的这个BUG快两个星期了 我也使用了 Jouke Witteveen所提供的roboswitch driver的办法但是尝试了很多次,目前结果如下:1、最开始报错:“wpa_driver_roboswitch_init: Invalid phy address (not a RoboSwitch?)” 于是修改源代码 打印出来调试信息发现ROBOSWITCH的PHY_ID是0x1E我的路由器是0x00,于是我强行修改了源代码中的ROBOSWITCH_ADDR的宏为 0x00;
    2、接着报错“wpa_driver_roboswitch_init: Could not get port information for VLAN 1
    ”于是我无语了
    麻烦您看到这条留言不吝赐教一下,我的QQ:523823374;gtalk:ljbha007@gmail.com

    回复
  2. David_Shun

    我也遇到了和你一样的问题 请问解决了吗?
    我的邮箱xy001964@gmail.com

    回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注