ELECOM WRC-1750GST2

いつも通り某フリマアプリを眺めていたところ、ジャンク扱いで¥1,000を切る出品があり衝動的に購入してしまったもの。
既にサポート済みのWRC-1750GS/GSVと一部を除き大方共通のハードウェアであるため、特に難なくサポートが完了し早いうちにマージされました。
まとめていきます。

仕様

前述の通り既にサポート済みのWRC-1750GS/GSVとほぼ同一のハードウェアであり、FlashとRAMの容量が異なるくらいの差。
法律の関係上、無線機能の使用は非推奨です

  • SoC: MT7621A (880MHz, 2C4T)
  • RAM: DDR3 256MiB
  • Flash: SPI-NOR 32MiB
  • WAN/LAN: 1000Mbps/1000Mbps x4
  • UART: J4, 57600bps(RJ45側から3.3V, GND, TX, RX)

その他詳細については、雑記を参照。

OpenWrt化

この機種も既存のWRC-*GS/GSV/GST(2)と同一のファームウェアフォーマットであるため、factoryイメージの生成を行えています。

WRC-1750GST2を起動
通常通り電源を接続して起動。ルータモードを前提とする
WebUIからファームウェア更新ページを開く
PCとWRC-1750GST2を繋いで http://192.168.2.1 にアクセスし、ファームウェア更新ページを開く
ファームウェア更新
WRC-1750GST2のOpenWrtのfactoryイメージを選択し、アップデートを実行
完了
Flashへの書き込みが完了後再起動され、OpenWrtで起動する

備考

この機種も変な癖は特にないのであまり書くことが無い。

  • メーカーファームに戻す際は、公式サイトで公開されているアップデート用ファームウェアの先頭32byte(= 0x20、ヘッダ部分)を削って firmware パーティションに mtd コマンドで書き込む
  • マージ時点でOpenWrt 21.02用branchは既に切られた後だった関係で、21.02リリースにはWRC-1750GST2のサポートは入らない
    と思っていたものの、いつの間にか21.02用branchにcherry-pickされておりリリースに含まれる模様

作業時の色々

  • 毎回恒例となっているが、factory生成コードを今回も使いまわせているのでとても楽。
  • また、ハードウェア構成を記述するdts/dtsiファイルもWRC-*GS/GSV/GST(2)系列でおよそ大半のバリエーションをカバーできる状態になっており、今回WRC-1750GST2で追加したのはmtdパーティションのうち共通化できない一部のパーティションのみ。
  • 色々

    今回は本当にごくわずかな変更のみであったことから、購入後NCP-HG100の作業の合間に気分転換も兼ねてハードウェア確認とサポート組み上げ、投げ込みテストやその他チェックなど行ったがかなり短時間で済み、そのままPRを投げ込んだ。そしてPRも特にツッコミを受けることなくすんなりとマージされ、一気に完了。
    既にディスコンとなっているものの中古ではそこそこの数が出ており、時々ある程度価格が落ちてくることから扱いやすいWRC-*GS/GSV/GST2系列の中でもFlashとRAMの多い機種の選択肢として良いかもしれない。
    WRC-1900GST2は今のところ確保しておらず予定も無し。

    BUFFALO WSR-2533DHP2

    個人的に初となるMT7622 (ARM)搭載機。もう既に記憶が曖昧であるものの、masterが確かKernel 4.14であった頃某氏より提供頂いてずっと作業を続けていました。
    途中から同じく某氏より実機の提供を受けたOpenWrtのチームメンバーであるHauke氏が加わり、何度かやり取りしながら今回ようやくサポート入りとなりました。まとめていきます。

    仕様

    SoCにはaarch64であるMT7622(mips(el)のMT7621ではない)を搭載し、無線は2.4GHz帯をSoCの無線機能を、5GHz帯はMT7615を搭載してカバーしています。また、SoCとSwitchの間は2.5Gbpsで接続されており、帯域に比較的余裕があります。
    法律の関係上、無線機能の使用は非推奨です

    • SoC: MT7622B
    • RAM: DDR3 256MiB
    • Flash: NAND 128MiB
    • WAN/LAN: 1000Mbps/1000Mbps x4 (RTL8367S)
    • UART: J4, 115200bps(RJ45側から3.3V, GND, TX, RX)

    その他詳細については、雑記を参照。

    OpenWrt化

    今回Hauke氏がfactoryイメージを仕立てて下さったので、簡単に投入できます。

    WSR-2533DHP2を起動
    電源ケーブルを繋ぎ、通常通りWSR-2533DHP2を起動
    WebUIにアクセス
    WSR-2533DHP2の設定用WebUIを開き、ファームウェア更新ページへ移動
    ファーム更新
    WSR-2533DHP2のfactoryイメージ(”squashfs-factory.bin”)を選択し、アップデートを実行
    この際、”factory-uboot.bin” はU-Boot用でありWebUI用ではないので選択しないこと
    完了
    Flashへの書き込みが完了後再起動され、OpenWrtで起動してくる

    備考

    WSR-2533DHP3は非サポート
    WSR-2533DHP3はスイッチその他でDHP2とはいくつかの差異があることが予想され、その関係上DHP2用のファームウェアは使用不可
    21.02リリースには入らない
    マージ時点では既にOpenWrt 21.02リリース用branchが切られた後であったため、当該リリースには間に合わずWSR-2533DHP2のサポートは入らない
    “factory-uboot.bin” イメージはU-Bootとその他用
    WebUI用の “factory.bin” ともう一つ “factory-uboot.bin” が生成されるようになっており、後者はU-Bootからの書き込みのほか、何らかの理由によりKernelとRootFSを一括で書き込む必要がある場合に使用するもの
    例:

    • 将来的にKernelサイズが現在の4MiBから更に大きいサイズに変更された場合
    • Flash内にメーカーファームウェアが存在している状態でinitramfsイメージでブートした場合

    ただし、sysupgrade時に使用する場合は仕様上設定を引き継ぐことができない

    Flash内のOSイメージは2組存在
    Flash内部にはOSイメージ領域が2組存在しており、その関係上OpenWrtでKernel + RootFS + ユーザー領域で使用できる合計サイズは58MiB(= 0x3A00000)ほど

    作業時の色々

    • とにかくイーサネットスイッチ部分が長らく問題になっていた。
      WSR-2533DHP2はRTL8367Sを搭載するが、つい最近までOpenWrtではこのスイッチのサポートが存在せず。別のRTL8367S搭載機種のPRでハードウェア的に近いRTL8367(R)B用ドライバである既存のrtl8367bドライバを改変して部分的にRTL3867Sサポートを追加しようとするものもあったが、どうにも進展が無いまま時間だけが過ぎていた。
      結局最近になってELECOMの市販されていない機種のサポートが入った際、同時にMediaTekから出たらしいRTL8367Sドライバがmediatek targetに追加され、ひとまずそれを使用できるようになったのでWSR-2533DHP2のサポートでもそれを利用した。
      ただ、決め打ちの箇所がだいぶ多く、その上OpenWrtでは使用されないコードが大量にあるあまりに巨大なドライバであるので、正直印象としてはだいぶ微妙。
    • 上記のスイッチ部分に次いで問題になっていたのがOpenWrtでFlashに書き込むファームウェアのフォーマットだった。
      NAND搭載機であることからRootFSにはUBIを使用したいところであったものの、単純に組み合わせようとするとエラーも吐かずブートが止まる問題を起こした。これについてはHauke氏がbcm53xxで使用されている方法を活用して解決してくださり、問題無くブートできるようになった。
      また、WSR-2533DHP2では “trx” というフォーマットのMagicNumberに非標準のものを用いる必要があり、OpenWrtでブート時にこのフォーマットからKernelとRootFSを分離するドライバでは標準のMagicNumber以外を認識できないため、代わりにLinux Kernel内の parser_trx に非標準MagicNumberのサポートを追加したうえで利用することとなった。
      この非標準MagicNumberのサポートはWCR-1166DSのfactoryイメージがブートできない問題の解決に必要となるので、今後の状況を見つつ可能になったらその問題を修正する。
    • 上記で少し触れたとおり、WSR-2533DHP2のサポートは部分的に将来的なKernelサイズの増加に備えたものにした。今現在のところ4MiBで問題はないものの、今後Kernelバージョンが上がっていくにつれて増加していくため、もし必要に迫られたときに大量の変更が必要になるのを避けたかったのと、それの対処についてある程度方向性を示したかった。

    色々

    今回、WSR-2533DHP2のサポート本体は自分の割合が多いものの、動作に必要となる周辺パッケージの改変やアイデア、コードの修正や改善、その他様々な点でHauke氏にご協力頂きました。また、最後こちらはNCP-HG100に掛かりっきりになってしまっていたのもあり、Hauke氏によってMLへのpatch投げ込みとコメントを受けての修正、マージまでやって頂き、本当に感謝です。
    1年以上を要したものの、ようやくマージとなり肩の荷が下りた。aarch64としてはMT7622搭載機はハイエンドよりはミドルレンジ寄りであるほか、中古価格も最近だいぶ落ちてきており入手性としては良さそう。
    現在同じくMT7622を搭載するWSR-3200AX4Sのサポート作業も進行中です。WSR-2533DHP3は今のところ作業予定は全くありません。

    NCP-HG100進捗報告

    書こうかと言いつつ作業に没頭して忘れかけていましたが、書いておきます。
    なお、NCP-HG100には型番末尾に “/Cellular” が付くWWAN対応モデルと付かないWWAN非対応モデルがあり、手元にあるのはWWAN対応モデルである為、その仕様を前提として書いていきます。

    仕様

    オーディオ周りはSoCの機能からしてKernelとOpenWrtどちらにもドライバが無く、現状使用できません。

    Model NCP-HG100
    SoC Qualcomm IPQ4019
    RAM SK hynix H5TC4G63EFR
    (DDR3 512MiB)
    Flash KIOXIA THGBMNG5D1LBAIT
    (eMMC 4GB)
    WAN/LAN (switch) 1000Mbps x1 / 1000Mbps x1
    (QCA8072)
    WLAN IPQ4019
    (SoC, 2.4/5GHz)
    USB USB 2.0 Type-A x1
    Bluetooth Qualcomm CSR8811
    Z-Wave Silicon Labs ZM5101
    Amplifier Realtek ALC1304
    Voice Input Processor
    (for Amazon Alexa Voice Service (AVS))
    Conexant CX20924
    MCU Nuvoton MINI54FDE
    (RGB LED, Fan, Temperature)
    Touch Sensor Controller Cypress CY8C4014LQI
    RGB/White LED Driver Texas Instruments LP55231 x2
    Bootloader U-Boot
    OS QSDK (OpenWrt based),
    Linux Kernel 4.4.60

    サポート作業状況

    元々 “暇な人” 氏が先行して作業していたものを途中からこちらでも弄り始め、その後氏の事情による活動縮小に伴い本格的に作業を開始しました。コードベースとしては、現在おおよその体感として6-7割程度が氏によるものです。
    現状、”ルータとして” 必要最低限程度に動作する状態です。また、現在も作業中でありマージされていないため、使用はおすすめしません。もし使用して何らかのトラブルが発生しても、私や暇な人氏は一切の責任を負いません。
    devadd/ncp-hg100
    devadd/ncp-hg100_mcu(MCUドライバ試行)

    • 現状動作するもの
      • initramfsイメージでのブート
      • eMMCからのsysupgradeイメージでのブート(要U-Boot設定)
      • sysupgrade時の設定保持
      • イーサネット
      • 無線(2.4/5GHz)認識(実動作未確認)
      • LED(底面のLP55231によるもの)
      • USB 2.0 Type-Aポート
      • RESET, SETUPボタン
      • WWANモジュール認識(暇な人氏により確認済)
    • 現状限定的に動作するもの
      • RGB LED(筐体外周)
        OpenWrt内やKernel内の複数のドライバをベースにしてMCU本体とLEDのドライバを作成。現状ではごく基本的なLEDサポートのみで、本来MCUが持っている様々な点滅パターンの制御は行えない
        また、MCUのI2Cに対する反応速度の問題からRGB同時点灯の白色を単一のLEDとして使用することはできない
    • 現状動作しないもの
      • マイクミュート, 音量Up, 音量Down, Alexa呼び出しボタン
        タッチパネルを制御するCY8C PSoCのドライバが現状無く、システム起動中のモードから抜けて通常動作モードに移行させることができない為
      • ファンコントロール, 温度読み取り
        MCUドライバが現状LEDサポート部分のみである為
      • Bluetooth
        UARTに接続されていると思われるが、ドライバの有無やアクティブ化の方法が不明
      • オーディオ関連全般
        IPQ40xxが搭載するオーディオ関連機能は現状Linux KernelとOpenWrtどちらにもドライバが無く、KernelのMLには2016年にpatchが投げられているものの指摘を受けた後作者から反応が無く完全に停滞。現状マージされる見込みがない
        また、Conexant CX20924も同様にドライバが無い。KernelのMLにConexantからpatchが投げられているが、2017年を最後にやり取りが途絶えている

    作業での色々

    ノリと勢いでMCUとRGB LEDのドライバを書いた
    NCP-HG100のMCU (Nuvoton MINI54FDE) は仕様に書いた通りRGB LEDを搭載しているが、それをLinux KernelのLEDクラスとして登録することでOpenWrtから扱いやすくできないかと考えた。stockファームウェアではあくまでMCUへ値を直接受け渡すだけのsysfsが提供されるのみのドライバであり、参考になる部分があまり多くないので厳しいかなぁと思ったものの、Linux Kernel内やOpenWrt内の色々なドライバを参考にとりあえず書いてみることにした。
    結果、知識不足からKernel Panicさせたり色々手こずったりしたものの、OpenWrt内のath79ターゲットに存在するRouterBoard 4xx用ドライバを参考にMCU部分のドライバを、Linux Kernel内のleds-pwmドライバを参考にMCUにぶら下がっているRGB LEDのドライバをいずれもそれっぽいところまで動作するように作れた。勢いは偉大。
    fstoolsでの変更によってコンソールやネットワーク周りなどが壊れた
    Twitterとかでひたすら悩んでたのがこれ。
    一度目におおよそ弄りたい範囲を終えてそろそろ投げ込めそうになった頃、念の為ビルドして動作確認してから暇な人氏に連絡取って確認してもらおうということでビルド実施した。ビルド終わってから投げ込んだところ、ブート途中のfailsafeに入るかどうか聞かれるタイミングまでは正常であるものの、それを過ぎるとシリアルコンソール上でEnterキーを押してもBusyBoxのash (shell)が立ち上がらず、OpenWrtのコンソールに入ることができなくなった。同時に、ネットワークもおかしくなっているのかWirelessNetworkWatcherで確認しても出てこない。SSHも繋がらない。
    この問題で1週間くらい解決できず止まっていたが、Gitログひっくり返したり目に付くものrevert繰り返したりしてひたすら原因探しをした結果、全く予想外のfstoolsに入った変更が原因だった。
    fstools: add partname volume driver git.openwrt.org Git – project/fstools.git/commit
    OpenWrtのサブプロジェクトであるfstoolsは、デバイスのブート中にユーザー領域としてOverlayfsでマウントする “rootfs_data” パーティション絡みの取り扱いなどを担当している。
    SDカードやeMMCの場合、stockファームウェアでのパーティション構成を以下の例とする。”rootfs_data” というデータ保存用のパーティションが存在していることが多い。

    OpenWrtにおいては、fstoolsの上記commit以前では “rootfs_data” と名付けられているパーティションを扱えなかった為、 “rootfs” と名付けられたパーティション内(正確にはKernelのcmdlineで指定されているrootデバイス)のSquashFSによるRootFSの後ろに、loopデバイスとしてext4によりフォーマットして “rootfs_data” と名付けた領域を置くことでそれをOpenWrtのユーザー領域として扱っていた。

    本来の “rootfs_data” パーティションを使えない状態ではあるものの、2つOSイメージを抱える機種などではユーザー領域を個々のOSイメージ領域内に持たせてそれぞれ独立させることができるなど、有利な点もあった。
    が、突如としてfstoolsに入った上記commitの変更により、ブート時に “rootfs_data” パーティションを扱えるようになった(1枚目のstockにおける構成と同じ状態)

    ただしここで問題になるのが、NCP-HG100で元々OpenWrtで使用することを想定していたのはあくまで “rootfs” パーティション内に存在する “rootfs_data” のみであり、”rootfs_data” パーティションは全く想定しておらずstockファームウェアでのデータが残されていたこと。
    その結果、”rootfs” パーティション内の “rootfs_data” に代わってこのパーティションがブート中にOverlayFSでマウントされてしまい、コンソールやネットワークなどを正しい状態に構成するためのファイルが欠落し、それらに問題を起こしていた。
    ちなみに、ipq806xターゲットに存在するZyxel機では、このfstoolsでの変更に起因して4MiBしかない “rootfs_data” がマウントされ(ようとしてフォーマットに失敗するのでtmpfsが代わりに使用され、設定が保存できないので再起動するたびに初期化され)る問題を起こしていた。
    NCP-HG100では “rootfs_data” パーティションが約1.6GBのサイズであり、fstoolsの変更が入る前の構成に戻そうとするよりは変更後の状態を活用する方がメリットが大きいと判断したため、sysupgrade周りのコードにおいて “rootfs_data” パーティションを扱うように手を加えて対処した。

    NCP-HG100は手元にある /Cellular のサポートとして既に投げ込んでおり、OpenWrtチームからの反応待ち。

    ELECOM WRC-1167FS

    今度は小型のこの機種。色々悩んでずっと保留にしていましたが、きっかけもあってエイヤと投げ込みました。
    まとめていきます。

    仕様

    自分の中では初となるMT7628A搭載機。ハードウェア構成としては比較的WSR-1166DSに近いです。
    Flashは16MiBのものを搭載するものの、メーカーファームウェアでは何故か前半半分 (8MiB)しか使われておらず後半半分は空。もったいない。
    法律の関係上、無線機能の使用は非推奨です

    • SoC: MediaTek MT7628A
    • RAM: DDR2 64 MiB
    • Flash: SPI-NOR 16 MiB
    • WAN/LAN: 100Mbps/100Mbps
    • UART: J1, 57600bps(”J1″ の印刷側から 3.3V, GND, TX, RX)

    その他詳細については、雑記を参照。

    OpenWrt化

    この機種もWRC-2533GHBK-Iと同様に、ヘッダ2つが使用される形式であり、どちらも構造を把握できていた為factoryイメージを生成するようにしました。
    ルータモードに設定されていることを前提とします。

    WRC-1167FSをブート
    WRC-2533GHBK-Iに電源ケーブルを接続し、通常通り起動
    WebUIを開き、ファームウェアアップデートページに移動
    http://192.168.2.1/ にアクセスし、ファームウェアアップデートページを開く
    アップデート実行
    OpenWrtのfactoryイメージを選択し、 “適用” ボタンをクリックしてファームウェアアップデートを実行
    完了
    OpenWrtで起動してくれば完了

    備考

    • 上で触れたとおり、搭載されているFlashは16MiBのものながらメーカーファームウェアで使用されているのは前半ちょうど半分のみであり、OpenWrtでもそれに倣った結果OpenWrtにおいてKernel + RootFS + ユーザーデータで使用できる合計は 7.18 MiBと少し程度。
    • “LAN” ポートそばのLEDに少々問題があり、SoC内蔵スイッチによって直接制御させようとしたところ挙動不審となる為、OpenWrtでは “INTERNET” と “LAN” どちらも接続の有無によって点灯/消灯するように構成した。トラフィックによる点滅は無し。

    作業時の色々

    • この機種で最も悩んだのがfactoryイメージに必要なヘッダ部分。前述の通り2つのヘッダが使用されており、1つ目はサポート済みのWRC-300GHBK2-IやWRC-2533GHBK-Iで1つ目として使われているもので、これは特に問題なし。問題は2つ目で、WN-AC1167GRや、WRC-2533GHBK-Iの2つ目として使われているものと似ているものの、全体的な構造がやや異なるほかチェックサムの種類やその値を取るタイミングが異なっており、それらをどうするかどうかで長期間悩んだ。
      この機種の作業開始当初はWRC-2533GHBK-Iサポートよりもずっと前であった為1つ目のヘッダを生成するコードはまだ分離前であり、WRC-1167FSの為だけに1つ目と2つ目のヘッダ用に長い生成コードを書く必要がある(当時はWRC-300GHBK2-I等のコードからの分離に思い至らなかった)ことから気が引けてしまった。
      ちなみに、途中で2つ目のヘッダをWN-AC1167GR等のフォーマットと一緒にC言語の生成ツールに書き直すことも考えたりした。
      これが原因でかなり長期間保留となっていたが、WRC-2533GHBK-Iのサポートの際1つ目のヘッダの生成コードを分離したことからWRC-1167FSでは2つ目のみのコード追加で良いことになり、調整した上で投げ込んだ。

    色々

    グダグダとしたまま長期間経ってしまい長らく悩みのタネとなっていたものの、ようやく投げ込んでマージされて肩の荷が下りた。
    若干大きい残念なポイントとしてFlashのパーティション構成があるものの、既に製造終了となってからしばらく経過していること、元々安価な機種であることから、イーサネットはFEながら何か小規模なものを動かしておくなどするのに良いかもしれない。

    I-O DATA WN-DX1200GR

    PRをオープン後、多少議論はあったものの意外と早くマージされました。I-O DATAの現行ミドルレンジ帯のこの機種です。
    価格設定的にWN-DX1167Rの後継と思われる為、既にサポート済みのWN-DX1167R, WN-AX1167GR2と大体同じかと思いきや、いくらか違いがありました。
    後回しにしていたら記事を書き忘れていました。まとめていきます。

    仕様

    WN-DX1167R, WN-AX1167GR2と同様にSoCにはMT7621Aを搭載しつつ、無線周りがMT7615D一つからMT7603E + MT7613BEの構成に変更されています。
    その他の仕様はあまり変わりません。
    法律の関係上、無線機能の使用は非推奨です

    • SoC: MT7621A (880MHz, 2C4T)
    • RAM: DDR3 128MiB
    • Flash: NAND 128MiB
    • WAN/LAN: 1000Mbps x1/100Mbps x4
    • UART: J5, 57600bps(三角マークから3.3V, TX, RX, NC, GND)

    その他詳細については、雑記を参照。

    注意事項

    本機種もWN-DX1167R, WN-AX1167GR2同様に、snapshotファームウェアでの使用は推奨できません。理由も同じで、特定状況下でバグを踏むなどしてOpenWrtがブート不能になった場合に復旧が非常に困難である為です。
    既にブランチが切られて最終的な準備が始まったOpenWrt 21.02リリースに含まれる見込みである為、それを待つことを推奨します。
    21.01リリースがアナウンスされた後、こちらでテストして問題無ければこのブログのデバイス情報ページにある “Latest Rel.” をsnapshotから変更予定です。

    OpenWrt化

    この機種もWN-DX1167R, WN-AX1167GR2同様にOSイメージを2つ持つ構造であることから、2段階でのインストールが必要です。

    WN-DX1200GRを起動
    電源ケーブルを繋ぎ、普通に起動
    WebUIにアクセス
    PCとWN-DX1200GRをLANケーブルで接続し、 http://192.168.0.1/ へアクセスしてファームウェア更新ページへ移動する
    ファームウェア更新
    OpenWrt initramfsイメージを選択し、アップデートを実行
    sysupgradeを実行
    上の手順を実行後再起動されOpenWrtで起動してくるので、そこでさらにそれぞれの機種のsysupgradeイメージを用い再度ファームウェアの更新を行う。これを行わないとinitramfsイメージでブートした状態であるため、変更した設定などが保存されない。
    完了
    Flashへのsysupgradeイメージの書き込みが完了後再起動され、OpenWrtで起動してくる

    備考

    • 前述の通りOSイメージを2つ抱える形の為、OpenWrtにおいて Kernel + RootFS + ユーザーデータで使用できる領域は合計で 50MiB (0x320000) 程度。

    作業時の色々

    • WN-DX1200GRは当初WN-DX1167R, WN-AX1167GR2と大体ハードウェア構成が同じかと思っていたが、実際のところ仕様でも触れたとおり差異があったほか、ソフトウェア面でもFlash内のパーティション構成がわずかに異なるなどしていた。
      しかしながら全体としてはほとんどが共通である為、当初WN-DX1167R, WN-AX1167GR2, WN-AX2033GRで用いているdtsiを一部手を加えた上で使用する方針だった。しかしPRをオープンしたところ “可読性が低いのではないか” という指摘があり、確かに自分自身そう思うところはあったのでdtsiの使用をやめて単独のdtsを使用するように変更しマージされた。
    • ある程度サポート作業が進み無線周りの構成に入った際、何故か5GHz帯用のMT7613BEにおいてMACアドレスが何度やっても正しく適用されない問題が起きた。
      ドライバを確認してみたところMT7613 (MT7663)においてはFlash内のeepromデータ読み取りがサポートされていない状態であり、それ故にeepromデータ内に埋め込まれているMACアドレスも適用されないということだった。
      ひとまずこれについては既知の問題としてcommit内に書き留めておいた。
      後日、MT7613 (MT7663)においてもeepromデータを読み込めるようにする変更が別の方によりOpenWrtに入った。

    色々

    上にも書いたとおり、意外とすんなりマージされたので安心した。
    この機種は結局、メーカー公式ファームウェアが公開されるよりも先にOpenWrtのファームウェアが出ることになってしまった。なので、そもそもとして確保前にファームウェアの中身を覗くことができていなかったりする。
    WN-DX1167Rが既に製造終了となり(WN-AX1167GR2も同様)、価格設定からして後継がこの機種であると思われ、入手性と価格的に良い機種と思われる。また、21.02リリースではDSAサポートが正式に入ってくるとされており、最初のリリースである21.02.0には間に合わないかもしれないもののDSAにおけるVLAN周りの整備も行われる予定で、その点でも扱いやすい機種となるかもしれない。