【無線LAN】OpenWrt【強化ﾌｧｰﾑ】13 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>420
使ったイメージはこちらでした。スミマセン。
ttps://downloads.lede-project.org/releases/17.01.1/targets/brcm47xx/legacy/lede-17.01.1-brcm47xx-legacy-linksys-wrt54gs-squashfs.bin 同様のメソッドで BHR-4RV でも成功しました。
使ったイメージはこちら
ttps://downloads.lede-project.org/releases/17.01.1/targets/brcm47xx/legacy/lede-17.01.1-brcm47xx-legacy-standard-squashfs.trx
1)Windows PCのアドレスを 192.168.12.2 にする
2)底面ラベルに記載されているLAN側MACを arp -s 192.168.12.1 00-1d-73-xx-xx-xx で スタティックに登録
arp -a で 192.168.12.1 側IFに 192.168.12.1が上手く登録されない場合は netsh を使って登録
netsh interface ipv4 set neighbors "ローカル エリア接続 X" 192.168.12.1 00-1d-73-xx-xx-xx store=active
3)ping 192.168.12.1 しつつ ルータ電源ON
4)192.168.12.1 から TTL=100 で応答あったら
別窓で tftp -i 192.168.12.1 put lede-17.01.1-brcm47xx-legacy-standard-squashfs.trx を実行
5)「転送を正常に完了しました：」のメッセージが出たら成功。
成功するまで繰り返し
DRAM 64MBの機種なので 初期状態で 74% free (約45MB) >>420-422
arp -d 192.168.11.1 (念のため)
ping -t -w 10 192.168.11.1
別窓で tftp -i 192.168.11.1 put xxxxxx<ファームウェア> のまま待機 (エンターキーは押さないでおく)
ルーターの電源on
pingやってる窓で反応があればtftpの窓でエンターキー押す
arp -a は必ず必要というわけではない
(192.168.11.1は機種にあわせて変更) broadcom CFE bootloader ですが世代の異なるWZR-900DHP では
TFTP push 型のインストールは上手くいきませんでした
>>382 のCFE Web Server メソッドでは
純正firmwareのdebug画面にbufpy で入って telnet でログインしますが、
これは起動時のboot wait を調整してCFE Webサーバに接続できる時間を作るためですが、
brick 状態や新firm機ではそれができません。
正面のAOSSボタンを押しながら電源を入れると、
CFEファームウェア側から192.168.1.2のTFTPサーバにlinux.trx-recovery を取得しにいくのですが
lede のファームをrename して転送しても上手く行きません。(おそらくヘッダの問題？)
(>>402-404 の加工した純正ファームでは成功することもあればしないこともあり、安定しませんでした)
しかし、AOSSボタンを押しながら起動すると、
nvram設定がデフォルト値で boot_wait=off でも何秒かCFE Webサーバが起動することがわかりました。
これを使って >>382 のアレンジ手法を編み出しました。 ◎準備
以下のLinkから Windows版curl を入手する。
http://opensourcepack.blogspot.jp/p/wget-and-curl.html
(検証時はwget-1.19.1_curl-7.52.1_win32_win64.7zを使用)
LEDE firmware を C:\temp\ 以下に置く
https://downloads.lede-project.org/releases/17.01.1/targets/bcm53xx/generic/lede-17.01.1-bcm53xx-buffalo-wzr-900dhp-squashfs.trx
PCのIPアドレスを 192.168.1.2/24 に設定する。
◎実施
1)あらかじめ ping -t 192.168.1.1
2)別窓で以下コマンドラインを準備(まだEnterしない)
curl -F "name=@c:\temp\lede-17.01.1-bcm53xx-buffalo-wzr-900dhp-squashfs.trx" http://192.168.1.1/f2.htm
3)AOSSボタンを押しながら電源を入れる。
正面のLED全点灯後 緑のPower LEDだけが点灯するまで押し続ける。
4)192.168.1.1 から TTL=100でping応答があったらすかさず別窓のcurl を enter
成功すれば Upload completedの文字列が含まれる HTML が返ってきます。
curl: (56) Recv failure: や curl: (7) Failed to connect to 192.168.1.1 port 80: は失敗です。
>>402-404 の加工した純正Firmware はインストール出来ませんでした。
default のNVRAM状態では wait時間が短すぎて、ファイル転送が終わらないのかもしれません。
ま、しかし 一度 LEDEをインストールした後、
CLIのnvram コマンドで boot_wait/wait_timeを設定すれば
上記の方法でインストールまで出来ます。
nvram default化 はcurl なら以下でできます。
curl http://192.168.1.1/do.htm?cmd=nvram+erase
とりあえずこれで CFEさえ活きていれば復旧する方法が見つかりました。
WZR-900DHPでもLEDEをガンガン遊べそうです。 >>423
そうですね。arp -s は必ずしも必要でないのかもしれませんが、
何度か検証した限りは設定しておいた方が成功率は高かったです。 プロジェクトの風通しが悪い うんたらかんたらだけで
じゃぁ分離したほうで何をするんだっていったら、同じことをやってるだけ
eglibcがglibcから分離したのは
毒舌野郎がx86だけサポートしてりゃいいんだよ、クソども、ってなことをのたもうて
マルチアーキテクチャ対応のほうがベターに決まってんだろ、ということで
そこをちゃんとやるために分離して、実際にやってて、随時本家の方にも反映されてましたからね
glibcのプロジェクトから件の毒舌野郎が離れて火種がなくなったので
再合流して一本化され、めでたしめでたし /etc/rc.localに
perl /usr/bin/wifi.pl
exit 0
と書きましたが、実行されません。
単独であれば、動いています。
確認点ありますか？ >>428 perl のフルパスが書かれてないからじゃないでしょうか？ WZR-900DHP ですが、DHP2 ではなく元の DHP ファームに戻すことが出来ました。
元ファームの /dev/mtdblock/2 (mtd2: linux)と /dev/mtdblock/3 (mtd3: rootfs) のバックアップデータを一つに結合したファイルを
>>425 のメソッドで送り込むことが出来ました。
bufpy / otdpopypassword で telnet を on にして以下で取得・生成。
# dd if=/dev/mtdblock/2 of=mtdblock2.dd bs=1
# dd if=/dev/mtdblock/3 of=mtdblock3.dd bs=1
# cat mtdblock2.dd mtdblock3.dd > wzr900dhp_cfe.trx
(最後のはWindows環境で copy /b mtdblock2.dd+mtdblock3.dd wzr900dhp_cfe.trx でもいい)
ただ、ファイルサイズが60MB近くになるのでnvram set boot_wait=30 程度は必要です。 純正ファームを加工してCFE用ファームを生成出来ない機種、
WZR-600DHP2、WZR-1166DHP2、WZR-1750DHP2 などでも
事前に mtd2、mtd3 のバックアップデータを取得しておけば
同様の手法で元のファームウェアに戻せるかもしれません
勇者求むw >>429
んー、フルパスにしてみたけど、動いてないみたい。
どこかにログは残るのかしら。 >>418
C7は日本で売ってるやつはOpenWrtだとCC stableは入らない
LEDEならReboot stableがメーカーデフォのGUIからそのまま入る >>433
>>418ですが、OpenWrtのリリース版は確かに起動できなかった
SPI FLASHが変更されたためJEDEC IDから容量などの情報がわからずに
なのでGIT trunkからインストールした wzr-900dhpでいろいろ弄くれることは分かったんだけど、Ledeにしてもdd-wrtにしても、導入後にWifiが使いものにならなくなるのが残念。
せめて2.4GHzだけでも普通に動けば、いちいち有線で繋ぐ必要がなくなるんだが…
例えば、標準ファームから、Ledeの17.01を入れると、最初は2.4GHzがbgだけではあるものの、正常出力で稼働する。でも一度でも電源をoffにすると（rebootはOK）、2.4GHzの出力が極端に弱くなり、1メートルも届かなくなってしまう。 >>436
その事象、BCM4331無線LANチップ用のfirmware？を
起動時にロードできてないように見受けられますね
（初回インストール時はオリジナルファームがロードしてるから動く）
WZR-900DHPに限らず Broadcom BMC Arm系SoC 系で
無線LANチップのBCM4331 の搭載機種で同様なのかな
WZR-xxxDHP系は無線LANを諦めて
有線専用の『BHR-4GRV３』として使うのが吉かと思いますね >>437
現行のBHR-4GRV2 がDRAM64MB,Flash16MB,USB無しのQualcom Atheros 720MHz
WZR-600DHP2/900DHPは
DRAM256MB,Flash 128MB, USB3.0付きで
ARM cortex-A9 800MHz
消費電力を除けば確かに優秀かも 使いもしない無線に微量とはいえ通電し続ける状態を悔しく感じるか感じないか b43カーネルモードドライバをopkgで削除して
後段のアンプ出力0にすれば
無視できるほどの消費電力にならないかな？ >>435
環境変数の何を見たらいいか分からない。
自己解決ですが。
command >/etc/aaa.txt 2>&1
みたいにログを残す方法を思い出して、付け足した。
ちゃんとファイルはできていて、内容を見るとスクリプトは実行されている。
しかし、設定が反映されていない。
rc.localの実行タイミングとか、引き続き調べてみる。 そこまでわかっているなら、
rc.local 実行中の変数をリダイレクトしたものと
shellログイン中のものを比較してみれば良いかと >>438
純正ファームじゃないとスイッチのアクセラレータ無効になるせいでスループットかなり落ち込むけどな >>443
どのくらい低下するのか検証してみました。
◎検証構成
役割 iperf3_Client Router PPPoE_Server/iperf3_server
HW：[i7-3770k|intel_1000PT]===[lan| |wan]===[intel_igb|i5-2505s|e1000]
SW：[Win10pro(x64) ]===[ ]===[debian8(amd64)onESXi6.0u3]
SW：[ _]===[PPPoE MTU1454]===[pppoe 3.8-3(amd64)]
SW：[iperf3(win64)v3.1.3 ]===[ ]===[iperf3(linux)v3.1.3]
NW：[192.168.11.2/24 ]===[-11.1|10.1.1.1]===[10.1.1.254 | 192.168.0.127/24]
◎測定コマンド
client側：iperf3 -c 192.168.0.127 -P 36 -d -t 65 -O 5
(tcp 36並列、双方向トラフィック、65秒間計測(最初5秒無視) )
server側：iperf3 -s
◎備考
clientとServer をPPPoEなしで直結した場合
送信：942Mbps、受信：943Mbps ◎結果（5回の平均）
・WZR-900DHP 純正ファームウェア Ver.1.14
送信：202Mbps 受信：202.4Mbps
・WZR-900DHP LEDE 17.01.1 r3316
送信：163.8Mbps 受信：164.2Mbps
◎備考
PPPoE接続、３６ストリームの双方向同時通信時のパフォーマンス
１ストリーム、送信だけだと約20%程度向上
１ストリーム、受信だけだと約30%程度向上 LEDEでの測定時のCPU load は peek で 0.65 位でした。
WZR-900DHPの純正ファームに対してLEDE17.01.1は8割程度の
有線スループット性能ですね。
半分くらいに落ち込むかと思っていましたが、案外落ちませんでした。 >445の結果に * 0.45やったら
BBR-4HGとBBR-4MGの値とほぼ同じ
4HG - アクセラレータ有効
4MG - アクセラレータ無効
ってことか >>446
純正ファームならPPPoE+NATで600Mbpsくらい出るはずなんだけどなんか変だな
他ファームに書き換えてアクセラレータ無効になると200Mbpsぐらいまで落ちるのは合ってるはず ぬーん。debianのpppoeの性能限界ですかねぇ WZR-900DHP発売当時のプレスリリースでは
PPPoE時922Mbps と謳っていたようですね
FastEtherのBHR-4RVやBBR-4HG当時は以下の測定環境だったようですが、
GbE時代はどういう環境なんですかねぇ
http://buffalo.jp/products/catalog/network/router_throughput/ アクセラレータというのは、ハードウェアNATのこと？ どうせ外回線で糞詰まるんだから気にするレベルじゃねぇわい pppoe-serverをkernel mode option -k を付け忘れてuser spaceで実行してました
このせいかな？
また夜勤なので、明日帰ったらファームを戻して再試験してみます >>442
確かに違うね。
でも、どんな影響があるか分からない
#rc.local
SHLVL=3
HOME=/
TERM=linux
PATH=/usr/sbin:/usr/bin:/sbin:/bin
PWD=/
#通常実行
SSH_CLIENT=192.168.**.*** 58749 22
USER=root
SHLVL=1
OLDPWD=/root
HOME=/root
SSH_TTY=/dev/pts/0
PS1=\u@\h:\w\$
LOGNAME=root
TERM=xterm
PATH=/usr/bin:/usr/sbin:/bin:/sbin
SHELL=/bin/ash
PWD=/etc
SSH_CONNECTION=192.168.**.*** 58749 192.168.**.1 22 切り分けのために同じ変数をスクリプトの中で定義すれば良いかと
HOME,SHELL,PATHあたりが関係しそう
あとはloggerでsyslogに吐かせて
スクリプト実行タイミングを測るとか
ちなみにperlで何やらせようとしてるのかな
大抵の操作はuciコマンドでできそうな気がするけれど >443-445
切り分けのため iperf3 client と PPPoE/iperf3 server を直結して
WindowsのPPPoE で接続して iperf3 走らせたら送信 202Mbps 、受信203Mpbsでした。
pppoe Server 側の性能限界でした。スミマセン。
debian8 の kernel PPPoE Server は上手く動きませんでした
また ESXi6上のLinuxなのでそこにもボトルネックありそうです。
SR-IOVでNICをパススルーするか、物理で立てるかしたほうが良さそうです あ、でも、PPPoEなしでやった場合は940Mbps程度は出たから、
ESXi側にはボトルネックはないかもですね
PPPoE Server 環境を見直します。。。 >>455
文字列処理とか正規表現とかするのに、Perlしか知らないもので。
で、何やってるかというと、
Wi-Fiの電波を取得して、自身の把握しているSSIDの中で1番電波の強いWi-Fiを掴む処理をしてる。
(Wi-Fi子機の機能で、イーサネットコンバーターにしてる。持ち運んで使う有線LAN機器で使用)
rc.localでの実行では、電波の強いWi-Fiまでは把握できてるけど、その後のperl内でuciを呼んで、Wi-Fi設定してる部分が行われてないのか、反映がされていない。
uciの部分だけperlから外して、rc.localに直に書いてみようかな。
環境変数の定義も試してみます。 MZK-EX300NPを入手したんですが、これバラさずにLEDE導入に成功した人っています？ >>461
スクロールしたら眼潰しされててはうぁってなったわ そもそもこのMZK-EX300NPってsrchackさんがOpenWrt対応した機種で、
バラしてシリアル引き出せば遊べそうなんですが、
バラすのダルいなーと思ったもので。
有線ない機種なのでシリアル無いと何にせよ厳しいか… カワイソウという感覚に襲われる通信機器・・・取り外してあげたくなる
http://www.planex.co.jp/products/mzk-ex300np/image/img_concent.png
しかもコンセントに挿してるのにLEDが消灯してるのもツッコミどころ
>>463
自分は使ってるし便利だけど、コンセントの配線経路を診断しにくいので市場的に廃れたね >>464
有線が無い機種でopenwrt入れたらデフォルトで無線有効化されないんで即文鎮化する
そんな機種はシリアルがないとopenwrtは無理 >>466
私が持っている有線が無いやつは、セキュリティの無い無線が出てくれるよ。 鯖缶が集まる居酒屋、セキュリ亭
酔ったお客さんがアカウント情報をメモしていく「アカウント帳」が人気 たくや L99 ほのらあてくなやえぽに...
( ﾟдﾟ) ... ふっかつのじゅもんか これ >>466
自ビルドすればインストール後即有効にできる。 少なくともbuffaloのはほぼ全ての機種で、
開腹せずに電源オンだけや最小限のボタンストロークで
外部からファームをインストールする機構が用意されてますよね
製造後に発覚した不具合や脆弱性の修正や
未出荷製品のファーム入れ替えて後継機に仕立てるために使っていると予想するけど、
それって他社でも必要だと思うんですよね
あまり知られてませんね 無線だけの機種にもあるんだろうけど、
インフラ側をどうするのか想像つかないや 上のMZK-EX300NPだと、正規状態ではWPSプッシュボタン認証で使うのが前提だよね
これにopenwrtいれて、初期設定はパスなしSSIDで掴めたとして、
無線デバイスをClientに切り替えた時点で、APを見失ったり間違った設定でAPPLYすると
二度とアクセスできなくなるね
Client+保守用APの2つで仕立てても、Client側の電波を掴めないとAPの電波も道連れで
出なくなるので、使用する上位APと完全にセットで管理しないと逃げ場の無い状態になる。
それでも使いたいなら、シリアル引き出して保守用端子を常設する改造が最適じゃないかと。
でないと、いざというとき自分が困る。 MZK-EX300NPの件ですが
そもそもバイナリとしてsysupgradeイメージしか無いので
1段目のイメージを自作しないといけない気がします。
シリアル引き出すとか引き出さないとか以前の問題でした… orz
勝算ないですが取りあえずシリアル引き出してみます hackは日本語で八苦と書く
これをやりたい達成したい、と具体的な目標があってこそ
調べて試して苦しみもがくことにも耐えられる >445-446
ほぼ同じ条件で、PPPoE/iPerf3 Server の仮想マシンを CentOS 6.9 x86_64 に代えてやってみました。
PPPoE + NAT 、 MTU/MRU 1454、iperf3 3.1.3 で測定。
◎WZR-900DHP
純正 ver1.14 … 送信：935Mbps / 受信：936Mbps
LEDE 17.0.1.1…送信：239Mbps / 受信：240Mbps
◎Windows10 Pro 1607
直結…送信：945Mbps / 受信：946Mbps
PPPoE…送信：929Mbps / 受信：929Mbps
因みに pppoe-server を ユーザーモードで実行すると
純正 ver1.14 … 送信：364Mbps / 受信：394Mbps
Win10PPPoE…送信：403Mbps / 受信：403Mbps
純正ファームはほぼカタログスペック出てるようです。
LEDE 17.01.1 の PPPoE+NATのスループットは約1/4でした Client側：
Windows10 Pro x64 / OS標準PPPoE
i7-3770 / Mem 16GB
iperf3 3.1.3
Server側：
CentOS 6.9 x86_64 / Kernel 2.6.32-696
ESXi6.0u3 上の VMware仮想マシンVersion11
vnic VMXNET 3 (ESXi準仮想化アダプタ)
CPU core 2 / Mem 8GB (i5-2405s )
iperf3 3.1.3(ソースビルド)
rp-pppoe-3.10-16.el6.x86_64 (Kernel Driver Bug fix版)
PPPoE サーバは以下で起動してます
/usr/sbin/pppoe-server -I eth1 -L 10.1.1.254 -O /etc/ppp/pppoe-server-options -k
--- pppoe-server-options ----
require-chap
lcp-echo-interval 30
lcp-echo-failure 4
mtu 1454
mru 1454
proxyarp iperf3 の実行コマンドは同様
Server側：
iperf3 -s
Client側：
iperf3 -c 192.168.0.127 -P 36 -d -t 65 -O 5
(tcp 36並列、双方向トラフィック、65秒間計測(最初5秒無視) )
Windows10の PPPoE では最初の数秒間はスループットが上がらないので、
5秒無視設定が有利に働いてました。 少なくとも、WZR-900DHP に関しては、純正の方が良いってことですね。
今、結果をまとめているところですが、
LEDEにしたときのの有線スループットは WZR-HP-AG300H の方が高いことがわかりました。
AG300Hは純正よりもLEDEの方が早いです。さすが鉄板と言われるだけはあります。 >>483
素晴らしい。
是非ともまとめてちょうだい。
でも、うちにはw??-hp-300nhだったかな。大量にある（汗） >>484
>480-481 の環境での検証結果をまとめました。
◎WZR-900DHP
純正 ver1.14 … 送信：935Mbps / 受信：936Mbps
LEDE 17.0.1.1…送信：239Mbps / 受信：240Mbps
◎Windows10 Pro 1607
直結…送信：945Mbps / 受信：946Mbps
PPPoE…送信：929Mbps / 受信：929Mbps
◎BHR-4RV
純正v2.45…送信：71.5Mbps / 受信：71.5Mbps
LEDE17.01.1…送信：23Mbps /受信：23Mbps ※ iperf3 -P1 での測定
◎WZR-HP-G301NH
純正v1.81…送信：122Mbps / 受信：122Mbps
LEDE17.01.1…送信：194Mbps /受信：194Mbps
◎WZR-HP-AG300H
純正v1.75…送信：199Mbps/ 受信：199Mbps ※ P20 での測定
WZR-600DHP v1.99…送信：166Mbps/受信：166Mbps ※P36 20秒間での測定
LEDE17.01.1…送信269Mbps/受信269Mbps 以下寸評
◎BHR-4RV
CPU性能を考えると純正ファームはかなりの高スループット
LEDEでは複数TCPセッションで６０秒間のiperf3 に耐えられずエラー終了
tcp 1セッションまで減らしてようやく終了。
◎WZR-HP-G301NH
LEDE の方が高スループットだが
30秒を超える辺りでiperf3 がエラー終了することも多々あり
◎WZR-HP-AG300H
純正v1.75や600DHP v1.99のファームでは TCP36セッション*60秒間のiperf3 に耐えられない
LEDEでは36セッションのiperf3を常に完走できるようになって安定性・スループット共に向上している。 ちなみに以上は 有線接続時のPPPoE+NATルーティングスループットでの評価となります
計算性能という意味ではOpenWrt サイトに OpenSSLのベンチマークがありまして、
https://wiki.openwrt.org/doc/howto/benchmark.openssl
WZR-900DHPと同じ BCM4708A0 を使っているASUS RT-AC68U は
AR7161のWZR-HP-AG300H に対してだいたい２倍程度の速度を叩き出してます >485 追加
◎BHR-4GRV
純正v1.77…送信：253Mbps / 受信：253Mbps
純正v1.99…送信：263Mbps / 受信：263Mbps
OpenWrt 14.07※…送信：73.9Mbps / 受信：73.9Mbps
LEDE 17.01.1※…送信：191Mbps / 受信：191Mbps
※ WZR-HP-G450H 用firmware
→ BHR-4GRVは純正のほうがスループットが高い。iperf3 も安定。
OpenWrt 14.07 から LEDE 17.01.1 で2.5倍のスループットに。
おそらく、QSDK Project での Athros ドライバの成果がフィードバックされたためではないかと思います。 >>488
乙でした
300系がLEDEで覚醒してるのは意外
4GRVでwrt使ってるけどギガビットイーサの仕様が全く生きてなかったのね…
時間があるときにLEDEの環境作ってみよう >486 さらに追加
◎BHR-4GRV2
純正v1.03…送信：920Mbps / 受信：920Mbps
純正v1.08…送信：932Mbps / 受信：933Mbps
OpenWrt 14.07※…送信：146Mbps / 受信：146Mbps ※AP135-20用ファーム
LEDE 17.01.1…送信：355Mbps / 受信：355Mbps
→純正firmがカタログスペック(839Mbps)よりスループット出ていて、PCでのPPPoE並です。
BHR-4GRV同様OpenWrt14.07からLEDEになってだいたい２.5倍に。
CPUクロックの向上(400MHz→720MHz)に比例したスループットになっています。
純正firmはクロック比以上の値になっているので、
何らかのアクセラレータ機能が有効になっているのかもしれません。
今までUSBなくなった廉価版のダメな子と思ってたよBHR-4GRV2。打ち捨てておいて悪かったw 何となくまとめ
Linux側でPPPoEサーバがユーザモードとkernelモードとで２倍以上の差がでることから
スループットはドライバの作りに大きく依存することがわかる。
Qualcom買収以前のAtheros SoC の機種は純正よりもLEDEの方がスループットが高い。
純正ファームウェアが古いkernelを使っている一方で、
QSDKで開発されたswitchドライバのフィードバックのおかげかもしれない。
https://wiki.codeaurora.org/xwiki/bin/QSDK/
新旧ともBroadcom SoC 機は純正の方がアクセラレータ機能が効いてLEDEの数倍のスループットが出る。
このあたりはエンタープライズ系NWプロセッサを手がけるBroadcomの本領発揮というところだが、
NDAで縛るなどOSSコミュニティに冷淡なので、今後LEDEで活用されることは期待できそうにない。
当面、LEDEでは Qualcom Atheros SoC の製品の方が推奨と思われる。
>418 の言うように 11ac 時代では TP-Link Archer C7 が鉄板というのも頷ける。
今後Ramips/MediaTek SoC系の評価もできたらしてみたい。
(WHR-1166DHPとWHR-300HP2はあるのですが、いずれもLAN側100BASE-TXなので・・・) >WHR-300HP2
WAN側も100Mなわけだが 長く販売されてきたロングセラーでも
日本に法人立てて国内販売が始まったのは去年のこと
猫も杓子も、のBuffaloの機種はハドオフ行けば連れ帰ってほしそうに見つめてくるが
わざわざTP-LINKを選ぶようなヘンタイは少ないから、新品で手に入るうちに買っとかないと
手に入らなくなるよ 無線機器の商売でメインが11acになった影響で、たしかに11nの弾数が一気に増えた印象。
先日訪問したら、G301NHが2つ、真ん中のはG450Hでアンテナ欠品、全部324円だった。
http://i.imgur.com/cAQcPZe.jpg
新しいファームを焼く実験機や、同じ設定を施した予備を増やす目的で本当に助かる。
ただ、上記の11nモデルは手元に増えすぎたので、底値だけど3台ともスルーした。
このあと、純正AC付きAG300Hを324円で発掘、こいつは別格だから結局買ってしまった。
http://i.imgur.com/o8XKxTj.jpg LEDEのSSH CLIから純正firmwareへの戻し方。(WZR-HP-AG300H、BHR-4GRV2対応)
純正firmware状態であらかじめbufpyでtelnetして /dev/mtdblock/6 を dd でバックアップ取っておく。
LEDEのSSH consoleでログイン
scp で /tmp に mtdblock6.dd をコピー
mtd write /tmp/mtdblock6.dd "firmware" で 書き戻し
/tmp はramdiskなのでメモリ128MBのAG300Hや、flashイメージが16MBと小さい4GRV2は
/tmpに置いても大丈夫。
G301NHや4GRVなどは/tmpがあふれてしまう。
USBメモリを有効にしたり、分割して書き込みなどの手段が必要 >494
\324でAG300Hとは安いねぇ
かつてのWHR-G54S 状態になってる気がしますね >>494
ドフスレかと思った
>G301NH
１つ324円ならすべて購入するわ
十和田市のドフじゃ(ギガ対応の11nは)１つ 1620円だからな 十和田ってどこかと思ったら青森、八甲田山じゃないのさ!! >>486
ag300hに入ってるar7161は、クロックアップできるってopenwrtフォーラムで
見たことがあります。確かソースのどこかの値をいじってビルドするらしい。
800MHzぐらいまでアップできたと思うので、そうなるとまた結果が変わってくる
かも。
>>491
ledeのtrunkでmt7621にジャンボフレームがサポート（2Kまで）されましたので
https://git.lede-project.org/?p=source.git;a=commit;h=eee09bfe01e8cc2db1501f82dde7b9b6bb424faf
wsr-1166dhp(2)あたりはちょっと期待できるかもです。 androidのカスタムファームでよくあるようにClockupがソフト的にできると良いですよね
個体差なども出てくると思います。 OCといえば、dd-wrtで、WBRやWHR-G54Sでoverclockという項目があって、
なにげなく1段階だけ速くしたらリセットが掛かり、起動直後からOCが適用されているのか、
30/30/30もできず、二度と戻せなくなったトラウマがある。 Router Model: Buffalo WHR-G54S
Firmware Version: DD-WRT v24-sp2 (02/17/11) std - build 16214
CPU Model: Broadcom BCM5352 chip rev 0
CPU Clock: 200 MHz
cron
00 05 * * * root wget -O /tmp/smbshare http://www.crunchyroll.com/rss >>502
おーありがとう。
うちの無線ルータwndr3700v1。パッチ作ってビルドしてみたお。
root@lede:~# dmesg|grep MHz
[ 0.000000] Clocks: CPU:800.000MHz, DDR:400.000MHz, AHB:200.000MHz, Ref:40.000MHz
[ 0.000007] sched_clock: 32 bits at 400MHz, resolution 2ns, wraps every 5368709118n s
root@lede:~#
800MHzになってるわ。これをガンガン試す用途がみつからない… >506
乙
作ったLEDE用パッチを是非公開してほしいです >>507
内容は上のリンクのやつのままだけど、カーネルのバージョンも当時とは
違ってるし、ソースが変わってるかもと思って一応今のソースで作ったpatchです。
なので途中でHunk!とかは出ないから安心して。
どうぞ
diff --git a/arch/mips/include/asm/mach-ath79/kernel-entry-init.h b/arch/mips/include/asm/mach-ath79/kernel-entry-init.h
index d8d046b..c8a5056 100644
--- a/arch/mips/include/asm/mach-ath79/kernel-entry-init.h
+++ b/arch/mips/include/asm/mach-ath79/kernel-entry-init.h
@@ -23,6 +23,8 @@
and t0, t1
ori t0, CONF_CM_CACHABLE_NONCOHERENT
mtc0 t0, CP0_CONFIG
+ li t2, 0xc0140198
+ sw t2, 0x18050000
nop
.endm
これを適当な名前、例えば
999-overclock800mhz.patch
で保存して、それを
/lede/buildroot/path/target/linux/ar71xx/patches-4.4
下に置いて、あとはmake
760MHzとの違いは、0xc0140198を0xc0140190にするだけみたい。800MHzで不安定
だったら、760にすればいいかも。 あかん、行頭の+とかスペースとかタブが削除されとる。
こちらでどうかな
https://pastebin.com/yjKpdwL8
こっちも.endmの次の空行が削られてるけど、なんとかなるでしょ。 >>509
爆ぜるのか？
うちのは爆ぜてないよ。まあcpuを使い切るほどに使用したり、真夏の暑さでは
試してないのでなんとも言えないが。
ということで、自己責任でお願いします。 ありがとう。
どこにパッチを置けば良いかも教えてくれてとてもサンキューです
AG300Hでやってみようと思います BroadcomやQualcommAtherosのような米帝の企業が設計しているものはいざしらず
中華の企業が設計してるもんなんて定格がそもそも本当に定格なのか
それすら信用していいものか分からんぞ
帰ってきたら家が無くなってたなんて笑えないから
悪いことは言わんOCは止めとけ
むしろ下げる方向のDCなら止めないが >>513
511だが、ある意味おもしろい。DCのやりかた教えて。 まぁまぁ。
常時空調のない一般家庭の劣悪な環境下で
連続稼働させるルーターでのクロックアップの危険性を説いたものと理解します。
クロックアップについては実験目的ですよね
LEDEのkernelパッチの当て方を教えていただいたことに価値があるかと思います OCはベースのクロックをPLLを通して上げるパラメータを変えるのだと思いますが
だとしたら倍率を下げる方へパラメータを変更すれば下げられる
PLLの設定の仕方は当然ながらSoCごとに違うので
それぞれの仕様を見て設定値を算出する必要がある >>518
511だが、なるほど、ar7161の仕様がわかれば、原理的にはDCも可能であるという
ことですね。
勉強になります。 >>517
そういってもらえると嬉しいです。
もし需要があれば、gitを使った極私的簡単パッチの作り方も書きますが、いる？ ■ このスレッドは過去ログ倉庫に格納されています
