maezawa.toshihiko
2025年6月3日 18時42分
==========
製品型番：AGX4500-U03Z
Debian/ABOSバージョン：3.20.3-at.3
カーネルバージョン：5.10.226-0-at
3G/LTE モジュール情報 (Debianのみ)：
その他：firmwareのバージョン情報 2.2.0
==========
UDP通信を行うアプリケーションコンテナへの通信ポートが変わってしまう症状が出ており困っております。
add_ports 50000:50000/udp
.conf にて上記設定をしているアプリコンテナがあります。
アプリコンテナは Debian GNU/Linux 12 (bookworm) 上で node.js v22.11.0＋UDP通信アプリケーション という構成です。
この構成で、UDP通信アプリケーションが何かしらの理由で再起動したとき（例えばnodeプログラム内部で process.exit() したとき）、コンテナアプリ再起動（自動的な再起動）後にUDP通信ができなくなる場合があります。
UDP通信アプリケーションがオープンしたUDP socketをcloseしないままprocess.exit()した場合にこの症状になるようなのですが、再起動後のアプリケーションでUDP socketのオープン処理は正常にできております。
現象発生時、本来はarmadilloの50000ポートとコンテナ内部の50000ポートを結びつけるところ、どうもarmadillo本体にて上記のマッピングポートとは別のポートが割り当てられ、その別ポートでの通信に置き換わってしまっているようです。
正常時
armadillo:50000 => container:50000
現象発生時（一例）
armadillo:50000 NG （unreachable)
armadillo:60640 => container:50000（データ到達）
なぜこのような現象になるのか？またこの状態からの回復手段をお教えください。
コメント
at_reika.yamazaki
お世話になっております。山崎です。
2点確認です。
1点目、症状発生時に Armadillo にログインすることは可能でしょうか？
問題がないときは「podman ps -a 」を実行したときにコンテナのステータスのうち、PORTS が 「0.0.0.0:50000->50000/udp」 と表示されていると思います。症状発生時も表示内容は変わらないでしょうか。
コマンドの実行結果をいただけますと幸いです。
2点目、ABOS のバージョンが古いようですが最新の ABOS でも同様の症状は発生するでしょうか？
可能であれば、ABOS をアップデートしても発生するかご確認いただけますと幸いです。
以上、ひとまずのお返事になります。
どうぞよろしくお願いいたします。
maezawa.toshihiko
症状発生時にarmadilloにアクセスし、各種情報を取得しました。
何かわかる点はありますでしょうか。
podman ps -a
50000ポートのマッピングは残っている
/home/atmark # podman ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES bd3b5657c66a localhost/remocon_base:v1.0.0 /var/app/rollback... 33 minutes ago Up 2 minutes 0.0.0.0:34354->34354/udp, 0.0.0.0:50000->50000/udp, 0.0.0.0:50010->50010/udp RemoConSubunit a16231aeb8d5 localhost/remocon_base:v1.0.0 /var/app/rollback... 33 minutes ago Up 8 minutes joind 6a106aa5188a localhost/remocon_base:v1.0.0 /var/app/rollback... 33 minutes ago Up 33 minutes 0.0.0.0:3000->3000/tcp jrcrmtctl /home/atmark #
armadillo本体でnetstat
/home/atmark # netstat -au Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0 0.0.0.0:34354 0.0.0.0:* udp 0 0 0.0.0.0:58100 0.0.0.0:* udp 0 0 0.0.0.0:50000 0.0.0.0:* udp 0 0 0.0.0.0:50010 0.0.0.0:* udp 0 0 0.0.0.0:46952 0.0.0.0:* udp 0 0 0.0.0.0:35876 0.0.0.0:* udp 0 0 localhost:domain 0.0.0.0:* udp 0 0 192.168.62.50:bootpc 192.168.62.1:bootps ESTABLISHED udp 0 0 10.88.0.1:153 0.0.0.0:* udp 0 0 0.0.0.0:mdns 0.0.0.0:* udp 0 0 0.0.0.0:55544 0.0.0.0:* udp 0 0 0.0.0.0:57718 0.0.0.0:* udp 0 0 0.0.0.0:mdns 0.0.0.0:* udp 0 0 :::47662 :::* udp 0 0 localhost:domain :::* udp 0 0 :::mdns :::*
container内部でnetstat
/home/atmark # podman exec -it RemoConSubunit bash root@bd3b5657c66a:/# netstat -au Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State udp 0 0 bd3b5657c66a:34354 0.0.0.0:* udp 0 0 bd3b5657c66a:50000 0.0.0.0:*
armadilloからcontainerへ50000ポートUDP通信
armadillo外部からの50000ポートへのアクセスはできない状況下で、armadilloへloginしlocalhost：50000ポートへのUDP通信を行いました。
ダミーデータがアプリまで届き、アプリとしてNGな通信なのでエラーを出している図です。
/home/atmark # podman logs -f RemoConSubunit | grep -e LAN & /home/atmark # nc -u 127.0.0.1 50000 00000000 info: [LAN] send_lan_status_telemetory_data(): drop data from unregisted equipment (10.88.0.1). data=30303030303030300a ^Cpunt!
at_reika.yamazaki
maezawa.toshihiko
山崎様
頂いた情報をもとにIPアドレスを固定化することで、コンテナ再起動後の通信が問題なく行われるようになりました。
ありがとうございます。
今回、IPアドレス割り当てを固定化する手法をお教えいただきましたが、この他に、ファイルの更新を伴わない方法で通信不可現象を解消させる手立てはございませんでしょうか。
armadilloを稼働場所が遠隔地でかつ通信回線が細くソフトウェアの入れ替えが難しい環境がございます。
そのような環境にて先の通信不可現象が発生した場合の回復手段があれば知っておきたいのです。
例えばcontrack周りに問題があるとのことでしたが、conntrackのトラッキング情報を削除することで回復したりはしないでしょうか。
maezawa.toshihiko
さらに追加で質問させてください。
今回は特定ポートへのすべてのUDP通信が停止していましたが、複数の通信相手があるのですが、コンテナ再起動後に通信が可能な相手と不可能な相手が出てしまう現象も発生しております。
今回のconntrackに関係する問題で、このような症状は起きますでしょうか。
全通信が止まる
✕ 192.168.1.11 → 192.168.1.10:50000
✕ 192.168.1.21 → 192.168.1.10:50000
一部の通信が止まる（一例）
◯ 192.168.1.11 → 192.168.1.10:50000
✕ 192.168.1.21 → 192.168.1.10:50000
at_reika.yamazaki
お世話になっております。山崎です。
>頂いた情報をもとにIPアドレスを固定化することで、コンテナ再起動後の通信が問題なく行われるようになりました。
解決したということで良かったです。
>そのような環境にて先の通信不可現象が発生した場合の回復手段があれば知っておきたいのです。
>
>例えばcontrack周りに問題があるとのことでしたが、conntrackのトラッキング情報を削除することで回復したりはしないでしょうか。
申し訳ありません。IP アドレスを固定する以外の対処法については現在不明な状態です。
また、弊社としては手作業ではなく、SWU イメージを用いたアップデート方法を推奨しております。
この方法はマニュアルの以下に記載があります。
■ 5.4. Armadillo のソフトウェアをアップデートする
https://manual.atmark-techno.com/armadillo-iot-g4/armadillo-iotg-g4_pro…
この SWU イメージはネットワーク経由や USB 経由で Armadillo にインストールが可能です。
■ 3.3.3.6. SWU イメージのインストール
https://armadillo.atmark-techno.com/files/downloads/armadillo-iot-g4/do…
また、追加でいただいた質問について確認です。
コンテナを再起動する前は通信が不可能な相手というのは一台も起きない、ということで相違ないでしょうか？
また、コンテナを再起動後に通信不可能な状態がおきると、以降はずっとその相手は通信不可能ということで合っているでしょうか？
以上、どうぞよろしくお願いいたします。
at_dominique.m…
よこからすみません、
マルティネです。
アップデートするのは正しいですが、問題は理解してますのでもうちょっと説明します。
まずは、この問題は不具合に見えますが、conntrack の仕組みなのでバグではありません。
modprobe nf_conntrack を実行した後に /proc/net/nf_conntrack ファイルで接続を確認できますが、
コンテナに送信すると以下の様な出力になります：
ipv4 2 udp 17 117 src=10.1.2.1 dst=10.1.2.22 sport=38120 dport=1234 src=10.88.0.5 dst=10.1.2.1 sport=1234 dport=38120 [ASSURED] mark=0 zone=0 use=2
コンテナの IP が変わると 10.88.0.5 の部分が合わなくなってカーネルが転送できなくなります。
ワークアラウンドですが、いくつかあります：
* ソースポートを 50000 ではなく別のポートを使うと別の接続として認識されますので、転送可能になります。
* 同じポートでも、120 秒以上通信を一旦やめればカーネルが接続を忘れて再び新しいコンテナに転送されます。
（5つ目の値ですね、上記の出力では 117秒。コンテナから返事なかった場合は 30 秒、返事あった場合は 120秒がタイムアウトとなります。net.netfilter.nf_conntrack_udp_timeout / net.netfilter.nf_conntrack_udp_timeout_stream の sysctl です）
よろしくお願いします
maezawa.toshihiko
いろいろな情報をありがとうございます。
base OSなどのupdateですが、本来はやりたいところ、対象機器設置場所が人が入り込めない山奥であり、また利用しているインターネット回線が細く、かつエンドユーザ様のものであり、ソフトウェアアップデートのために利用できず、ファイルサイズの大きな os updateは実施できません。
> * 同じポートでも、120 秒以上通信を一旦やめればカーネルが接続を忘れて再び新しいコンテナに転送されます。
アプリケーションの構造上、120秒間通信をしないということは実現できません。
> * ソースポートを 50000 ではなく別のポートを使うと別の接続として認識されますので、転送可能になります。
こちらでの解消か、IPアドレスを固定化するか、の二択になりますが、ひとまず実績ができたIPアドレス固定の方向で進めていきたいと思います。
サポートありがとうございました。
at_dominique.m…
マルティネです。
> base OSなどのupdateですが、本来はやりたいところ、対象機器設置場所が人が入り込めない山奥であり、また利用しているインターネット回線が細く、かつエンドユーザ様のものであり、ソフトウェアアップデートのために利用できず、ファイルサイズの大きな os updateは実施できません。
事情の説明ありがとうございます、理解しました。
OS アップデートがサイズ的に扱いづらくてすみません。
今回の問題は OS 全体のアップデートが必要なく、ファイル一つを転送すればいいだけですので、SWUの場合は標準 ~45KB ぐらいの転送になります（それでも大きいでしたら実装はしてませんが、2KBぐらいの SWU イメージまで構築できると思います）。
こちらの問題を他の方法で回避できても不具合や脆弱性は必ずでるものですので、今後にでもご検討いただければと思います。
ややこしいですが、インタネット回線がエンドユーザ様のもので、勝手にアップデートに利用できない問題はエンドユーザ様にアップデートを実行させる仕組みも可能かと思います。
よろしくお願いします
maezawa.toshihiko
2025年6月3日 18時53分
現象発生時の通信キャプチャ画像を追加します。
armadillo が 192.168.1.10、外部装置が 192.168.1.11 192.168.1.21 192.168.1.41 です。
192.168.1.10から外部装置へのUDP通信 が、通常時のポートは src:50000 dst:50000 のところ、現象発生時は src:60640 dst:50000 となっています。そして外部装置からarmadilloの50000ポートへのudp通信がunreachableになっています。
試しに外部装置から 60640ポートへudp通信したところ、コンテナ内部まで通信が届きました。