大破ログ

日々大破、それと側転少々。PC関連その他、気になったことなどをつらつらと。

WAB-I1750-PSのOpenWrtにおける "SERIAL" ポートについて

OpenWrt/ath79

さて、最近のELECOM公式のセールによってすっかりお馴染みとなったWAB-I1750-PSですが、OpenWrtにおいて "SERIAL" ポートの動作がサポートされました。

留意する点がいくつかある為、まとめていきます。

仕様

  • メーカーファームウェアでのSERIAL ポート

    • コマンドラインによって設定を行うことを目的として、所謂Ciscoケーブルを接続する為のRJ-45ポート
    • 115200bpsで動作

  • OpenWrtでのSERIALポート

    • デフォルトではコンソールの割り当ては無し
      • Enterキーを押しても改行されていくだけで、シェルは表示されず、操作は不可
    • Linux Kernelのデフォルトである9600bpsで動作

OpenWrtにおけるSERIALポートの使用

2024/03/26改訂: WAB-I1750-PSのサポート用コードを変更するほか、OpenWrtのシステム系に手を入れることでLinux KernelやOpenWrtのコンソールをデフォルトで割り当てられそうだ、と思い至ったので変更を試して投げ込み、マージされました。

下記コミット以降において、U-Boot部分とOpenWrtの一部システムメッセージを除いて、 "SERIAL" ポートを "SERVICE" ポートと同様に利用することが可能です。

procd: update to Git HEAD (2024-03-25) · openwrt/openwrt@ff064b6

  • 備考

    • OpenWrtの一部システムメッセージは "SERVICE" ポートにのみ出力され、 "SERIAL" ポート側には出力されない

      • - config restore -
      • - failsafe button <button> was pressed -（failsafeモード移行時）
      • - failsafe -（failsafe移行時）
      • sysupgrade時の Commencing upgrade. Closing all shell sessions. 以降のログ

      など

    • "SERIAL" ポートでOpenWrtのコンソールを利用しない場合、/etc/inittab 内の ttyATH1::askfirst:/usr/libexec/login.sh 行の先頭にシャープ (#) を置いて（前後にスペースは入れない）コメントアウトする

    • "SERIAL" ポートはLinux Kernelの "bootconsole" ではない関係上、Kernelのブート最初期段階からは出力されず、ブート中に ttyATH1 が有効になったタイミングでdmesg先頭からその時点までが一気に出力される

何らかのアプリケーションで /dev/ttyATH1 をオープンするか、ポートにOpenWrtのコンソールを結び付けるなどして使用してください。

  • 共通

    • シェル上でbaudrateをデフォルトの9600bpsから変更する場合は、stty コマンド等を使用する
      • 例: stty -F /dev/ttyATH1 115200

  • OpenWrtのコンソールとして使用

    1. /etc/inittab の末尾に以下を追記
      ttyATH1::askfirst:/usr/libexec/login.sh

    2. WAB-I1750-PSを再起動
      ブート後半でSERIALポートのコンソール上に Please press Enter to activate this console. と表示され、操作が可能になる

    注: firstboot すると /etc/inittab の変更が消失し、コンソールが再び開けなくなるので注意すること。また、sysupgrade時に引き継がれる対象のファイルに含まれていない可能性があるので、その点も注意する。

    なお、追記済みの /etc/inittab ファイルを用意して、Image Builderでそれを組み込んだイメージをビルドすることも可能。

技術的な話

WAB-I1750-PSが搭載しているSoCであるQualcomm Atheros QCA9558の属するQCA955xシリーズでは、プライマリのUARTにはごく一般的な8250互換である16550 UARTを搭載しているが、それに加えてセカンダリとしてAtheros AR933xが搭載するUARTと互換のものを備えている。
前者は "SERVICE" ポートや、それと同一ラインである内部ピンヘッダに割り当てられ、メーカーによるデバッグや復旧用となっている一方で、後者はこの記事で主題となっている "SERIAL" ポートに割り当てられ、ユーザーによる設定用として供用されている。

QCA955x SoCにおいて、16550 UARTは何ら問題無くサポートされ機能する状態であるものの、AR933x互換UARTについてはこれまでQCA955x SoC上ではOpenWrtにおいてサポートされておらず、WAB-I1750-PSのサポートがOpenWrt公式にマージされた時点では使用不可の状態であった。
ただ、それがマージされた時点で少々気になっていた点があり、落ち着いてからDeviceTreeを弄ってみたところ、Linux Kernelへのpatch等は無しで動いてしまった。そこで折角だからとQCA955x SoCにAR933x互換UARTのサポートを追加する変更と、WAB-I1750-PSでそれを有効化する変更を仕立ててOpenWrt公式に投げ込み、マージされた。
これにより、OpenWrt公式のファームウェアでも "SERIAL" ポートが使用できる状態となった。
ちなみに、できればメーカーファームウェアと同じ115200bpsで動作させたかったものの、DeviceTreeプロパティの current-speed がAR933x互換UARTのドライバではサポートされていなかった為、やむなく9600bpsで置いておくことになった。

当初はLinux Kernelのdmesgも "SERIAL" ポートに "SERVICE" ポート同様出力させようとしてみたものの、OpenWrtのプロセス管理ツール（systemdの代替）であるところのprocdによるコンソールの検出ロジックとLinux Kernelによるメインコンソールの取得ロジックが嚙み合わずworkaroundを用いた結果、failsafeモード下において "SERVICE" ポート側の入出力が壊れる問題が発生した為、断念してdmesgは流さないこととした。
具体的にはLinux Kernelがbootargsに存在する複数の console= 引数のうち最後を /dev/console として割り当てるのに対し、procdは最初のものをOpenWrtのコンソールとして取得してしまう為、対象となるコンソールの不一致が起きた。その為の対処として "SERVICE" 側のコンソール (ttyS0) を最初と最後で2回設定したところ、通常起動のOpenWrtコンソールでは問題無いものの、failsafeモードにおいては "SERVICE" 側の入力が壊れた（入力が中途半端な状態で送出される, 前の入力が一緒に送出される等）。

また、/etc/inittab へユーザーによる追記が必要な点については、あくまでWAB-I1750-PSでは ttyATH1 が設定用シリアルコンソールとして供用されているというだけで、それ以外のデバイスでは他の目的で用いられている可能性が絶対に無いとは言い切れない為、ath79/generic の /etc/inittab としてttyATH1をコンソールに割り当てたものを用意することはしなかった。

2024/03/26追記分:

上記のLinux Kernelとprocdのコンソール取得方法の差による問題は、procdにおいてbootargs内に複数の console= パラメータを検出した場合に、特定のコンソールデバイス (/dev/ttyS<n>) の代わりにLinux Kernelが設定済みの /dev/console を使用するように変更することで対処した。
また、OpenWrtのコンソールとして登録する点については、procdがコンソールを探すのに使用する /etc/inittab の内容をブート時に毎回チェックし、OpenWrtがブートされているデバイスがWAB-I1750-PSで、なおかつ ttyATH1::askfirst が存在する場合は何もせずスキップし、存在しない場合はエントリを追加するスクリプトを追加することで対処した。

なお、一部システムメッセージが "SERIAL" 側に出力されないのは、前述の通りprocdが /dev/console（/dev/ttyS0（"SERVICE" ポート側） が割り当てられたもの） を出力先として使用していることが理由。これについては複数のコンソールに出力できない関係上、U-Bootの出力先である "SERVICE" 側をOpenWrtでも一貫してメインのコンソールとして設定した。
また、U-Bootが "SERIAL" 側で出力されない点については、そもそもU-Bootが "SERIAL" ポートへの出力を想定せず、セットアップも行っていないことが原因なので、どうしようもない。U-Bootを操作したい場合は "SERVICE" ポートを使用する。

ELECOM WAB-S600-PS, WAB-S1167-PS, WAB-I1750-PS

OpenWrt/ath79

WAB-S600-PS, WAB-S1167-PS, WAB-I1750-PS内部

3年半くらい前に某氏がWAB-I1750-PSの作業を始め、当方では興味があったので少し弄って放置していました。
が、最近割引セールでWAB-I1750-PSが話題になったことに伴い、せっかくだからとWAB-S600-PSとWAB-S1167-PSも確保して1750とコードを共有させる形で組み立て直して投げ込み、マージされました。

まとめていきます。

仕様

基本的に3機種ともハードウェアはかなり似通っており、特に600と1167は同一と思われ、ソフトウェア面での差のみと推測されます。
法律の関係上、無線機能の使用は非推奨です。

  • WAB-S600-PS

    • SoC: Qualcomm Atheros QCA9557
    • RAM: DDR2 128 MiB (Winbond W9751G6KB251 x2)
    • Flash: SPI-NOR 16 MiB (Macronix MX25L12835FMI-10G)
    • Ethernet: 1000Mbps x2
    • USB: USB 2.0 Type-A x1
    • UART: "SERVICE" または内部ピンヘッダ, 所謂Ciscoケーブルは非互換

  • WAB-S1167-PS

    • SoC: Qualcomm Atheros QCA9557
    • RAM: DDR2 128 MiB (Winbond W9751G6KB251 x2)
    • Flash: SPI-NOR 16 MiB (Macronix MX25L12835FMI-10G)
    • Ethernet: 1000Mbps x2
    • USB: USB 2.0 Type-A x1
    • UART: "SERVICE" または内部ピンヘッダ, 所謂Ciscoケーブルは非互換

  • WAB-I1750-PS

    • SoC: Qualcomm Atheros QCA9558
    • RAM: DDR2 128 MiB (Winbond W9751G6KB251 x2)
    • Flash: SPI-NOR 16 MiB (Macronix MX25L12835FMI-10G)
    • Ethernet: 1000Mbps x2
    • USB: USB 2.0 Type-A x1
    • UART:
      • "SERVICE" または内部ピンヘッダ: 所謂Ciscoケーブルは非互換
      • "SERIAL": OpenWrtでは未サポート

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

OpenWrt化

  1. WABをブートしWebUIにアクセス

    ACアダプタまたはDHCPの無いPoEに接続してデバイスをブートし、192.168.3.x に設定したPCを "PSE" ポート側に接続して http://192.168.3.1 にアクセスする

  2. factory.binイメージでアップデートを実行

    ファームウェア更新ページを開き、OpenWrtのsquashfs-factory.binイメージを選択してアップデートを実行する

  3. 完了

    Flashに書き込み後再起動され、OpenWrtでブートしてくれば完了

備考

  • イーサネットポート2つはデフォルトでブリッジされ、DHCPで 192.168.1.0/24 のアドレスが配布される状態となっている。
    DHCPが他から配布される上流ネットワークに接続する場合、OpenWrtのLANインターフェースを静的アドレスからDHCPクライアントに変更するなどの設定を行う。

  • "SERVICE" ポートは内部ピンヘッダと同じ入出力が行える、SoCのプライマリかつデバッグ用シリアルポートである一方で、RJ-45ジャックであるものの電圧と配列が特殊であり、所謂Ciscoケーブルとは互換性は無い。

  • "SERIAL" ポートはSoCの持つセカンダリのシリアルポート。このポートは "SERVICE" ポートのシリアルポートとは別の仕組みであり、WAB 3機種のサポート時点ではLinux KernelやOpenWrtでのサポートが無い為、OpenWrt環境下では利用できない。
    なお、今後サポートされたとしても、U-Bootの出力先が "SERVICE" 側である関係上、U-BootとLinux Kernel (OpenWrt) で一貫させる為に "SERIAL" 側にLinux Kernelのdmesgを出力させるようにはしない。
    （メインのコンソール入出力ポート以外にdmesg出力のみ（入力無し）を他のポートに割り当てることはLinux Kernelの機能によって可能であるものの、出力だけの為に "SERIAL" ポートを占有するのもどうかと思うのでやらない）

作業時の色々

  • 今回のWABシリーズ3機種のファームウェアは、先行してサポートされているI-O DATA WN-AC733GR3やWN-AC1167GRと同じファームエア形式を採用しており、OpenWrt側に生成コードが既に存在していることから、WAB用のWebUIから投入できるfactoryイメージの生成も問題無く行えた。

  • 基板自体は3機種とも同一であり、無線の差異によってSoCや5GHz帯用無線チップ、アンテナ回路の実装がわずかに異なる程度だった。

  • 基本的には以前自分が弄ったコードと某氏が作業したコードをすり合わせ、当時のOpenWrtにおける実装方法から変更されたものは今現在の形に書き換えるなどの変更を行った。

色々

前述の通りWAB-I1750-PSは3年半ぶりとなるので、当時の記憶を思い出しつつの作業となった。
最終的に "SERIAL" ポートは少々気になるものの、マージされたので一安心。"SERIAL" については気が向いたら少し弄ってみるかもしれない。

今回は筐体を開けて内部のUARTピンヘッダを利用したものの、毎回開けるのは面倒なので、 "SERVICE" ポートをRJ-45から2.54mm間隔のピンヘッダに変換する基板を製造予定。

アパート契約とその回線開通あれこれ

アパート

これは mstdn.maud.io Advent Calendar 2023 11日目の記事です。

引っ越して日が浅く、未だバタバタしていて記事書くのも忘れかけ、既に当日22時過ぎ。なんとか思い出して時間も多少取れたので、書いていきます。

今年はアパートのネット回線開通までのあれこれです。

発端

まずもって、元々実家でまともに出歩くことなく過ごしていたものの、突如として一人暮らしを思い立ち、思い立ったが吉日とばかりに行動を起こしてアパートに移った。

  1. 10月上旬頃、運動不足などを実感するようになる
  2. 買い物などで出歩くことで運動不足を解消しようと考える
  3. しかしそもそもとして、吉川南東部の実家周辺に出掛けるような場所がほとんど無い
    • 飲食店もコンビニもスーパーも徒歩圏内に無い
      • 蕎麦屋はあるけどアレルギーの関係上きびしい
  4. ... 実家出てアパート暮らししよう （やや思考が飛躍）

アパート契約の流れ

回線だけ気になる人は飛ばしてください

  1. 10月第1週, 物件の検索と絞り込み

    • 新松戸と新八柱の2件くらいまで絞った
    • 仲介に回線設備に関しての問い合わせを投げて、2件のうち片方はすぐ帰って来たけどもう片方は無反応

  2. 10月第2周, 新松戸の物件の内覧予約

  3. 10月第3週, 新松戸の物件の内覧, 申込

    • カーテンのサイズ確認や、既にある棚などの為の寸法確認など
    • 当時使っていたリュックがいい加減ボロボロで、午後の内覧までに急遽新しいものを確保した

  4. 10月第4週, 諸費用支払いと諸契約

    • 保証会社や大家の審査が通ったので、週初めくらいからインフラや保険類の契約を実施。
      • 水道に関しては下水道絡みが不明だったので、一旦保留にして仲介に確認してから電話で申し込み。引越れんらく帳に対応している千葉県営水道ではなく非対応の松戸市営水道の管轄。
    • 契約金が約20万程度になり、それを銀行振込で支払う必要が生じたものの、口座における問題が発生してしまい、かなり焦った
      • 利用しているゆうちょ銀行において、これまで高額な振込の経験が無かったこともあり一日の送金限度額が初期設定の5万であった。
        契約金の20万は大きく超過することから慌ててネットサービスの登録と限度額の引き上げを行ったものの、10月末近くの期限に間に合うかわからず、かなりヒヤヒヤした...
      • 知見: 高額な振込をする際は予め送金限度額を確認する
    • NTTの契約も開始したが、かなり面倒な状況に陥ってしまい、中々進展しなかった。詳細は後述。

  5. 10月第5週, 鍵受け取りや持ち込む物準備

    • アパートの契約は11月1日からであったものの、仲介の休業日の関係上前日に鍵受け取り。
    • とにもかくにもDKと洋室和室の3部屋の照明を設置する必要があり、DKと和室はコストダウン目的でアイリスオーヤマの昼白色/電球色それぞれのLEDシーリングを調達。

  6. 11月, ほぼ1か月使って荷物輸送や住環境整備

    • PCやルータ等、とにかく自分で運んでしまいたかったこともあり、両親の車をそれぞれ借りたりしつつ運び込んだ。
    • 月の半ばにようやくネット回線が開通した為、その辺りでLAN構築等を進めた。

  7. 12月第1週, 引越

    • 12月に入り、ようやく最後の荷物と家具の為に業者を入れて引越実施。
      • ヤマト運輸の引越しサービスを利用した。ニトリのデスク（ブリザ12070 引出付き MBR）は予め解体したことで、島忠の本棚（スライド書棚　プラス　８０Ｍ　ＮＡ（ナチュラル））とその中身の本（コーナン100サイズ段ボール箱 x7）などと併せて、1m x 1m x 1.7mのボックスに載せきれた。

ネット回線開通とPC類移設

  1. 10月第4週, 利用意向登録と電話取り逃しと繋がらない

    • NTT東フレッツ光のサイトで確認したところ、アパートの結果が "要状況確認" であり、利用意向登録からの開始だった。
      • しかしこれが地獄の入り口である
      • 物件が戸内まで光配線方式であることは仲介に確認済みで、自分自身での目視でも既に確認していた。
      • 利用意向登録後数日してNTTから電話が掛かって来たもののタイミングが悪くて出られず。
        • その直後メール経由で折り返すよう指示があったので電話したものの繋がらず、翌日以降も1日2回以上間を置いて掛けるも全く繋がらない
        • 中央の窓口に掛けて再度向こうから電話を掛けてもらうよう依頼したものの、それも運悪く出られないタイミングで取り逃し、そのまま一度も繋がることなくフェードアウト

  2. 11月第2周, NTTの中央窓口から回線申込

    • いい加減繋がらない電話に業を煮やし、NTTの中央窓口 (0120-116-116)から新規の申込を実施。
      • 連絡システム経由で本人確認書類の送信を指示された為、免許証の写真を撮ってアップロード
      • 当日夕方近くに電話あったものの、これもタイミング悪く取り逃し
        • また地獄かとかなり不安になる
      • 翌日17時近くに電話があり、回線申込が完了する
        • 第3週半ばにONUが届き、翌日開通ということで、ようやく諸々の目途が立つ
        • 興味があった為、小型ONUを送ってもらえるか確認したところ、すぐに可という回答がありすんなり依頼できた
      • 2日で片付いてしまい、利用意向登録から電話繋がらず地獄だったのは一体何だったのか
        • 知見: 物件内に光コンセントが有るのにNTTサイトで要状況確認になる場合、電話で問い合わせた方が早いこともある
    • フレッツ回線の目途が立ったので、ISPを選定しBIGLOBEを申込

  3. 11月第3週, ONU着弾と開通

    • 小型ONUが着弾し、予定していたPanasonic Switch-M24eG PN28240Kに装着して正常動作を確認した。感無量である
      • なおSwitch-M16eGはSFPの関係上メーカーファームウェアでの運用。VLAN等は実家にて構成済
      • ルータにはFortinet FortiGate 50EをOpenWrt導入したうえで割り当て

  4. 11月第4週, サーバ用レンジラック持込, ネットワーク設定

    • 実家にてビルド鯖や大破鯖（WebやMastodonなどホストしているメインの鯖）を積載しているレンジラックを解体して持ち込み、組み立てた
      • ビルド鯖も一緒に箱詰めして持ち込んだ
    • 週末にFortiGate 50Eにて鯖類用の転送やフィルタ設定を実施

  5. 11月第5週, メイン機用メタルラック持込, メイン機とサブ機, 大破鯖持込

    • 週初めにメイン機とサブ機を積載しているメタルラックを解体し、PCに先んじてアパートに持ち込んで組み立てた
    • 週の半ばにメイン機と大破鯖を箱詰めしてアパートに持ち込み、メイン機はラック上で最低限使える状態に、大破鯖は外部疎通まで構築
      • Proxmox VEのホスト側設定（固定ローカルIPやDNS設定その他）を探すのに手間取り、予定を大幅に超過してようやく外部疎通を実現できた
        • 実家とは異なるセグメント (192.168.1.0/24 → 192.168.50.0/24)にしたことが大体の原因ではある

  6. 12月第1週, サブ機持込

    • 仕事に使用する関係上最後まで動かせなかったサブ機を、ようやく撤去して箱詰めの上アパートに持ち込み、月曜からは少なくとも作業できるようにメイン機同様最低限のみ構成。

  7. 12月第2周, メイン機とサブ機をデスクに配置

    • 週末にデスクが業者によって運び込まれたので、急いでメイン機とサブ機のモニタを設置し直したり配線取り廻したりして実家と同じ状態に構築。

色々終えて

正直ダラダラと時間掛かりすぎた感はある。最初に引越し日時決めておけばよかったかもしれない。

ひとまず、PCや鯖、ネットワーク関係は生活が落ち着くまでIPv6切ってIPv4 PPPoEのみで運用中。そのうち余裕ができたらIPoEとかも手を出す予定。

mstdn.maud.io Advent Calendar 2023、明日12日は omasanori さんです。

Fortinet FortiGate 30E

OpenWrt/mvebu

FortiGate 30E内部

FortiGate 50Eを見付けた後、ならば他のFortiGateにもMarvell SoCを搭載している機種が無いかと探して見つけ、悩んだ末に確保してサポートを行いマージされました。

まとめていきます。

仕様

既にサポート済のFortiGate 50Eと同様に、ほとんどの機種でFortiSOCまたはIntel CPUを搭載するFortiGateの中ではかなり珍しく、Marvellの汎用SoCである88F6820を搭載。 差別化の為か、SoCやRAM、ネットワーク周りでいくらか50Eから削られた仕様となっています。

  • SoC: Marvell Armada 385 88F6820
  • RAM: DDR3 1024MiB (MT41K256M8DA-125 x4)
  • Flash: SPI-NOR 128MiB (MX66L1G45GMI-10G)
  • WAN/LAN: 1000Mbps x1/1000Mbps x4
  • USB: USB 3.0 Type-A x1
  • UART: "CONSOLE", 所謂Ciscoケーブル互換

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

OpenWrt化

ブートローダが主に復旧用としてファームウェア投入機能を持つ為、それを使用してinitramfsイメージを踏み台とする なお、 "FG-30E" と称する

  1. FG-30Eのブートメニューを表示させる

    電源を接続しブートする途中、 Please wait for OS to boot, or press any key to display configuration menu と表示されたタイミングで適当なキーを押下し、ブートメニューに入る

  2. コンソールポートのbaudrateを9600bpsに設定

    ブートメニュー上で [I]: System information. から [S]: Set serial port baudrate. を呼び出し、baudrateを9600に設定する

  3. TFTPサーバを用意

    ブートメニュー上で [R]: Review TFTP parameters. を呼び出してTFTP関連の情報を表示し、それに従ってTFTPサーバを用意する
    なお、PCはTFTP関連情報内で示されているポートに接続する
    また、OpenWrtのinitramfsイメージは image.out にリネームの上TFTPフォルダに配置する

  4. TFTPでinitramfsイメージをダウンロード

    ブートメニュー上で [T]: Initiate TFTP firmware transfer. を呼び出してTFTPを実行し、initramfsイメージをサーバからダウンロードする

  5. initramfsイメージを実行

    TFTPサーバからのダウンロードが完了後、 Save as Default firmware/Backup firmware/Run image without saving:[D/B/R]? と表示されたら R キーを押下し、Flashには書き込まずブートする

  6. メーカーファームウェアをバックアップ

    もし将来的にメーカーファームウェアに書き戻す可能性がある場合など、必要であればメーカーファームウェアをバックアップする
    dd を用い、 /proc/mtd を確認の上

    を最低限取り出し、scp等でPCに転送し保管する

    例）

     root@OpenWrt:/# mkdir /tmp/mtd
 root@OpenWrt:/# cd /tmp/mtd
 root@OpenWrt:/tmp/mtd# cat /proc/mtd
 dev:    size   erasesize  name
 mtd0: 001c0000 00010000 "u-boot"
 mtd1: 00010000 00010000 "firmware-info"
 mtd2: 00010000 00010000 "dtb"
 mtd3: 00010000 00010000 "u-boot-env"
 mtd4: 00010000 00010000 "board-info"
 mtd5: 00600000 00010000 "kernel"
 mtd6: 01800000 00010000 "rootfs"
 mtd7: 00600000 00010000 "kn2"
 mtd8: 01800000 00010000 "rfs2"
 mtd9: 01200000 00010000 "part1"
 mtd10: 01200000 00010000 "part2"
 mtd11: 01e00000 00010000 "config"
 root@OpenWrt:/tmp/mtd# dd if=/dev/mtdblock1 of=mtd1_firmware-info.bin
 128+0 records in
 128+0 records out
 root@OpenWrt:/tmp/mtd# dd if=/dev/mtdblock5 of=mtd5_kernel.bin
 12288+0 records in
 12288+0 records out
 root@OpenWrt:/tmp/mtd# dd if=/dev/mtdblock6 of=mtd6_rootfs.bin
 49152+0 records in
 49152+0 records out

    バックアップをデバイスに書き戻す際は、 mtd コマンドを用いて書き込む

     mtd write <backup image> <target partition>

    例）

     mtd write mtd1_firmware-info.bin firmware-info
 mtd verify mtd1_firmware-info.bin firmware-info    # 書き込まれたデータが元データと一致するか検証
  7. OpenWrt上でsysupgradeを実行

    scpなどを用いてsysupgradeイメージをデバイス上にアップロード（またはダウンロード）し、sysupgradeを実行する

  8. 完了

    Flashへの書き込みが完了後再起動され、OpenWrtで起動する
    この時メーカーファームウェアで起動してしまう場合は、ブートメニューに入った上で [B]: Boot with backup firmware and set as default. を呼び出し、デフォルトのOSイメージをOpenWrtを書き込んだ1番目の方に切り替える

備考

  • SoC自体はFortiGate 50Eと同じ88F6820ながら、動作クロックは50Eの1.60GHzに対して30Eでは1.33GHzに落とされている。

  • 今回のサポートにおいて、CONSOLEポートのbaudrateはFortiGateで広くデフォルトとして使用されている9600bpsを前提としている。
    その他の値に設定されていた場合、Linux Kernelのdmesgが出力されないなどのトラブルが起きる為注意する。

  • WAN1, WAN2ポートはデフォルトでブリッジを構成している為、上流が1系統である場合はどちらに接続しても問題無い。
    ただし、それぞれで別系統のWANを利用する場合、ブリッジを解除しそれぞれにOpenWrtの仮想インターフェースを割り当て直す。

  • OpenWrtのサポートにおいては、Flash内に2組存在するOSイメージ領域のうち1つ目の最小限を利用するよう構成しており、もう片方のメーカーファームウェアに対しての影響は恐らく無いと思われる。
    この為、ブートメニューにおいて [B]: Boot with backup firmware ~ を選択することで、必要に応じてOpenWrtとメーカーファームウェアを切り替えてブートできる。

  • 中古などで入手する場合、本機種のDCジャックは特殊であり通常の丸形プラグを持つACアダプタを使用できない為、基本的にはACアダプタが付属するものの選択を推奨。
    なお、嵌合するプラグはMolex 5557-02Rであり、自作することは可能（例）。

作業時の色々

  • 基本的には一部を除いてFortiGate 50Eと共通のハードウェアであり、それ故にDeviceTreeなどのコードを仕立てるのは比較的容易であった。
    しかしながら何故かLANからWANへのNATが不安定となる症状を長らく起こしており、SoCのEthernetとSwitch (88E6176) 間の接続に起因すると思われたものの、しばらく解決できずサポートの投げ込みを保留していた。
    最近になってLinux Kernelにおいていくつか88E6xxxのDSAサポートにおける修正が入っており、試したところほぼ解決していた為、サポートを投げ込んだ。

  • 前述の通りハードウェアはFortiGate 50Eと大半が共通であり、それ故に使用されている基板も50Eと同一であった。

色々

今回の機種もFortiGate 50Eと同様に、日本国内におけるOpenWrt目的としては貴重な有線機。
50Eには及ばないながらも大容量のRAMを搭載し、USB 3.0ポートも搭載することから様々な用途に活用できると思われる。

ただ、ヤフオク等で50Eが安価に数が出ている為、敢えて30Eを選ぶ意義は薄いところではある。

WSR-2533DHP2のOpenWrtにおける最近の変更について

OpenWrt/mediatek

WSR-3200AX4Sのサポートを追加するにあたって、WSR-2533DHP2に一定の変更を加えました。そのうち1つに過去のWSR-2533DHP2用OpenWrtファームウェアとの互換性を失わせる必要があるものが存在している為、それについて書いておきます。

発端

WSR-3200AX4Sのサポートの追加に際して、当該機種はWSR-2533DHP2とLEDやボタン類のGPIOピン、イーサネット構成その他である程度ハードウェア構成が共通となっており、ハードウェア仕様を記述しLinux Kernelがセットアップを行う為の仕様書となるDeviceTreeソース (dts) は共通部分を統合するなど、ある程度サポート用のコードをWSR-2533DHP2と共通化する必要が生じた。

その中で、WSR-3200AX4Sのサポートの為に絶対に必須というわけでは無いものも含めてWSR-2533DHP2のサポートの改善を先に行うこととした。

経緯

まずOpenWrtの上流に位置するLinux Kernelにおいて変更された、DeviceTreeでの各デバイスにおける記述方法に従っての変更と、MT7622では実際には存在しない仕様に関連するコードの削除等を行った。

その後、最近のmediatek targetに限らずNAND搭載機で時々問題になっている、kernelサイズの肥大化問題についてWSR-2533DHP2で確認したところ、然程時間を置かずに直面する可能性が高かったことから、対処することとした。

  • kernel肥大化問題

    OpenWrtにおいてはレガシーKernelの保守に要するコストなどの関係上、基本的にはLinux KernelのLTSバージョンを使用し、メジャーリリース毎に次のLTSバージョンへ切り替えていく運用をしている。

    • OpenWrt 21.02: Linux Kernel 5.4
    • OpenWrt 22.03: Linux Kernel 5.10
    • OpenWrt 23.05: Linux Kernel 5.15
    • OpenWrt ??.??（次期メジャーリリース）: Linux Kernel 6.1（予定）

    この関係上、Linux Kernelのメジャーバージョンが上がっていくに連れて、機能の追加や改善等に関連してコード量が増え、OpenWrtファームウェアのkernelバイナリも少しずつ肥大化していく。その為、過去には妥当であったKernel用mtdパーティションのサイズが最近のkernelにおいてはギリギリ、または完全に不足することが度々起きる結果となっている。

    これに対処する際、単純にKernel用パーティションのサイズを変更して増やし、RootFSが格納されるパーティションの始点とサイズを変更するだけでは、OpenWrtのsysupgradeの仕様上、変更前のファームウェアからの更新時に正しく取り扱うことができない。その結果、sysupgradeに失敗して不完全な状態で書き込まれ再起動されてしまいbootloopに陥るなどの状況が発生する。
    その対処として、Kernel/UBI用パーティションの変更後のファームウェアが使用された場合にsysupgradeが禁止されるよう構成する必要が生じる。

    なお、以前まではKernel用パーティションのサイズとして4MiBが一般的に使用されていたが、最近は6MiBが使用されるようになっている。

対処

さて、WSR-2533DHP2においても既にkernelサイズの肥大化が進行し、4MiBの上限に対して既に心許ない残量となっていたことから、Kernel用パーティションの拡大を行った上で、過去バージョンとの互換性を失わせる対処を行った。

  • 変更内容

    • WSR-2533DHP2において、Kernel用パーティションを4MiBから6MiBに拡大し、rootfs+ユーザーデータのUBIパーティションを2MiB分縮小
    • 互換バージョン設定を追加し、過去バージョンとのsysupgrade禁止とその際に表示されるメッセージを追加

  • 影響

    • OpenWrt 23.05シリーズはこの変更の影響を受けず、過去のリリースから問題無く23.05シリーズへsysupgradeすることが可能
    • snapshotにおいてはこの変更前のファームウェアから変更後のOpenWrtファームウェアにsysupgradeすることはできず、エラーとなる
    • OpenWrt 23.05シリーズの次のメジャーリリースからはこの変更が含まれるため、OpenWrt 23.05シリーズまたはその前のリリースから次期メジャーリリース（23.05.xではない）へsysupgradeはできなくなる

  • 今回の変更後のファームウェアへの更新

    sysupgrade.binイメージは使用できない為、代わりにfactory-uboot.binイメージを使用し、sysupgradeに -F オプションを付けて強制的に実行し、firmwareパーティション全体を書き換える。sysupgrade.binを使用しないよう、十分注意する。

BUFFALO WSR-3200AX4S

OpenWrt/mediatek

WSR-3200AX4S内部

某氏より提供頂き、とある事情から遅れに遅れたものの、ようやく投げてマージされました。

まとめていきます。

仕様

全体的には既にサポートされているWSR-2533DHP2と近く、一部のみ変更した形の11ax (Wi-Fi 6)対応機です。

法律の関係上、無線機能の仕様は非推奨です。

  • SoC: MediaTek MT7622B (aarch64)
  • RAM: DDR3 512MiB
  • Flash: SPI-NAND 128MiB (W25N01GVZEIG)
  • WAN/LAN: 1000Mbps x1/1000Mbps x4
  • UART: J4, 115200bps（三角マークから3.3V, GND, TX, RX）

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

OpenWrt化

WSR-2533DHP2同様にfactoryイメージを生成できている為、直接投入することが可能です。

  1. WSR-3200AX4を起動 なお、ルータモードに設定されていることを前提とする
  2. http://192.168.11.1/ にアクセスし、ファームウェア更新ページに移動
  3. OpenWrtのfactory.binイメージを選択し、更新実行ボタンを押下
  4. Flashに書き込み後再起動され、OpenWrtが起動して完了

備考

  • WSR-2533DHP2と同様に、Flash内にOSイメージを2つ抱える構成となっている。それらの使用方法も変わらず原則として1つ目が使用される仕様であり、OpenWrtでもその様に扱う。

  • WSR-3200AX4Sのサポートに際して必要が生じていたことから、WSR-2533DHP2に過去のファームウェアとの互換性を失わせる必要がある変更を行った。
    これについては別記事において詳細を記述する。

  • WSR-2533DHP2と異なり、badblockなどNAND特有の仕様の為や他の特定のパーティションの為にある程度の領域が割かれていることから、OpenWrt (kernel + rootfs + data) で使用できる領域はWSR-2533DHP2での 0x3a00000 (58MiB) に対して 0x1800000 (24MiB) と半分以下になっている。
    当然ながらユーザーがパッケージのインストール等に使用できる領域も小さい。

作業時の色々

  • WSR-2533DHP2と異なり、WSR-3200AX4Sにおいては無線用の補正用データ内に機種固有のMACアドレスが格納されていない。その為、無線LANの各アダプタに適切なBSSIDが割り当てられない。
    サポートを投げるにあたって問題となっていたのがこの点であり、過去にELECOM機を投げた際渋られた経緯があることから、長期間保留としていた。
    しかしながら結局のところ現状ではこれを解決する適当な手段が無く、仕方ないのでコミットメッセージ内に注意書きを載せて投げ込み、今回マージされるに至った。

  • WSR-3200AX4Sは仕様で書いた通りWSR-2533DHP2にかなり近いハードウェア構成となっており、それ故にまずWSR-2533DHP2のサポートの改善をいくつか行った。
    具体的にはOpenWrtの上流であるLinux Kernelで変更されたDeviceTree仕様に従うもののほか、MT7622には実際には存在しない仕様の為のコードの削除など。

  • スイッチICとしてRTL8367Sを搭載しているWSR-2533DHP2と異なり、WSR-3200AX4SではMT7531が搭載されている。

色々

1つ前のWN-DEAX1800GR同様年単位で時間を要してしまったものの、マージされて一安心。

残念ながらWSR-2533DHP2と比べてOpenWrt用として使用できる領域は小さいものの、MT7622搭載機としての選択肢は増えた。

I-O DATA WN-DEAX1800GR

OpenWrt/ramips

WN-DEAX1800GR内部

とある方より提供頂いたものの、ソフトウェア面で若干難がある仕様であること、内部ファームウェアの取り扱いで多少手を加えようとしたことなどから長らく保留になっていましたが、投げ込んでマージされました。

マージされてからだいぶ遅い記事ですが、まとめていきます。

仕様

基本的にはサポート済のWN-DX1167R等と同様にMT7621とNANDを組み合わせた無線機であるものの、MT7915Dを搭載して11ax (Wi-Fi 6)に対応した比較的新しい世代の機種です。
どちらかというとAP寄りの使用を想定した機種であるのか、有線ポートは計3ポートに絞られています。

なお、法律の関係上無線機能の使用は非推奨です。

  • SoC: MediaTek MT7621A
  • RAM: DDR3 256MiB (NT5CC128M16JR-EK)
  • Flash: RAW-NAND 128MiB (W29N01HVSINF)
  • WAN/LAN: 1000Mbps x1/1000Mbps x2
  • UART: J2, 115200bps（"1" のシルク印刷から3.3V, GND, TX, RX）

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

OpenWrt化

これもWN-DX1167R等と同様に、2段階での導入が必要です。

  1. WN-DEAX1800GRをブート
  2. http://192.168.0.1/ にアクセスし、ファームウェアの更新ページへ移動
  3. OpenWrtのinitramfs-factory.binイメージを選択して更新ボタンを押下し、ファームウェアの更新を実施
  4. 更新が完了後再起動されるので、OpenWrtで起動したらsysupgrade.binイメージをscp等を用いてデバイス上に転送し、sysupgradeを実施
  5. Flashへの書き込みが完了後再起動され完了

備考

  • WN-DX1167RほかMSTCによって製造されたサポート済機種と同様に、この機種もFlash内に2つのOSイメージ用領域を抱えており、ファームウェア更新毎に切り替わる仕様となっている。
    OpenWrtにおいては1つ目の領域のみを使用する。

  • この機種ではU-Bootの環境変数領域に問題を抱えており、U-Bootのコマンドライン上でsaveenvを使用した場合環境変数領域が吹き飛ばされる問題が存在する為、絶対に使用しない。
    もし誤って使用した場合、MACアドレスやパスワード、SSIDなど個体固有の情報が全て消失する。

作業時の色々

  • 冒頭で触れた通り、Flash内部に抱える2つのファームウェアをどちらも扱えるようにしようとドライバを書くなどしており、他機種との兼ね合いもあったことからズルズルとWN-DEAX1800GRの作業も遅れていってしまった。
    最終的には結局面倒になってしまい、既にサポート済のWN-DX1167R等と同じく1つ目のファームウェアのみ扱う仕様とすることで決着とした。

  • 上記の仕様で触れた通りMT7915Dを使用して11axに対応しているが、MT7621AのPCIe 1本では帯域が足りず、もう1本を合わせて計2本を使用することで帯域を確保している。
    この為、MT7621AのPCIeの片方ではMT7915のPCI IDが返ってくるが、もう片方ではHIFと呼ばれる仮想的なインターフェースとしてのIDが返ってくる。

  • 既にサポートされているWN-DX1167R等と同じくMSTCの製造であるものの、メーカーファームウェアのWebUIが受け付けるファームウェア形式は少し異なるものが採用されていた。
    この為、既存の生成コードが利用できず、WN-DEAX1800GR用に新たに追加する羽目になった。

色々

提供頂いてから2年程経過した末に、当初企図していた全てとはならなかったものの、ようやくマージまで到達することができた。

有線は3ポート止まりであるものの、他の無線機と比較するとわずかに筐体がコンパクトである為、選択肢としては有りかもしれない。