【無線LAN】OpenWrt【強化ファーム】13 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
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セッションで60秒間の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 に対してだいたい2倍程度の速度を叩き出してます >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になってだいたい2.5倍に。
CPUクロックの向上(400MHz→720MHz)に比例したスループットになっています。
純正firmはクロック比以上の値になっているので、
何らかのアクセラレータ機能が有効になっているのかもしれません。
今までUSBなくなった廉価版のダメな子と思ってたよBHR-4GRV2。打ち捨てておいて悪かったw 何となくまとめ
Linux側でPPPoEサーバがユーザモードとkernelモードとで2倍以上の差がでることから
スループットはドライバの作りに大きく依存することがわかる。
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
1つ324円ならすべて購入するわ
十和田市のドフじゃ(ギガ対応の11nは)1つ 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を使った極私的簡単パッチの作り方も書きますが、いる? 早くしたいならルータとアクセスポイント別の筐体にすればいいじゃん 364円で買えるならクロックアップハックで楽しむのも有りでしょう
カーネルパッチを当てるのなら、
固まっても、u-bootでTFTPからの復旧はできそうですしね
クロックアップしたルーターで通常運用はしないかな
PLCCを書き換えるということはマスタークロックが上がってしまうので、
無線含めるとどこに影響出るかわからないし DD-WRTなら管理画面からポチでOCなのに面倒なんだな >>524
ポチをしてOCできたとしても、それが楽しいかどうかとはまた別なんだなあ。
パッチあててそうなったというのがおもしろいのであって。
>>505さんのHNATの情報なんて、ワクテカしないか? >>526
WXR-1900DHPを1.4GHz駆動させてると先にインターネット回線の方が足りなくなるんで特には そこは出来合いを活用するDD-WRTと
自分で組み上げるOpenWrt/LEDEの文化の違いではないかなぁ >>527
BCM4709A0って、DD-WRTで1.4GHzまでOCできるの?
ソースのどこかをいじれば、LEDEのbuildrootでも再現できるのかな? >>523
了解。
ざっくりとした流れとして、
1.# cd カーネルorパッケージの/ソースの/ルートディレクトリ
2.# git init
3.# git add 変更/したい/ファイル
4.# (editor) 変更/したい/ファイル
5.# git diff > xxx-hogehoge.patch
6.# cp xxx-hogehoge.patch /パッチを/あてたい/カーネルorパッケージ/patches
です。 例えば、パッチを作りたいパッケージと今組み込みたいターゲットが、
ターゲット:ar71xx
パッケージ:fugafuga
fugafugaへのパス:package/feeds/packages
だとして、
0.まずはfugafugaを組み込んだ状態で、一度ビルドする
# make
1.ar71xxに関わるソースは、build_dir/target-mips_24kc_musl/ 下にあるので
# cd build_dir/target-mips_24kc_musl/fugafuga
2.一時的なgitリポジトリを作成
# git init
3.変更したいファイル(ここではsrc/main.cとする)をgitに教える
# git add src/main.c
4.ファイルを編集して保存する。ここではviにしてるけど、お好きなエディタでどうぞ
# vi add src/main.c
5.git diffすると、コンソールにdiffが出力されるので、これをパッチファイルとして保存
# git diff > xxx-hogehoge.patch
6.作成したパッチを、fugafugaのpatchesディレクトリにコピー
# cp xxx-hogehoge.patch /path/to/buildroot/package/feeds/packages/fugafuga/patches
7.再度ビルド
# make 4.の"add"は間違いです。"add"はいりません。
6.でコピー先のpatchesディレクトリがまだなければ、自分でmkdirしてください。
パッチファイルのxxxは、3桁の数字を適当に(例えば999)割り振ってください。既にパッチがあるときには、
それとかぶらないのを割り振ればいいでしょう。
カーネル用のパッチは、target/linux/xxxxxxxx/patches下に置いて下さい。
パッケージのパッチは、一度作成すればターゲットにかかわらず反映されますので、別の
ターゲット用にいちいち作ることはありません。
ごりごり開発する人からするとしょぼく見えるでしょうが、簡単なパッチを作るにはこれで結構間に合います。
こうしたらもっといいのにというのがあれば、ご指摘ください。 ありがとうございます〜
非プログラマなのでgitの使い方までは調べられても、
LEDEにおける正しいやり方がわからなかったので助かります パッチファイルの番号はいまディレクトリにあるやつの最後の番号より大きい数字にしとくのが無難
先頭の数字3つ分が大きい値にしてあればいい
ワイルドカードでかき集めてパッチするから辞書順で適用していくので
最後にしておけば、すでにパッチ済みの現状を邪魔せずに追加するかたちになりまする この辺りの情報をまとめたいね
活用wikiでも良いけどどうせなら本家に
日本語版独自コンテンツを作ったら怒られるのかな? wzr-1166dhpなんだけど、dd-wrtの方では、5GHz、2.4GHzともに正常出力で、安定稼働するようなことがforumに書いてあるんだけど、ledeやopenwrtはどうなんだろう。
いま、ハドオフでジャンクを物色中。 ここは無線AP/ルータ 10種類以上持ってるような人ばっかりなのですか!? >>537
whr-1166dhpの方じゃないの? >>539
mediatecは、wsr-1166を1つもっているし、いけそうな感じがわかるんだけど、
broadcomは、wzt-900の例もあるから、いろいろ心配。 >>538
持ってる数は少ないよ。
openwrt/ledeをインストールして使ってきたのは無数にある。
というか、機種を選ぶときに、インストールできるか、もしくはサポートされる
可能性が高いかが基準になってる。 >>541
>>542
いや、SoCとしてはwzr-1750dhpとほぼ一緒だと思う。なので可能性としては
そちらのが使えるかもしれない。
brickしてもいいなら、値段次第じゃない? ledeとopenwrtの再マージのプロポーザルが、ほぼまとまったみたい。
http://lists.infradead.org/pipermail/lede-dev/2017-May/007771.html
続くスレッドで、主要な開発者がほぼ異議なしと言ってるので、これで進むと
思われます。 >>540
さすがにそれだけの数があると置き場所、コンセント確保、
無線のチャネルを衝突しないように割り振ったりファームウェア更新したりの管理も大変でしょうね Aruba とか Cisco aironet WLC みたいな
Wiress lan controller のOSSソリューションって何かありますかねぇ >>547
管理が大変なのは確かだけど、全部を同時に動かすわけじゃ無いでしょ。
うちも似たような数があるけど、込み入った仕事をやらせたときの前触れ無くリブートする頻度や、
無線の規格が同一でも、クライアントとしてぶら下げる端末同士の相性が結構ある。
さほど距離が離れていないのにリンクが途切れるとかね。
それを切り分けてバランスのよいAPを探すために、とっかえひっかえ、検証してる。 OpenWrt FWへ入れ替えて納めてサポートしてのSIerさん?
搭載して動かせるようになるのは大抵は現行品でなくなった頃だから
それでまとまった数を確保して納入する、とかの商売が成り立つのか
想像がつきませんが 550だけど個人で遊んでるだけだよ。
というか、これを仕事で納入なんて想像だにしたこと無いよ。
市販品を改造して仕事の道具として導入して、そのあとどんな結末になるかなんて、
誰でも想像付くと思うけど。 おそらくカスタマイズ用無線LAN装置でOpenWrtに対応してものは
世の中にはあるのだろうとは予想するけど、
そんな機器を納入できるSIerはクローズドでいろいろノウハウあるだろうから、
こういうスレに出入りはしないでしょうねぇ。。。 >>549
arubaとciscoのことを知らないので比較できるのかわからないけど、openwrt/lede
をインストールしたAPを集中管理できそうなのでいえば、openwispかなあ。
http://openwisp.org/
packageにもある
https://github.com/openwrt/packages/blob/master/admin/openwisp-config/Makefile
それと、これもいけそう
https://cucumberwifi.io/
でも、どちらも自分で使ってみたことがないので、実際のところはわかりません。 >>554
ありがとうございます。
複数のAPを統合管理するソリューションなのでこんな感じです。
GUIの感じは https://cucumberwifi.io/ が見やすくていいですね
完全OSSみたいなので、OpenWISPの方が良いかな?
無線LANルータをたくさん持っている方、これで遊んでみません? >>485,488,490 の PPPoE+NATスループット試験では
WZR-900DHPがWZR-HP-AG300Hに敗れる結果に終わりましたが、
それだけの評価ではWZR-900DHPがいらない子になってしまうので、
今度はLEDEにStrongSwanをインストールして、
PPPoE+NAT+IPSec (IKEv2 RSA) でのスループットを測ってみました。
結果、WZR-900DHP は WZR-HP-AG300Hの約2倍のスループットを叩き出しました。 今度は以下のような環境でテストしました。
[Win10x64]------[ LEDE Router ]-----[(ESXi6.0u3)-----(CentOS6.9 VM)----(Win7x64 VM)]
| ←----------PPPoE MTU 1454--------→ |
StrongSwan| ←----------IPSec IKEv2 RSA---------------------→ | 標準VPN Client
client|←-----------------------iperf3 -P 36 -d ---------------------→| server
CentOS6.9 x64 , rp-pppoe 3.10 (kernel mode)
LEDE 17.01.1 , StrongSwan 5.5.1
Windows7 Pro x64 , OS標準VPN Client, iperf3 3.1.3 win64
Windows10 Pro x64 , iperf3 3.1.3 win64
Win7 側で iperf3 -s
Win10側で iperf3 -c <iperf3 ip> -P 36 -t 65 -O 5 -d
※iperf3のIPはWin7側LAN IPと VPN IPとで切り替えて 通常PPPoEの場合と、IPSecの場合とで測定。 測定結果まとめ
◎BHR-4GRV + LEDE17.01.1
PPPoEのみ:送信:155Mbps / 受信:155Mbps
IKEv2 RSA:送信:14.5Mbps / 受信:14.3Mbps
◎WZR-HP-AG300H + LEDE17.01.1
PPPoEのみ:送信:310Mbps / 受信:310Mbps
IKEv2 RSA:送信:21.5Mbps / 受信:21.4Mbps
◎WZR-900DHP + LEDE17.01.1
PPPoEのみ:送信:274Mbps / 受信:275Mbps
IKEv2 RSA:送信:41.6Mbps / 受信:42.2Mbps
StrongSwanのインストール&設定用 ansible playbook を作成し、
3台とも同一の設定手順でStrongSwan の VPN環境を構築しました。
(証明書は同じものを使いまわしです) ■ このスレッドは過去ログ倉庫に格納されています