近期朋友入手一台TP-Link WR940N V5，是一款使用TP9343 SOC (Qualcomm的QCA9561閹割版，少了USB以及PCIe的支援)擁有4MB flash及32MB ROM，由於友人沒有任何特殊需求，也不需要任何fancy的功能，所以直接幫他在stock firmware中設定一下，就上線服役了，幾天後，友人反應說偶爾會有斷線的狀況，而且從Windows中重連時會短暫的搜尋不到SSID，得等一陣子才能夠再次搜尋的到，雖然發生頻率不高，但每每發生就得斷線一下，使用上的感受實在不太好。
我本身對AP也不是非常懂，於是請教了在某AP ODM大廠就職的阿水大神，根據他Google一番，問題似乎發生在TP-Link依舊採用Atheros rate control algorithm，但這algorithm在訊號擁擠的環境下，表現很差，所以各大第三方firmware (Openwrt、dd-wrt)都改用minstrel_ht rate algorithm，而TP-Link or 他的BSP廠也沒有上對應的patch。詳情可以參考:
The ath9k rate control algorithm has various architectural issues that make it a poor fit in scenarios like congested environments etc.
我在晚上尖峰時段在這機器附近掃瞄了一下，周遭最少有21~25台AP，不可不謂擁擠啊，本想說在TP-Link官網上找找有沒有新的Firmware，結果發現超妙的一件事情，我在官網根本找不到V5的版本，本以為是不是買到水貨，還好在NCC網站上有查到資訊，最起碼是官方貨。
唯一解法就是刷第三方韌體，剛好前陣子才看到LEDE (Linux Embedded Development Environment)專案，是一個based on Openwrt的專案，目的在改善Openwrt開發緩慢、開發過程透明度不足以及跟使用者互動極差的缺點，可惜在官方網站只列出支援WR940N V4，所以只好再次請教阿水大神，在他比較TP-Link的GPL code後，確認v5跟v4應該是同樣的硬體，所以可以直接刷v4的firmware。
刷的過程本以為很快很順利，本以為就把firmware透過TP-Link的後台上傳LEDE firmware即可，結果發現TP-Link竟然開始會檢查是不是官方firwmare，在阿水大神檢查了bootloader code後，發現雖然TFTP也會檢查product id以及hardware version，不過好笑的地方在於TP-Link官方給WR940N V4的product id/hardware version是09410006 (WR941ND V6)而WR940N V5的product id/hardware version則是0940004 (WR940N V4)，所以當LEDE乖乖按照TP-Link慣用格式把用在WR940N V4的firmware填上0940004反而因為這樣而可以刷入WR940N V5，所以只需要把LEDE給WR940N V4的firmware下載回來(-factory.bin結尾那個)更名為wr940nv5_tp_recovery.bin，然後使用TFTP刷進去即可（刷法Google一下即可），真是一個美好的錯誤啊！
刷好後，觀察了一兩天，Wi-fi不穩的問題煙消雲散，但卻發現一個詭異的問題，Wi-fi的download速度一直上不去(upload可以打到80多Mpbs)，在LEDE上跑了iperf3當server，然後用T440打流量，download最多只能打到35~40Mbps，雖然已經高於友人家中的網路頻寬，同時也發現訊號有稍微減弱，身為資工人，實在很想解決這問題，所以嘗試了許多招式，特此紀錄。
0x01 嘗試上Qualcomm Fast Path的Patch
WR940N V5採用的SoC是TP9343，所以也是有支援Qualcomm的Fast Path技術，雖然在嘗試前我們就知道Fast Path應該只會對於NAT<->WAN的效能有顯著提升，而我們先前測試都在NAT內，不過死馬當活馬醫，想說在enable這功能的同時，會不會順便改進一下Wireless的效能。
想不到初次嘗試就碰的一鼻子灰，我們嘗試包LEDE論壇上gwlim提供的patch，結果發現他的patch似乎包了整個完整的SDK，導致包出來的image超過機器僅有的4MB Flash，幾經嘗試拔除一堆套件 e.g. LuCi、opkg、OpenVPN等等等，還是遠超過4MB，就在準備放棄時，阿水大神突然發現了有人做了一個精簡版的patch，嘗試打上那個patch後，總算成功包好firmware，結果刷上測試，立刻澆了一桶冷水，wireless效能完全沒有顯著改善，GG斯米達。
** 學到技能：包LEDE firmware + 上LEDE Patch
0x02 嘗試增加TX Power (方法1)
ssh進去LEDE後，發現wlan0的tx power只有20dbm，透過 iw reg get發現雖然Global設定在TW，但是phy#0卻是選擇US，所以我們懷疑firmware有限制wireless的TX Power，所以就嘗試修改這個限制，根據阿水大神開示，在TP-Link上這個限制應該是存在ART partition裡面，同時也超有耐心的教導該如何更改，步驟如下：
- ssh進去LEDE
- 使用
cat /proc/mtd，檢查mtd layout (會看見有個partition叫做art)
|
|
- 備份現有的ART partition:
cd /tmp && cat /dev/mtd4 > art_orig.img(注意，參考上一步驟看看art是mtdX) - 把
art_orig.img從LEDE上scp出來到Linux server上 - 在Server上編譯ART partition Tool
|
|
- 利用剛剛編譯出來的tool修改ART image:
./ar9300_eeprom -y0 art_orig.img -u art_mod.img - 把修改好後的
art_mod.img從server scp回去LEDE的/tmp裡面 - ssh進去LEDE，把修改好的image寫回ART partition:
cd /tmp && mtd write art_mod.img art
然後，你就會發現LEDE告訴你錯誤，原來ART partition從安全性的考量上預設是read-only，所以唯一的辦法就是自己編譯一次LEDE firmware，在make menuconfig中，選擇Kernel modules -> Other modules->kmod-mtd-rw，重新刷一次編好的firmware後，ssh進去後下: insmod mtd-rw.ko i_want_a_brick=1，在把修改好的ART image刷進去即可，最後修改/etc/config/wireless中的txpower改為30，reboot後即可。
然而，現實是殘酷的，即使重開好後看到iw reg get中的資訊，限制已經被提高到30dbm，但是iwinfo卻顯示wlan0只打到22dbm，再次GG斯米達。
0x03 嘗試增加TX Power (方法2)
我已經進入自己懷疑自己的階段，開始懷疑是不是剛剛那隻tool沒有把東西改好，此時找到另外一個改法是直接修改ath9k driver的binary檔，這隻tool叫做reghack，使用方法如下：
- ssh進去LEDE
cd /tmp && wget http://luci.subsignal.org/~jow/reghack/reghack.mips.elf && chmod +x reghack.mips.elf./reghack.mips.elf /lib/modules/*/ath.ko./reghack.mips.elf /lib/modules/*/cfg80211.ko- reboot
然後，發現現實毫不留情面地在給我一個大大的巴掌，毫無幫助，經過阿水大神大神查詢FCC的資料，發現940N V5申報最高就只能打到23dbm (22dbm + 1dbm antenna gain = 23dbm)，所以我們已經打到硬體的極限，同時他也發現另外一個有趣的事，940N V4竟然可以打到26 dbm，比較了PCB Layout發現V5應該是cost down少了三顆power amplifier，所以txpower也就打不上去了，含淚GG思米達！
** 學到技能：買AP前要看FCC申報資料，同樣型號同樣的CHIP，能打出來的txpower還是有不小差異
0x04 意外發現QCA9561的LNA/PA patch
在我已經打算放棄時，隨意亂Google時突然發現在LEDE官方論壇一個關於QCA9561 LNA/PA的patch，LEDE中的ath9k driver錯把AR9561的PA Bias level設定成AR9565的，AR9565是0x1e00而AR9561則是0x300，這個patch便是修正這錯誤讓firmware可以讀取正確的calibration資訊，所以我決定做最後一次嘗試，再一次的編譯了LEDE，步驟如下:
- git clone https://git.lede-project.org/source.git lede && cd lede
- ./scripts/feeds update -a && ./scripts/feeds install -a
- make defconfig && make menuconfig
- cd package/kernel/mac80211/patches
- wget https://raw.githubusercontent.com/oe1rfc/lede-qca9561-pa-bias/88dcdee6b0b86d489afb9bc54010c04063695e5e/package/kernel/mac80211/patches/514-ath9k_QCA9561_pa_bias.patch
- cd ../../../ && make -j 4 V=s CONFIG_DEBUG_SECTION_MISMATCH=y 2>&1 | tee /tmp/build.log | egrep -i ‘(warn|error)’
在毫無期待的心情下再測試了一下，結果讓人大幅振奮，速度竟然攀升到75Mbps，竟然在打算放棄前最後一刻，成功地解決了這個問題！
結論
整個過程如果沒有對AP極為熟悉的阿水大神協助，根本沒有機會解決這問題，再次感謝！也從中學到了寶貴的經驗：
Bonus
附上阿水大神調教過的超級瘦身版config.seed (for TL-WR940N V4/5 only)：
|
|