Firefox OSのスマホを、44Netの通信観測所にしてみた——Fx0とOpenWrtで作ったLooking Glass

2026年10月10日 02:30

いま、私の手元にある古いスマートフォンが、インターネット上でひっそり働いています。

端末は LG Fx0（LGL25）。搭載OSはAndroidでもiOSでもなく、かつてMozillaが開発していた Firefox OS です。

このFx0を、アマチュア無線のIPネットワーク 44Net（AMPRNet） の観測データを表示するWebサーバーとして復活させました。名前は 「JN1EEP 44Net Looking Glass」。現在の公開版は v0.4 です。

公開ページ： https://fx0.jn1eep.ampr.org/looking-glass/

「古いスマホでWebサイトを公開するだけ？」と思われるかもしれません。でも今回の面白さは、むしろその裏側にあります。

44Netに、小さな観測窓を作りたかった

私が使っている44Netのアドレス帯は `44.27.57.0/29`。そのネットワークの入口には、GL.iNet GL-MT300N-V2、通称Mango という小型ルーターを置いています。中身はOpenWrtです。

ただ、IPアドレスが使えるだけでは、その先の通信がどうなっているかはわかりません。

ゲートウェイへの応答はあるか
44Net内の観測先に通信が届いているか
DNSは応答しているか
経路はどこまで観測できるか
応答時間は時間帯によって変化するか

そこで、これらをひとつのページから眺められるようにしました。ネットワーク運用の世界でいう Looking Glass にならった、読み取り専用の観測サイトです。

Fx0に全部やらせない、という設計

全体は次のような構成です。

閲覧者のブラウザ
       │ HTTPS
       ▼
Mango / OpenWrt
  ├─ nginx（HTTPS入口・リバースプロキシ）
  ├─ ping / traceroute / DNS計測
  ├─ 履歴・経路監視（RAM上に保存）
  └─ 計測結果をJSONで配信
       │ ローカルネットワーク
       ▼
LG Fx0 / Firefox OS
  ├─ BusyBox httpd（観測画面）
  ├─ JSONを定期取得
  └─ HTML / JavaScriptで可視化

計測の中心はMangoです。Fx0は主にHTMLとJSONを配信する役割に絞っています。

これは古い端末を活用する上でも、公開サービスを安全に運用する上でも大切な分離でした。ブラウザから任意の宛先にpingやtracerouteを実行する機能は設けず、計測先はMango側のスクリプトに固定しています。

また、Fx0が元から提供していたWebサイトは8080番で維持し、Looking Glassは別の8081番で稼働させました。既存のサイトを壊さず機能を追加するためです。

一番苦労したのは「再起動すると消える」こと

Firefox OSのFx0にはBusyBoxを導入してあり、httpd でWebページを配信できました。ところが、動作中にファイルを配置しても、再起動すると作業領域の /data/local/tmp が消えてしまう、という問題に遭遇しました。

つまり、画面が表示できても、それだけでは常時運用にはならないのです。

そこで役割を分けました。

恒久保存するHTMLと起動スクリプト：/system/etc/looking-glass/
起動後に作り直す公開ディレクトリ：/data/local/tmp/looking-glass/

通常起動時に起動スクリプトがHTMLをコピーし、BusyBoxのWebサーバーを立ち上げます。JSONはMangoから一定間隔で取得します。

`/system` の更新にはTWRPを一時起動して作業しました。最後はSHA256を比較して、保存したHTMLと再起動後に配信されるHTMLが一致することまで確認しています。

なお、起動直後はWi-Fiがまだ接続されず、JSONが取得できない場合もあります。実際の確認では、接続後に再試行され、手動介入なしでデータ取得が始まりました。

v0.1からv0.4へ、少しずつ育てた

最初から全部作ったわけではありません。

$\small \def\arraystretch{1.5} \begin{array}{|l|l|} \hline \textsf{\textbf{版}} & \textsf{\textbf{追加したこと}} \\ \hline \textsf{v0.1} & \textsf{Fx0での画面公開と基本的な状態表示} \\ \hline \textsf{v0.2} & \textsf{44Net DNS、外部ICMP、tracerouteの観測} \\ \hline \textsf{v0.3} & \textsf{直近24時間のRTT履歴、応答率、DNS履歴の可視化} \\ \hline \textsf{v0.4} & \textsf{可視44Netホップの変化を比較し、イベントとして記録する仕組み} \\ \hline \end{array}$

計測は原則1分ごと。tracerouteとDNSは約10分ごと。v0.3以降の履歴はMangoのRAMに置くため、フラッシュメモリへの頻繁な書き込みを避けています。

代わりにMangoを再起動すると履歴は消えるので、長期保存用の監視システムではありません。まずは軽く、安全に観測し続けることを優先しました。

「pingが通らない＝サービス停止」ではない

今回、考え方を整理するきっかけになったのが、44Net内のDNSサーバー 44.60.44.3 です。

この観測先はICMP Echoに応答しなくても、`ampr.org` のDNS問い合わせには応答することがありました。実際、テストでは名前解決の成功を確認しています。

そのため画面でも、ICMP応答の有無とDNSサービスの応答を別々に表示しています。

「応答がない」という観測結果は事実でも、「サーバーが故障している」という結論には直結しません。これは普段のセキュリティや障害対応にも通じる話だと思います。

さらにインターネット向けの 1.1.1.1 も観測していますが、MangoではポリシールーティングによりVPN・WireGuard経由になる場合があるため、単純な「直接WANの通信品質」とは呼べません。

v0.4で「経路変化を見たつもり」を避ける

v0.4では、約10分ごとに得られるtracerouteから、公開可能な44Netホップの位置とIPアドレスを比較しています。

新しい並びを一度見ただけでは確定せず、同じ並びを2回連続で観測したときにイベントとして記録します。また、応答が消えただけの場合は安易に経路変更とは判定しません。

それでも、記録されるのはあくまで「見えているホップの変化」です。ロードバランシングやICMP制御などで見え方が変わる可能性もあり、ネットワークの実際のルーティング変更を証明するものではありません。

公開JSONでは、44Net以外の中継IPアドレスをマスクしています。観測できることと、何でも公開してよいことは別です。

なお、経路変化の検出ロジックは模擬データで確認しましたが、実際の44Net経路変更によるイベントは、この記事の執筆時点では未検証です。そこは今後の運用で確かめます。

完成させるより、観測し続ける

v0.4まで来て、Web公開、再起動後の自動復旧、DNS・ICMP・経路情報の取得、RTT履歴の表示まで動作を確認できました。

一方、次に必要なのは機能を無限に増やすことではなく、観測システム自身が止まっていないかを判定する仕組みや、外部の観測地点からの到達性確認かもしれません。

そして何より、Firefox OSの古いスマートフォンが、いまもネットワークの実験装置として働ける。そのこと自体が今回の成果です。

実装の構成や設計上の制約は、GitHub向けにも整理しました。再現手順とともに、何を確認できていて、何はまだ確認できていないのかも残していくつもりです。

対象環境：LG Fx0（Firefox OS/B2G）、GL.iNet GL-MT300N-V2（OpenWrt）、44Net（AMPRNet）。2026年10月、v0.4時点の記録。