Armadilloフォーラム

UDP通信ポートマッピングが変わる?

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(データ到達)

なぜこのような現象になるのか?またこの状態からの回復手段をお教えください。

コメント

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通信したところ、コンテナ内部まで通信が届きました。

ファイル ファイルの説明
UDP NG.jpg 現象発生時の通信キャプチャ

at_reika.yamazaki

2025年6月3日 20時35分

お世話になっております。山崎です。
2点確認です。

1点目、症状発生時に Armadillo にログインすることは可能でしょうか?
問題がないときは「podman ps -a 」を実行したときにコンテナのステータスのうち、PORTS が 「0.0.0.0:50000->50000/udp」 と表示されていると思います。症状発生時も表示内容は変わらないでしょうか。
コマンドの実行結果をいただけますと幸いです。

2点目、ABOS のバージョンが古いようですが最新の ABOS でも同様の症状は発生するでしょうか?
可能であれば、ABOS をアップデートしても発生するかご確認いただけますと幸いです。

以上、ひとまずのお返事になります。
どうぞよろしくお願いいたします。

maezawa.toshihiko

2025年6月4日 13時57分

症状発生時に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

2025年6月4日 14時54分

お世話になっております。山崎です。
こちらですが、conntrack 周りに問題があり、コンテナが再起動する度に別の IP アドレスが割り当てられるのですが、前の接続を覚えているため新しいコンテナに送らないという状況のようです。
そのため、コンテナの IP アドレスを固定すると改善されると思われます。
ご使用の conf ファイルに「set_ip <IPアドレス>」を追記して、コンテナの IP アドレスを固定してみてください。以下は例です。

set_ip 10.88.0.100

以上、どうぞよろしくお願いいたします。

maezawa.toshihiko

2025年6月5日 15時22分

山崎様

頂いた情報をもとにIPアドレスを固定化することで、コンテナ再起動後の通信が問題なく行われるようになりました。
ありがとうございます。

今回、IPアドレス割り当てを固定化する手法をお教えいただきましたが、この他に、ファイルの更新を伴わない方法で通信不可現象を解消させる手立てはございませんでしょうか。
armadilloを稼働場所が遠隔地でかつ通信回線が細くソフトウェアの入れ替えが難しい環境がございます。
そのような環境にて先の通信不可現象が発生した場合の回復手段があれば知っておきたいのです。

例えばcontrack周りに問題があるとのことでしたが、conntrackのトラッキング情報を削除することで回復したりはしないでしょうか。

maezawa.toshihiko

2025年6月5日 16時24分

さらに追加で質問させてください。

今回は特定ポートへのすべての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

2025年6月5日 18時54分

お世話になっております。山崎です。
>頂いた情報をもとに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…

2025年6月6日 7時07分

よこからすみません、
マルティネです。

アップデートするのは正しいですが、問題は理解してますのでもうちょっと説明します。

まずは、この問題は不具合に見えますが、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

2025年6月11日 10時16分

いろいろな情報をありがとうございます。

base OSなどのupdateですが、本来はやりたいところ、対象機器設置場所が人が入り込めない山奥であり、また利用しているインターネット回線が細く、かつエンドユーザ様のものであり、ソフトウェアアップデートのために利用できず、ファイルサイズの大きな os updateは実施できません。

> * 同じポートでも、120 秒以上通信を一旦やめればカーネルが接続を忘れて再び新しいコンテナに転送されます。
アプリケーションの構造上、120秒間通信をしないということは実現できません。

> * ソースポートを 50000 ではなく別のポートを使うと別の接続として認識されますので、転送可能になります。
こちらでの解消か、IPアドレスを固定化するか、の二択になりますが、ひとまず実績ができたIPアドレス固定の方向で進めていきたいと思います。

サポートありがとうございました。

at_dominique.m…

2025年6月11日 10時43分

マルティネです。

> base OSなどのupdateですが、本来はやりたいところ、対象機器設置場所が人が入り込めない山奥であり、また利用しているインターネット回線が細く、かつエンドユーザ様のものであり、ソフトウェアアップデートのために利用できず、ファイルサイズの大きな os updateは実施できません。

事情の説明ありがとうございます、理解しました。
OS アップデートがサイズ的に扱いづらくてすみません。

今回の問題は OS 全体のアップデートが必要なく、ファイル一つを転送すればいいだけですので、SWUの場合は標準 ~45KB ぐらいの転送になります(それでも大きいでしたら実装はしてませんが、2KBぐらいの SWU イメージまで構築できると思います)。
こちらの問題を他の方法で回避できても不具合や脆弱性は必ずでるものですので、今後にでもご検討いただければと思います。

ややこしいですが、インタネット回線がエンドユーザ様のもので、勝手にアップデートに利用できない問題はエンドユーザ様にアップデートを実行させる仕組みも可能かと思います。

よろしくお願いします