気になったので中のほうからの挙動を調べてみました。
常時pingで外部との疎通をチェックはしているのですが、
それで一定期間たつとアプリの内部ステータスは切断されたことになり、
ネット復活時には再接続する、というシーケンスはきちんと動作しているようです。
また、APとの接続状態はwpa_supplicantが正常に動作していて、APシャットダウン後の再接続にはきちんと応答しています。（IPアドレスの不整合が起こらない場合）
この後、DHCPのアドレス取得が入ればOKなのですが、確かに動作していないことを観察しました。
普通のLinuxのディストリビューションではこの辺バックグラウンドサービスでやってくれてるか、やるように設定するんでしょうが、ATOMCamでは全く設定されていませんね。
バックグラウンドでその辺動くようにしたらもしかしたら改善するかもですが、別に書いたようにデバイス情報のIPアドレスがサーバに送られていないようなので、きちんと連携しないとコケるかもなぁ。
いっそ、APがコケた後には再起動するように設定したほうがマシですね。
bakueikozoさま
モニタリングのレポート、ありがとうございます。非常に参考になりました。
やはりATOMCamはIP取得の挙動に問題がありそうですね。
それにしても、なぜ開発側はそのような仕様にしているのか疑問です。
ご存知の通りDHCPとはそもそも限られたIPアドレスを共有する為のものなので、クライアントのIPアドレスがちょいちょい変動するのは正常な動作ですし、そういうものです。
また、前レスのnoteのリンクでサーバとの関係を解説されていた記事がありましたが、それを踏まえますと、動画データを保存するサーバとは別にサーバがあるとすれば、そこにはユーザーIDとATOMCamの個別ID（MACアドレスか）が取れていれば必要十分なはずで、LAN側のIPアドレスは関係なくそこを変動させたくない理由は見当たらないんですけどね〜。