Zopfcode

かつてない好奇心をあなたに。

Linksys の新ルーター "Velop WRT Pro 7" を頂いたので濃密にレビューする。

Linksys が日本の無線ルーター市場に復活した。それが発表される直前の2024年6月、奇しくも私は Linksys 往年の名機 WRT54GS 日本版を手に入れていた。

Linux 搭載の民生用無線ルーターとしては最初期にリリースされた WRT54G シリーズは、2003年*1に登場してから今までの間で、最初にして最大の栄華を誇ったファミリーといっても過言ではない。何の栄華かというと、ルーター遊びである。WRT54G で動く Linux kernel のソースコードが OSS ライセンス GNU GPL v2 のもとに配布され、それがベースとなって OpenWrt が生まれたからだ*2。

民生用無線ルーターのマイルストーンであるこのシリーズをどう調理するか考えながら、写真を撮って X にアップロードした。すると驚くべきことが起こった。今なおこのシリーズで遊ぼうとする私の存在が、日本法人を通じて米 Linksys の CEO へと届いたというリプライを頂いたのである。

しかも「折角なら最新のWi-Fi 7対応搭載機をプレゼントしよう」との申し出まで頂いた。そんなことあっていいのか？とビックリすると同時に、ぜひしっかりと遊んで差し上げねばという使命感に燃えつつ DM を送った*3。それからしばらくの後、実際に発売されるものと完全に同じ仕様で技適マークのついた個体をついに受け取った。今年の2月のことである。

このような経緯で Linksys の Wi-Fi 7 対応無線ルーターである "Linksys Velop WRT Pro 7" (MBE70) を手に入れたので、本記事では OpenWrt 搭載ハードとしての Velop WRT Pro 7 を観察したのち、光クロス回線を通じた MAP-E と IPIP6 でのネット接続と実際の通信スピードをレポートする。

念の為明記しておくと、このルーターは Linksys 日本法人からご恵贈いただいたものであり、レビューの執筆を依頼されたり、他に何らかの見返りを受け取ったりしたことは一切ない。純粋に私なりのお礼として執筆しているに過ぎず、記載内容は Linksys 公式の見解ではないことを留意願いたい。

目次

珍しい OpenWrt 搭載ルーター、その中身は

純正で OpenWrt が動く本機種は、Wi-Fi を飛ばしつつ汎用なコンピューターとしても遊べる数少ない選択肢として日本市場に登場した。そこでまず、Velop WRT Pro 7 を OpenWrt 搭載ハードとして、ネットワーク機器というよりはコンピューターの側面から眺めていく。

本体の外観。

SoC

Velop WRT Pro 7 は Qualcomm IPQ9554 を搭載している。公式ページ、Qualcomm のプロダクトブリーフ、/proc/cpuinfo を総合すると、Arm Cortex-A73 クアッドコアでハードウェア FPU (VFP) と SIMD (NEON) をサポートしている。

IPQ9554 の specification。Cortex-A73, 802.11be など華々しい文字列が並ぶ。プロダクトブリーフより引用。

Linksys 曰く 1.5 GHz, Qualcomm 曰く 2.2 GHz とクロック周波数の表記に違いがあるが、cpufreq の cpuinfo_max_freq には 1488000 とあるので Linksys の表記が正しい。発熱等を鑑みてアンダークロックしている可能性があり、Device Tree の cpufreq 設定をクロック制限のない開発ボード相当に戻してからビルドすれば本来の周波数に戻すことも可能かもしれない*4。

# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq
1488000

近年は無線ルーターのハイエンド機を中心として SoC に Arm アーキテクチャのマルチコア CPU を採用する例がよく見受けられる。先述の WRT54G 時代から10年以上 MIPS のシングルコアかデュアルコアが普通だったことを考えれば目覚ましい変化である。Cortex-A73 はネットワーク機器向け SoC に実装された Arm CPU のマイクロアーキテクチャとしては最上位クラスにあたり、A72やA53が多数あるのに対してA73はこの製品以外にほとんど見たことがない。検索した感じではごく一部のルーターに採用例がある程度のようだ。

そのようなハードウェアながら少々気になるのが、動いているバイナリの ISA（命令セットアーキテクチャ）である。uname -m を実行すると armv7l と出力したので、カーネルが Armv7 (32bit ISA) 相当とわかる。この状況は 64bit SoC で 32bit のカーネルを動かしていた一時期の Raspberry Pi と同じともいえる。Armv8 でないからといってネットワークの性能に劇的に響くわけでもないし*5、ユーザー体験からすれば些末な差でしかないが、少し惜しい感じがする。

なお下図にあるように QSDK の menuconfig を確認したところ 64bit の選択肢があったので、32bit を選択しているのは何か理由があるのかもしれない。

QSDK の menuconfig の Subtarget 選択画面。64bit の選択肢がある。

DRAM

Velop WRT Pro 7 には 1 GB DDR4 という広大かつ高速な DRAM が搭載されている。近年こそ 1 GB 以上の DRAM を搭載したルーターが増えているが、2 GB の RAM を搭載する FortiGate 50E のような例外*6を除けば RAM 1 GB のルーターはトップクラスに位置する。

WRT54G 時代から2010年代前半まで 16 MB の DRAM で OpenWrt が動いていた*7ことを考えれば、これまたとんでもない進化といえるだろう。

Flash

無線ルーターのようないわゆる組み込みと呼ばれるジャンルのハードウェアでは、ブートローダー、カーネル、ソフトウェア、個体固有情報などが 生 NAND や SPI flash にまとめて入っているパターンが多い。本機種の場合は物がモダンなのが手伝ってか、ストレージとして eMMC という SD カードの親戚を搭載している。eMMC という時点で容量が大きそうなので簡単に調べてみた。

OpenWrt のルートファイルシステムは、読み取り専用のパーティションに別の書き込み可能なパーティションを文字通りオーバーレイする "overlayfs" が使われる。Overlayfs がある環境では、一見するとルートファイルシステムの全域が読み書き可能に見えるが、実はこれらへの書き込みはオーバーレイへと逃がされている。工場出荷時のルートファイルシステムは読み取り専用のまま保たれているので、設定のリセットを行った時やデータ破損時に、オーバーレイを消すだけで工場出荷時設定へ戻せるという利点がある。

というわけで、mount コマンドで現在マウントされている overlayfs の部分を探すと、/dev/loop0 つまりループデバイスを ext4 としてマウントしたものがオーバーレイとして見つかった。

# mount | grep overlay
/dev/loop0 on /overlay type ext4 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)

Sysfs を確認すると、loop0 の実体は mmcblk0p29、つまり0番目の eMMC の 29 番目*8を loop0 にセットしているようだ。普通 loop device は別のファイルシステム内のファイルをセットして使うが、どういうわけか eMMC のパーティション（ブロックデバイス）を丸ごと loop device にしている。真意は不明。

# cat /sys/block/loop0/loop/backing_file
/mmcblk0p29

fdisk を opkg でインストールしパーティションテーブルを見たところ、eMMC 全体としては 7.29 GiB、p29 は 500 MiB の容量を持つことがわかった。つまり、ルートファイルシステムには 500 MiB のデータが追加で置ける。

Command (m for help): p

Disk /dev/mmcblk0: 7.29 GiB, 7818182656 bytes, 15269888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 98101B32-BBE2-4BF2-A06E-2BB33D000C20

Device            Start     End Sectors  Size Type
/dev/mmcblk0p1       34    2081    2048    1M unknown
...(略)...
/dev/mmcblk0p29   84514 1108513 1024000  500M unknown
...(略)...
/dev/mmcblk0p33 2157090 7471069 5313980  2.5G unknown

現代の OpenWrt のルートファイルシステムは 8 MiB あればギリギリ実用的な構成のファームにできる*9ことを考えると、果てしなく贅沢な空間の使い方といえる。

ルートファイルシステムの容量が 500 MiB というのは、一般には帯にもタスキにも短い印象を持つかもしれないが、ルーターの文脈でいうとフルセットの CPython*10 がインストールできてしまうなどアグレッシブな遊びができる印象になる。用途は不明だが、末尾の広大な 2.5 GiB も少し気になるところだ。

I/O

I/O は本製品最大の惜しいポイントである。まず、LAN/WAN ポートと電源入力以外の入出力ポートが一切ない。ルーターの USB ポートを活用するユーザーこそ多くないとはいえ、上位機種に位置する無線ルーターで RJ-45 と DC ジャック以外のコネクタがないのは珍しい。

次に、Wi-Fi 7 のスループットが Gbps を超えるうえに WAN 側ポートが 2.5 GbE なのに対して、LAN 側ポートが 2.5 GbE 非対応なのが惜しい。NAS を主導に 2.5 GbE が有線 LAN の現実的なアップグレードとして認知されてきていることを思えば、有線のスペックがちぐはぐに映るというのが率直な感想である。このあたりから鑑みるに、従前の認識でいうハイエンドルーターというより、L3 やトンネルも扱える AP として本機種を捉えた方がしっくり来そうだ。

本体背面のポート類。

もちろん載せているのは OpenWrt なので、WAN 側ポートに L2 スマートスイッチを接続して Tagged VLAN を駆使した複雑怪奇な構成を組めば WAN 側ポートひとつで LAN と WAN の両セグメントを繋ぐ構成も可能かもしれない。また、bond0 があるのでボンディング（チーミング）もできそうな雰囲気がある。こういうアイデアが浮かんでくるあたり、変わったネットワークを組む腕試しの題材にするのも一興かもしれない。

QSDK（ソースコード）

OpenWrt のフォークである QSDK のソースコードが下記公式ページで公開されている。

ダウンロードして中身を見ると、企業が公開している OSS としては珍しくビルド手順の Readme も付属していて掴みはいい。しかし実際にビルドを試みたところ、Qualcomm のプロプライエタリなコードを参照しているらしいパッケージがあり、そのままではビルドが通らなかった。エラーが出たパッケージを順に無効化しながらビルドを進めればいつか成功しそうだが、少なくとも本記事の執筆時点でビルドには成功していない。

自分の手順が間違っているだけの可能性もあるが、できれば楽にビルドできて欲しかった感がある。自ビルドのファームを実機に書くことはないにせよ、カーネルモジュールのビルドや Device Tree のカスタムなど使い道はいろいろ考えられるからだ*11。

support.linksys.com

光クロスのスピード計測で実力を検証

ここまで、公式のスペックからあれこれ考察してきた。次は、日頃の使い道で最も重要といえるインターネットの接続性と速度を検証する。

設定に入る前に、まず我が家のインターネット環境がどんなものかを紹介する。

プロバイダ

enひかりクロスの回線を契約している。ISP が光回線を NTT から借り受ける光コラボ回線なので、契約はenひかりとだけ結んでいる。

オプション

  • v6プラス
  • 固定 IP

「v6プラス」は、MAP-E こと RFC7597 を仕様として IPv4 over IPv6 を実現するオプションである。回線契約者宅のルーターが NAT を行い、VNE から割り当てられたポート範囲でのみインターネットと相互に通信する。ポート範囲が限られているというのは、同じグローバル IP アドレスを他の契約者とポートレベルで分割して分け合うことに起因する。

「固定 IP」は、RFC2473 を仕様として IPv4 over IPv6 を実現するオプションである。RFC で使われている呼称ではないようだが、IPIP6 などと呼ばれることがある。実用上の MAP-E との違いはポート範囲が限られないことである。プロビジョニング方法は VNE により異なり、JPIX (JPNE) の場合は契約者宅のルーターが VNE の提供するエンドポイントへ IPv6 アドレスを登録すると VNE との間にトンネルが確立可能になる。これにより、契約者宅のルーターは全てのポートでインターネットと相互に通信する。余談として、実は MAP-E もまた RFC2473 を内部的に利用している*12*13。

まとめると、我が家のネット回線は MAP-E と固定 IP どちらでもインターネットへ出られる状態になっている。

10 Gbps で通信した場合のスピード

日頃の構成だと、MacBook Pro → QNAP QNA-T310G1S → XikeStor SKS8300-8X → YAMAHA RTX1300 の組み合わせを通じて 10 GbE でインターネットに出る。この場合は双方向ともに実測 6 から 7 Gbps ほどのスピードが出ている。つまり、Velop WRT Pro 7 の WAN 側ポートの理論最高速度である 2.5 Gbps を十分に上回るため、ベンチマークには問題ない回線品質といえる。Speedtest.net による計測結果とリンクは以下の通り*14。

Speedtest by Ookla - The Global Broadband Speed Test

Velop WRT Pro 7 のセットアップ

ここからは実際に Velop WRT Pro 7 を MAP-E と固定 IP それぞれの構成でインターネットに出させる設定を行う。今回はMacBook Air (15-inch, 2024) を使用したが、設定はほとんどブラウザで済ませられるので手順は他の OS でも概ね変わらないはずだ。

MAP-E のセットアップ

MAP-E の構成には複数の設定値が必要だが、IPv6 プレフィックスからこれらを自動で計算し設定してくれるスクリプトを Linksys 日本法人が公式に提供している。この自動構成スクリプトは ipk パッケージで公開されているので、ブラウザで OpenWrt の設定ができる LuCI でインストールしてもいいし、Velop WRT Pro 7 に scp 等で転送して opkg install コマンドでインストールしてもよい。今回は後者を選択した。

なお、このパッケージは他のパッケージに依存しているので、この時点でインターネット接続が必要である。回線が開通していない場合、Velop WRT Pro 7 の Wi-Fi 設定を AP（アクセスポイント）から STA（クライアント）に切り替え、スマホでテザリングするのが良いだろう。接続手順はここでは割愛するが、Pixel 9 Pro XL を使い 2.4 GHz でテザリングしたところ問題なく接続できた。

インターネット接続を確保したら以下のように手順を進める。まず、自動構成スクリプトのパッケージを scp で転送する。

$ scp -O ~/Downloads/velop-auto-ipoe_1.54_all.ipk root@192.168.1.1:/tmp

次に実機に SSH し、opkg リポジトリを更新しつつパッケージをインストールする。

# opkg update
{中略}
# opkg install /tmp/velop-auto-ipoe_1.54_all.ipk
Installing velop-auto-ipoe (1.54) to root...
Installing bash (5.0-4) to root...
Downloading http://downloads.openwrt.org/releases/19.07.9/packages/arm_cortex-a7_neon-vfpv4/packages/bash_5.0-4_arm_cortex-a7_neon-vfpv4.ipk
Installing map (4-13) to root...
Downloading http://downloads.openwrt.org/releases/19.07.9/packages/arm_cortex-a7_neon-vfpv4/base/map_4-13_arm_cortex-a7_neon-vfpv4.ipk
Installing ds-lite (7-4) to root...
Downloading http://downloads.openwrt.org/releases/19.07.9/packages/arm_cortex-a7_neon-vfpv4/base/ds-lite_7-4_all.ipk
Installing luasocket (3.0-rc1-20130909-5) to root...
Downloading http://downloads.openwrt.org/releases/19.07.9/packages/arm_cortex-a7_neon-vfpv4/packages/luasocket_3.0-rc1-20130909-5_arm_cortex-a7_neon-vfpv4.ipk
Installing luasec (0.8-1) to root...
Downloading http://downloads.openwrt.org/releases/19.07.9/packages/arm_cortex-a7_neon-vfpv4/packages/luasec_0.8-1_arm_cortex-a7_neon-vfpv4.ipk
Installing lua-openssl (0.7.1-1) to root...
Downloading http://downloads.openwrt.org/releases/19.07.9/packages/arm_cortex-a7_neon-vfpv4/packages/lua-openssl_0.7.1-1_arm_cortex-a7_neon-vfpv4.ipk
Installing lua-cjson (2.1.0-2) to root...
Downloading http://downloads.openwrt.org/releases/19.07.9/packages/arm_cortex-a7_neon-vfpv4/packages/lua-cjson_2.1.0-2_arm_cortex-a7_neon-vfpv4.ipk
Installing jq (1.6-1) to root...
Downloading http://downloads.openwrt.org/releases/19.07.9/packages/arm_cortex-a7_neon-vfpv4/packages/jq_1.6-1_arm_cortex-a7_neon-vfpv4.ipk
Configuring jq.
Configuring bash.
Configuring lua-cjson.
Configuring luasocket.
Configuring ds-lite.
Configuring luasec.
Configuring lua-openssl.
Configuring map.
Configuring velop-auto-ipoe.
#

ブラウザで LuCI を開くと、上のメニューにある "Services" に "IPoE Assistant" という項目が増えているのでこれをクリックする。パッケージのインストール前からログインしていた等により "IPoE Assistant" が見つからない場合は、右上の "Logout" をクリックしてから再ログインする。公式の手順ではブラウザのリロードを案内しているが、私の場合は再ログインが必要だった。

パッケージをインストールしたあと、Services メニューに "IPoE Assistant" というメニューが現れたところ。

『「オートIPoE を実行」をクリックして開始します…』とあるので、促されるまま「オートIPoE を実行」ボタンを押す。自動構成のログが表示されたあと、問題なく設定が完了すると「サービス開始」というダイアログが表示される。ルーターの再起動が終わるまでしばらく待つ。

MAP-E の設定が完了したことを表すダイアログ。

再び LuCI にログインして "IPoE Assistant" を開くと、自動構成サービスの動作を示すログと状態が表示される。この時点でもうインターネットに出られるので、Wi-Fi を STA モードに設定していた場合はこれを AP モードに戻しておく。

インターネットへの疎通を確認するため、LuCI の "Network" メニューにある "Diagnostics" を開き、openwrt.org へ IPv4 と IPv6 両方で ping が通ることを確認する。

IPv4 で ping したところ。応答が返っている。

IPv6 で ping したところ。こちらも問題なく応答が返っている。

さらに LuCI の "Network" メニューにある "Interfaces" でグローバル IP アドレスを確認すると、VNE が持つ IP アドレスが割り振られていることが確認できる。この時点では MAP-E で接続しているため、契約書に明記された固定 IP アドレスにはなっていないことに注意。

Interfaces 画面。有効なグローバルアドレスが割り振られている。

固定 IP のセットアップ

前節の時点でインターネット接続は達成しているが、固定 IP 構成にはなっていない。前述の自動構成スクリプト（執筆時点でバージョン 1.54）のコードを読む限り、ASAHIネットが提供する標準化されたプロビジョニング方式*15の固定 IP 接続には対応しているが、JPIX (JPNE) が提供する「fcs.enabler.ne.jp に IPv6 アドレスを登録する」方式には対応していないようだ。このため、本記事では自動構成スクリプトを使わずに手動で構成する。

YAMAHA RTX1300 が既に IPv6 アドレスを通知しているため私はアドレスの通知までは行っていないが、DHCPv6 でプレフィックスを得ている原理上 IPv6 アドレスは変わりうる（可能性や頻度は不明）。このため、手動構成のまま長期運用ができるのか不明である点は注意が必要。自力で通知するスクリプトを書くことも可能かもしれないが、このあたりは今後の自動構成スクリプト側の対応を期待したい。

まず現状の IPv6 アドレスをメモする。LuCI の "Network" メニューの "Interfaces" を開き、"WAN6" インターフェースの "IPv6-PD" の値をメモしておく。これはプロバイダから割り当てられた IPv6 プレフィックスである。

次に、自動構成スクリプトを停止する。LuCI の "Services" メニューの "IPoE Assistant" を開き、「オートIPoE を無効化」をクリックする。すぐに停止された旨のダイアログが表示される。

自動構成スクリプトを停止したところ。

次に、再度 "Interfaces" を開く。"WANMAP" インターフェースの行にある "Edit" をクリックし、"Protocol" の欄を "IPv4 over IPv6 (RFC2473-IPIPv6)" に変更し、"Switch protocol" ボタンを押す。読込中っぽいアニメーションが出るが待っても終わらないので、それを無視して "Dismiss" をクリックする。

改めて "WANMAP" インターフェースの "Edit" をクリックすると、Protocol が "IPv4 over IPv6 (RFC2473-IPIPv6)" に切り替わっているので、他の入力欄を以下のように設定し "Save" で保存する。

  • Remote IPv6 address or FQDN: プロバイダの資料に記載された BR アドレス
  • Local IPv4 address: プロバイダの資料に記載された IPv4 アドレス
  • Local IPv6 address: 先ほどメモした IPv6 プレフィックスと、プロバイダの資料に記載された「インターフェイス ID」をくっつけたもの（たとえばメモしたプレフィックスが xxxx:xxxx:xxxx:xxxx::/56、インターフェイス ID が yyyy:yyyy:yyyy:yyyy であった場合、くっつけると xxxx:xxxx:xxxx:xxxx:yyyy:yyyy:yyyy:yyyy になる）

WANMAP インターフェースの設定画面。

次に "LAN" インターフェースの "Edit" をクリックし、以下の欄を入力したあと "Save" で保存する。

  • IPv6 suffix: プロバイダの資料に記載されたインターフェイス ID の先頭に :: を追記しサフィックスの形式にしたもの（たとえばインターフェイス ID が yyyy:yyyy:yyyy:yyyy であった場合、::yyyy:yyyy:yyyy:yyyy になる）

LAN インターフェースの設定画面。

ここで "Save & Apply" をクリックすると設定が反映される。あとは実機に SSH して ping を走らせるなどして IPv4 によるインターネットへの疎通を確認する。正しい通信がしばらく確認できない場合は再起動してもよいだろう。

Velop WRT Pro 7 に SSH し Google Public DNS に ping しているところ。問題なく返っている。

スピードテスト

固定 IP によるインターネットへの疎通が確認できたところで、インターネットとの通信スピードを計測した。条件は以下の通り。

  • 測定時間: 平日朝7時〜8時ごろ
  • 測定サービス: speedtest.net（サーバー: GSL Network）
  • 測定回数: 条件ごとに1回*16

測定パターンは以下の通り。

  1. Velop → インターネット (Speedtest.net CLI)
  2. MacBook Air (15-inch, 2024) → 有線 (GbE) → Velop → インターネット
  3. MacBook Air (15-inch, 2024) → Wi-Fi 6E → Velop → インターネット
  4. Pixel 9 Pro XL → Wi-Fi 6E → Velop → インターネット

Velop → インターネット

Speedtest.net が公式に提供する Speedtest CLI の armhf 向けバイナリを Velop WRT Pro 7 内の /tmp に直接置いてスピードを計測した。本体から直接 2.5 GbE でインターネットに出ることにより、本機種自身の純粋なスループットが計測できる。

予想: 回線自身は 7 Gbps ほどのスループットが出せることから、性能が十分であるなら 2.5 Gbps 付近で頭打ちになるはず。

結果: 上下ともに 2.3 Gbps だった。ベンチマーク中のスピードがあまり変化しないことから、フレームサイズ等に起因するオーバーヘッドを引いて物理層で頭打ちになっていると推測される*17。よって、L2/L3/トンネリングの処理速度は少なくとも物理層のスループットに迫れるレベルと判明した。2.5 GbE 搭載の無線ルーターとしては申し分ないといえるだろう。

「Velop → インターネット」の計測結果。
Speedtest by Ookla - The Global Broadband Speed Test

MacBook Air (15-inch, 2024) → 有線 (GbE) → Velop → インターネット

予想: LAN ポートは 1 Gbps で接続されているので、1 Gbps 近辺で頭打ちになるはず。

結果: 物理層の理論スピードからオーバーヘッド分を引いたであろう結果となった。もはや GbE は朝飯前。

「MacBook Air → 有線 (GbE) → Velop → インターネット」の計測結果。
Speedtest by Ookla - The Global Broadband Speed Test

MacBook Air (15-inch, 2024) → Wi-Fi 6E (6 GHz) → Velop → インターネット

予想: macOS 曰く Wi-Fi のリンクスピードは 2 Gbps ほどなので、そこから大幅に減じても実測 1 Gbps を超える程度のスピードになるはず。

結果: 下りは予想通りになった。上りは 1 Gbps を割った。

MacBook Air → Wi-Fi 6E → Velop → インターネット
Speedtest by Ookla - The Global Broadband Speed Test

Pixel 9 Pro XL → Wi-Fi 7 (6 GHz) → Velop → インターネット

予想: MacBook Air よりも速くなる。

結果: 上りと下りどちらも安定的に 1 Gbps を超えた。この回だと下りは Mac より遅い数字になったものの、時として 1.9 Gbps ほど出ることもある。物理層が無線なのであまり深追いはしないが、Wi-Fi 7 のポテンシャルを感じる結果となった。

「Pixel 9 Pro XL → Wi-Fi 6E → Velop → インターネット」の計測結果。
Speedtest by Ookla - The Global Broadband Speed Test

Pixel 9 Pro XL → Wi-Fi 7 (MLO) → Velop → インターネット

Velop WRT Pro 7 は MLO をサポートするので、インターネットの情報から設定を試行錯誤したものの、今日の時点で MLO の動作は確認できなかった。手元で唯一 Wi-Fi 7 MLO に対応しているのは Pixel 9 Pro XL だけで、別のデバイスで試すなどの問題切り分けができないため断念した。これは後日再挑戦したいと思っている。

まとめ

上部の状態 LED は sysfs を通じて操作できる

ハイスペックな無線ルーターでありながら、その強烈な内面と質素な外観のコントラストには上級機種と呼ぶにふさわしい気品がある。ハイエンドの無線ルーターに派手な外観の製品が多いなかで、質素だからこそ輝くものがあると感じる。

また、2.5 GbE の物理層を使い切れる強力な性能により、VPN や動画配信などの通信にシビアなアプリケーションにも向くだろう。LAN 側ポートは GbE までになるため NAS のような大容量データを動かす用途では他製品に譲るところもあるが、家庭や小規模オフィスのほとんどのユースケースで十分な性能であることに変わりはない。

ネットワーク機器でネットワーク以外のことをやらせるのが好きな自分の視点だと、USB ポートが1つでもあればグッと遊ぶ幅が増えただろうなと思わなくもない。しかし中身をよく見ると確かな性能があるのは前述の通りなので、高いスループットと設定の柔軟さを活かして自分だけのネットワークを本気で作りに行くのもよし、カスタマイズした Wi-Fi 7 AP として使うのもよし、使い方はたくさんあるだろう。IPIP6 の JPIX (JPNE) 対応など、今後のエンハンスにも期待したいところだ。

*1:日本市場において。価格.com の登録日を根拠とした。

*2:この話を含む組み込み Linux の歴史について詳しくはこちら

*3:ちなみにこの時点で私の家では HPE (Aruba) Instant On AP11 を設置していたので、家の AP が Wi-Fi 5 (IEEE 802.11ac) から Wi-Fi 7 (IEEE 802.11be) へと一段飛ばし（6 GHz Wi-Fi も含めれば二段飛ばし）でアップグレードされることになった。

*4:本機種の Device Tree は読んでいないが、一般に cpufreq の取りうる選択肢として周波数のリストを Device Tree に記載するのが Arm SoC のボードでは一般的。

*5:今日のネットワーク機器の処理性能はハードウェアにオフロードした部分が大勢を占める。IPQ9554 も "WAN tunnel offload engine" とプロダクトブリーフにあるように L3 を超えるレイヤーすらオフロードしている。

*6:例外というか、そもそも家庭用ではない。

*7:ちなみに現在の OpenWrt も DRAM が 32 MB あればギリ動かせる。

*8:後者のインデックスは 1 始まりであることに注意

*9:あまりにギリギリなため、8/64 warningという言葉で公式な警告が一応されている。もちろんデバイスによっては 8 MiB に収まらないものもある。

*10:最もよく使われている C 実装の Python は CPython と呼ばれる。

*11:Device Tree は実機の fdt やバラしたファームから取り出すこともできるが、ソースコードの段階では human-readable な定数の識別子だった箇所が定数そのものに置き換わるなど可読性が低下する。

*12:RFC2473, Section 4: "MAP supports the encapsulation mode specified in RFC2473."

*13:RFC2473, Section 5.4: "On the CE, the path to the BR can be represented as a point-to-point IPv4-over-IPv6 tunnel RFC2473 with the source address of the tunnel being the CE's MAP IPv6 address and the BR IPv6 address as the remote tunnel address."

*14:ちなみに回線の名前が au になっているのは、v6プラスを提供する VNE である JPIX (JPNE) が KDDI の子会社であることに関連しているかもしれない。そのあたりのバックボーンや構成については知識がないが、概ねそんなところであろうと推測している。

*15:https://github.com/v6pc/v6mig-prov/blob/1.1/spec.md

*16:ネットに出るスピードは物理層より十分速いので、物理層や規格の違いによる大まかな性質が見えればよいと判断し簡便に1回とした。

*17:WAN 側の理想的な構成を宅内で用意してオーバーヘッドを直接計測しないと断定できないが、今回は行っていない。