2003年7月16日 星期三

關於 Dlink 650+ for Linux

各位看倌, 有人用過 Dlink 650+ wireless card 嗎?
今個兒, 我想談談這個卡用的 TI acx100 chipset 的故事...
首先, 我個人覺得這是張不錯的卡, 然而不錯在那我並不十分清楚.
只不過, 如果有人和我一樣是個 linuxer 又恰巧買了 Dlink 650+ 那就十分不妙了...
Dlink650+ 用的是 TI 的 acx100 chipset, 而前一代 Dlink 650 並非用 acx100 chipset, 而且 Dlink650 在 Linux 上 support 還算不錯.
當有些 linux 朋友見到功能更強的 Dlink 650+, 而希望在自個的 linux 上使用時, 便開始了一連串的惡夢....
首先, 來看看外國人的討論 SeattleWireless: DlinkDwl650Plus

I just checked and D-Link (listed as D Link Systems Incorporated) is a member of the Better Business Bureau (their ID is 13033848). Since D-Link and TI and not listening to us this way, perhaps they will listen if their BBB status is at risk (this is valuble to companies for many reasons)..

Here are the facts:

* From around August 2002, D-Link support began telling Linux users that a driver would be released in December, so we should just hang on until then.

* Eventually, an offical FAQ item showed up on their web site stating this.

* In December, it was annouced that the driver had be delayed til Quarter 1 of 2003.

* At the end of December, D-Link reversed course and began telling users that there were no plans for a Linux driver because they coundn't obtain the source code from TI. After the Eusso driver became available and Eusso support stated that they obtained the source for the driver from TI under an NDA, this statement was retracted by D-Link

* At the current time, the driver's development has apparently been frozen and now we're all stuck with card we were told would be supported.


僅管 Dlink 在不久前放出了 linux binary driver for Dlink 650+, 但是有些 hacker 已耐不住性子了, 開始了 Acx100ReverseEngineering計畫, 想利用已有的 binary driver(linux/windows)作逆向工程, 並在 sourceforge 開個 acx100 oss driver project...

從 20030706 release 的成果來看, 已令我十分吃驚. Ad-Hoc without WEP 已可使用. 而且整個 source tree & code 整理的十分好. 很難想像是完全沒有任何文件或技術支援下硬幹出來的產物.

這個 porject 會發展起來也算是對製造商的一種抗議, 據我所知, Dlink 事實上也想 release linux station driver source, 只不過 TI 基於一些商業因素(可能還有其它)並不願意釋出 source. 也可能 source 裡有一些機密形成的商業考量.

最後, 我想節錄一段 acx100 oss driver project 的 README 作為結束, 我不便譯為中文, 那會失去一些原味, 請各位好好細讀一翻 :-)

Let me mention that we REALLY dislike the way very stupid hardware vendors
name their cards containing DIFFERENT chipsets!!

One of these vendors is SpeedStream/Siemens: a card that uses the same
name "SS1021" is available in both Orinoco chip and ACX100 chip versions.

Another one is D-Link: they have "DWL-650" and "DWL-650+".
"DWL-650+" is simply an improved version of the "DWL-650", right?
The standard versions use Prism2.5, whereas the "+" versions use ACX100
chipset. Good luck in finding a (correct) driver!!
And it's even WORSE: I just found out that there is some newer
version of the "DWL-650" out that also contains the ACX100
(it uses the same hardware as the "+" versions).
This BRAINDEAD STUPIDITY in device naming easily entitles D-Link
for the "Most Braindead Hardware Vendor 2003" award. And of course
they were also talking about developing another Linux driver for some time,
without any results (although I guess that's because they wanted to
develop it, but were not allowed to, unfortunately, so it's understandable).

IF you dare to release cards with a different incompatible chipset
that doesn't even have proper driver support for a popular alternative OS,
then AT LEAST change the card name in order to let people know and discern
which hardware to avoid like the plague, for heaven's sake!
This is such a , I could ...

Finally, let me mention that we really dislike the way how
Texas Instruments handles Linux driver support. It's a really shameful
pity, with delays to be measured in years versus the Windows driver
support, and with poor and buggy binary driver support.
All in all our team would be very grateful to receive proper
development support and cooperation from TI in order to create
proper Linux drivers. That would be The Good Way to do it...
(although admittedly that would still only be the second-best way to do it,
with the best way being to have paid company developers work on a
well-working OSS driver, of course)
After all it's the hardware VENDOR that's earning money via OUR, the
customers', payment, so it should be the damn responsibility of the
hardware vendor to ensure good driver support, not the other way around!
Just imagine the weird looks of thousands and thousands of Linux users
when they discovered the lack of support for the product that they just
shelled out considerable amounts of money for...

2003年7月14日 星期一

Fix Module Binary

How to fix symbols and version of module binary?

[root@localhost net]# insmod acx100sta_cs.o
acx100sta_cs.o: kernel-module version mismatch
acx100sta_cs.o was compiled for kernel version 2.4.21-0.13mdk
while this kernel is version 2.4.21-0.18mdk.

有時候我們從一些網站上下載回某個 linux driver, 有些含 source, 有些僅是
module binary 若該 module binary 編譯的環境(kernel 版本)和目前正在用的
kernel 版本不符時, 往往就會出現 kernel-module version mismatch 的錯誤.

有個方法是利用 insmod -f 來強迫載入 module.
還有個法子, 請下載 fixscript

fixscript 可直接修改 module binary 裡的符號表和版本資訊以符合目前
運行中的 kernel 版本和環境. fixscript 處理過後即可不用 insmod -f
來強迫載入. 只是這樣的 module 可能帶來一些風險, 要自行斟酌使用之.

[root@localhost root]# ./fixscript acx100sta_cs.o newacx100sta_cs.o
Fixscript V1.7
doing eth_type_trans trunc=eth_type_trans new=eth_type_trans_R729edb6c
doing __wake_up trunc=__wake_up new=__wake_up_Rb76c5f1e
doing __kfree_skb trunc=__kfree_skb new=__kfree_skb_Rc45b82d1
doing alloc_skb trunc=alloc_skb new=alloc_skb_Rdc2b24bd
doing pci_register_driver trunc=pci_register_driver new=pci_register_driver_R1e536d21
doing __generic_copy_from_user trunc=__generic_copy_from_user new=__generic_copy_from_user_R116166aa
doing __release_region trunc=__release_region new=__release_region_Rd49501d4
doing kmalloc trunc=kmalloc new=kmalloc_R93d4cfe6
doing pci_free_consistent trunc=pci_free_consistent new=pci_free_consistent_R1bfc1908
doing pci_enable_device trunc=pci_enable_device new=pci_enable_device_R1bc741d2
doing alloc_etherdev trunc=alloc_etherdev new=alloc_etherdev_R6520b46c
doing vfree trunc=vfree new=vfree_R2fd1d81c
doing pci_disable_device trunc=pci_disable_device new=pci_disable_device_R958460
doing boot_cpu_data trunc=boot_cpu_data new=boot_cpu_data_R0657d037
doing cpu_raise_softirq trunc=cpu_raise_softirq new=cpu_raise_softirq_Rd01f3ee8
doing free_irq trunc=free_irq new=free_irq_Rf20dabd8
doing unregister_netdev trunc=unregister_netdev new=unregister_netdev_Rd372bc38
doing __out_of_line_bug trunc=__out_of_line_bug new=__out_of_line_bug_R8b0fd3c5
doing iounmap trunc=iounmap new=iounmap_R5fb196d4
doing pci_alloc_consistent trunc=pci_alloc_consistent new=pci_alloc_consistent_Rca1c24c8
doing __ioremap trunc=__ioremap new=__ioremap_R9eac042a
doing del_timer trunc=del_timer new=del_timer_Rfc62f16d
doing register_netdev trunc=register_netdev new=register_netdev_Rc85ab262
doing iomem_resource trunc=iomem_resource new=iomem_resource_R9efed5af
doing kfree trunc=kfree new=kfree_R037a0cba
doing request_irq trunc=request_irq new=request_irq_R0c60f2e0
doing netif_rx trunc=netif_rx new=netif_rx_Rd1546c1c
doing __verify_write trunc=__verify_write new=__verify_write_R203afbeb
doing pci_unregister_driver trunc=pci_unregister_driver new=pci_unregister_driver_Re8061e13
doing skb_over_panic trunc=skb_over_panic new=skb_over_panic_R5ced0794
doing pci_set_master trunc=pci_set_master new=pci_set_master_R99cc7ae2
doing sleep_on_timeout trunc=sleep_on_timeout new=sleep_on_timeout_R75c8e394
doing sprintf trunc=sprintf new=sprintf_R1d26aa98
doing jiffies trunc=jiffies new=jiffies_R0da02d67
doing __vmalloc trunc=__vmalloc new=__vmalloc_R79995c5b
doing softnet_data trunc=softnet_data new=softnet_data_R338e35b2
doing __request_region trunc=__request_region new=__request_region_R1a1a4f09
doing printk trunc=printk new=printk_R1b7d4074
doing add_timer trunc=add_timer new=add_timer_Ra19eacf8
doing __generic_copy_to_user trunc=__generic_copy_to_user new=__generic_copy_to_

[root@localhost root]# insmod newacx100sta_cs.o
Warning: loading newacx100sta_cs.o will taint the kernel: no license
See http://www.tux.org/lkml/#export-tainted for information about tainted modu
newacx100sta_cs.o: init_module: No such device
Hint: insmod errors can be caused by incorrect module parameters, including inva
lid IO or IRQ parameters.
You may find more information in syslog or the output from dmesg

2003年7月1日 星期二

傾印執行檔 (dump2bin)

很久以前曾經看到一位很有名的 hacker - silvio 將 core 檔轉換成 ELF 執行檔(core2elf), 當時覺得非常有趣. 在 Un*x 的檔案權限限制裡, 如果我們將某個執行檔設為可執行卻不可讀寫, 那麼我們將無法讀取檔案內容, 也無法對該執行檔作正常的 gdb 動作.
對執行檔進行讀取和除錯其實是逆向工程或是系統安全裡的基本操作, 有些系統管理者或程式設計者太過信賴 Un*x 權限管理, 將過多的資訊保存在執行檔裡, 卻可能導至一些問題的發生.
這個程式 dump2bin.c 是我利用 Linux 提供的 ptrace 系統呼叫, 將執行檔內容傾印至指定的檔案.
例如: ./flags 原本是不可讀寫的執行檔, 但經過 dump2bin 轉換成 ./flags2 即可讀寫.
flags 的 file owner 可以為任何人, 只要可以執行的檔案都可轉換.

[tim@localhost hack]$ ls -al ./flags
---x--x--x 1 tim tim 11400 6月 23 17:21 ./flags*
[tim@localhost hack]$ ./dump2bin ./flags ./flags2
Ready to dump ./flags to ./flags2 ...
Child pid = 12183
Converted successfully!
[tim@localhost hack]$ ls -al ./flags2
-rwx------ 1 tim tim 11400 7月 1 01:01 ./flags2*
[tim@localhost hack]$ file ./flags2
./flags2: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), stripped