【無線LAN】OpenWrt【強化ファーム】13 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>384 手順のアレンジ、ありがとうございます。 そうかぁ。2.4GHzの方も何か遅いと思ったら、bgのみで認識されているんですね。 ちなみに、dd-wrtも同じ手順で焼けますが、フォーラムでも指摘されている通り、wifiの出力が極端に弱くなり、使い物にならなくなります。 >>386 これ、元のファームウェアに戻す方法ってあるんですかねぇ 一応、bufpy で入った時に cat /proc/mtd で表示される全領域のdd バックアップは取ってありますが。 >>387 戻す方法としては、wzr-600dhp2のdd-wrtのbuffalo公式ファーム(USサイトはすでにダウンロードできませんが、他を探すといくつか見つかります)を経由して、元のファームに戻すことができます。 詳しい手順は、dd-wrtのフォーラムで、wzr-900dhp wifi signal low で検索すると記事があります。 >>387 >全領域のdd バックアップは取ってあります 純正ファームのcat /proc/mtdが残っていれば元に戻せる 純正ファームのcat /proc/mtd と dd-wrtのcat /proc/mtd を見比べて 必要な所を書き戻せば可能 openwrtからは戻せない可能性がある >>368 Buffalo公式dd-wrtファームじゃなくともdd-wrtのファームがあれば戻せる >>387 ,389 ありがとうございます。 2年くらい前の前々々スレあたりで SDKに含まれるbuffalo-encを使って 公式ファームからCFE用ファームを生成する方法の書き込みがありましたよね 今の環境でやってみたらうまくいかなくて、 当時生成できてたWZR-900DHP2用のをmini CFE web Serverからuploadなどしてたら… OSが起動できなくなってしまいましたw pingのTTLで判断する限り、mini CFE Web serverが無限ループしてる… もう一度LEDE 17.0.1.1をmini Web経由でuploadしても upload成功の画面に遷移するけど、 LEDEが起動してこなくなってしまいました。 CFEがまだ動いてるみたいだから完全brickしたわけじゃないけど 開腹しなきゃダメカモですねぇ >>391 多分、焼き込みに失敗しているので、30-30-30リセットすると元のファームに戻ると思う。 何度かそのパターンになったので。 >>389 cat /proc/mtdの事前値は取ってあって、 LEDE起動後のと見比べてみましたけれど、 レイアウトが違いすぎててLEDE上からオリジナルファームをddで書き戻すのは無理そうでした WZR-HP-xxx系と同じように安心して使えるように mini CFE web serverからオリジナルファームを書き戻す方法が見つかれば良いのですが >>392 重ね重ね情報ありがとう これから夜勤なのですぐはできないけど、 明日帰ってからやってみます〜 dd-wrt - RAMディスク上で読み書き(フラッシュは起動時に読み込むだけ) openwrt - フラッシュに直接読み書き この違いを理解しないと元に戻すのは難しい あぁなるほど。 OpenWrt/LEDE はoverayfs 使ってread onlyのファイルシステムへの書き込み差分をflashに保存するのに対して DD-WRTは設定をnvram領域にのみ書き込むから、フラッシュメモリのレイアウトが違うんですね。 mtdへのdd書き込みで戻すなら オリジナルに近いフラッシュレイアウト構成のDD-WRTでやる必要があるわけですね mussshinoさんがLEDEの公式Webの翻訳をしていただいているようです。 できる範囲で協力させていただきたいと思ってますが この手の翻訳って、原文に対する正確な訳出が必要でしょうか。 技術的にあっていれば大意を外さない程度に意訳でもいいのではないかと 私は考えていますが、皆さんの意見を賜りたく OpenWrt Chaos Calmer 15.05.1 proxy2ch_20170504-1_ar71xx.ipk http://pc.cd/IE97 フィード等 http://pc.cd/TWK7 >>392 brick疑いのWZR-900DHP ver 1.11 でしたが、 30-30-30 reset したらオリジナルファームが復旧しました! ありがとうございます ただしWZR-900DHP2 ver 2.15 としてwww おそらく mini CFE Web Server から 加工したファームウェアが送り込めたのだと思います。 再試を行いまして、WZR-900DHPの bootloader 内蔵の mini CFE Web Server 経由で 過去スレの以下の方法で生成した WZR-900DHP2 ver 2.15 のファームウェアをインストールできることがわかりました。 http://hayabusa6.2ch.net/test/read.cgi/network/1412980670/739 以下の手順で成功しました。 0) 純正ファームウェアの場合はバックドアから telnetd を有効化 http://192.168.11.1/cgi-bin/cgi?req=frm& ;frm=py-db/55debug.html に bufpy / otdpopypasswored でログインし、telnetd を有効化させる。 1)CLI上で nvram 設定を変更 # nvram set boot_wait=on # nvram set wait_time=20 # nvram commit 3) reboot reboot 4)起動中に mini CFE Web Server にWeb接続する http://192.168.1.1/ 5) WZR-900DHP2 のヘッダ加工済み firmware を uploadする 6) 転送に成功したメッセージが出たら、CFE Web Server 上のリンクをクリックして NVRAMをデフォルト状態にする。 7) NVRAM デフォルト化が成功したら そのまま Web Server 上の reboot のリンクをクリックして 再起動 8) http://192.168.11.1/ にアクセスして WZR-900DHP2 の Web画面になっていることを確認 9) 元がOpenWrt/LEDEだった場合はmtd のバックアップ領域(linux2/rootfs2)が壊れたままなので 再度正規のWZR-900DHP2用純正ファームウェアでアップグレードインストールする。 注意点としては 5)の転送成功のWeb画面に遷移するまでは 30-30-30 reset や nvram default化は行わないこと。 1) の nvram パラメータが初期化されるので CFE Web Server への接続が困難になります。 転送に成功すれば転送ファイルサイズともに成功した旨のWeb画面が表示されます。 失敗している場合は「ページが表示できません」になります。 おそらく他のWZR-xxxDHP系でも応用できると思いますが未確認です。 http://hayabusa6.2ch.net/test/read.cgi/network/1412980670/739 にもありますが、 純正ファームウェアをCFE用に加工できることがわかっているのは以下4機種だけです。 WZR-600DHP3 WZR-900DHP2 WZR-1166DHP WZR-1750DHP どんな機種でもOKな純正リカバリ方法ではないのが残念です。 >>403 まとめ、お疲れさんです。 リンク先が過去ログなので、念のため↓に貼り付けます。 0739 734 2015/04/28 00:06:28 WZR-DHP系のファームウェアを加工してみた?? >736 のヘッダの位置は各機種のファームで共通だったので?? linux上で以下のコマンドでCFEインストール用ファームウェアを生成できた?? (実機でのインストールは未検証)?? $ dd if=<buffalo_firm> of=temp.bin bs=1 skip=200?? (hexdump -C temp.bin | head で先頭がstart で始まっていることを確認)?? $ buffalo-enc -d -i temp.bin -o temp2.bin?? $ dd if=temp2.bin of=CFE_firm bs=1 skip=46?? (hexdump -C CFE_firm | head で先頭がHDR0 で始まっていることを確認)?? でも、ファームウェアによっては buffalo-enc でデコードが出来ないことがわかった?? WHR-300HP2 / WHR-1166DHPをオリジナルに戻す方法 AOSS押しながらのやつは 「フラッシュから読み込み」 ではなく「tftpから読み込み」なのでフラッシュに書き込みされない ソフトウェアリブート後に純正ファームが起動する この純正ファーム上でweb公開されてるファームでファーム更新する必要がある 文字化けの解消法はopenwrt入れる前に設定ファイル保存しておくこと 設定ファイル読み込ませれば文字化けは元に戻る (設定初期化したら文字化けするけど・・・) MZK-W04Gという古い11n機ですが、これのopenwrtインストール実績ってありませんか? 外観がほぼ同じなMZK-W04NUなら導入情報がたくさんありますが、中身は全然違うようです。 SoC STAR STR9102 フラッシュメモリ EON EN29LV640H-90TCP フラッシュメモリの型番を調べてみたら8Mbit=1MB? これが本当なら望み薄いかなぁ。 内部にはminiPCIカードが入ってて、RT2860Tが搭載されていました。 miniPCIカードを取り出して、手持ちのx86ノートPCへ差し込んで、 LEDE x86をいれて、kmod-rt2800-pciをいれたら使えました。 >>407 starsemiのstr91xxですね。caviumに買収されてcns11xxでもある。 確かopenwrtは動いた実績はないと思います。 検索してみると、bsdの文字が出てくるので、netbsdあたりで実績あるのかも。 そのフラッシュは64Mbit=8Mbyteじゃない? >EN29LV640H EON - 64 Megabit (4M x 16-bit ) 【ethaddr=00:90:cc:f3:ab:06】 でぐぐれば情報あり >406 ざっと見ました。 基本的にはOpenWrt、LEDE 双方のコミュニティ共、 再合流には前向きなようですね OpenWrt側がLEDEの呼称を使うことは否定してる一方、 LEDE側はOpenWrtのブランドを評価してLEDEの呼称には拘らない意見が多いようですね(実に意外) まだ議論尽くされてないのが LEDEの正式版リリースサイクルを再合流後も維持するのかどうかですね 私は今のLEDEのサイクルは早すぎると思っているので、 従来のOpenWrtをOpenWrt/LTS, 今のLEDEをOpenWrt/LEDEなどとすればいいんじゃないかなぁと思いました >>408-409 ありがとうございます。リンク先を見てみると、フラッシュ8MB RAM64MBでした。 USBがついてるので本体を有効活用したかったですがムリっぽいですね。 miniPCIカードは普通に動いてるので、これだけ活用することにします。 いちど喧嘩別れしたのだからそのまま別の道を歩むべき 簡単によりをもどそうとか考えるな 日本人的にはそう思うのが普通かと思うのですが、 感情や面子に拘らないんですねぇ 文化の違いってやつを感じました 一年ほどLEDEを運営してみて 認知度や資金援助面で限界を感じているんですかねえ 元々ニッチ分野のLinuxディストロですから リソースを集約する方向に動くことは 私は賛成しますね 今OpenWrtをインストールする前提でおすすめの無線ルーターってある? GbE対応、ac対応で あ、できたら国内で手に入るのがいい 無線APでも可 >>416-417 TP-Link Archer C7 (AC1750) 鉄板!! >>415 最初は合流賛成の意見ばかりかもしれないけど、あとの方ではそうでもないよ。 そもそも分離した時の問題はどうしたんだ?って意見もある 古いルータですが、Linksys WRT54GS (v1.0) に LEDE 17.01.1を インストールできました。 使ったイメージは以下で、インストールメソッドはBOOT時にtftpクライアントからのpush インストール 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.1.2 にする 2)LAN側MACを arp -s 192.168.1.1 00-0F-66-xx-xx-xx で スタティックに登録 3)ping 192.168.1.1 しつつ ルータ電源ON 4)192.168.1.1 から TTL=100 で応答あったら 別窓で tftp -i 192.168.1.1 put lede-17.01.1-brcm47xx-legacy-standard-squashfs.trx を実行 5)「転送を正常に完了しました:」のメッセージが出たら成功。 成功するまで繰り返し 4)の応答時間は1応答あるかないかくらいでかなりシビアだからPCとルータとの間にHUBを挟むことを推奨。 DRAM 32MB の機種のせいか初期状態で free メモリは 10MB 以下(38% free) LEDEの最低ラインですね >>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-4GRV3』として使うのが吉かと思いますね >>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接続、36ストリームの双方向同時通信時のパフォーマンス 1ストリーム、送信だけだと約20%程度向上 1ストリーム、受信だけだと約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 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる