mnakada / atomcam_tools

Hack tool for atomcam and wyzecam.
Other
183 stars 22 forks source link

ローミング環境での動作について #34

Closed accept closed 2 years ago

accept commented 2 years ago

お世話になっております。 以前ブログでコメントさせていただいた際に素早い対応を頂き、ありがとうございました。 このような素晴らしいソフトウェアをご厚意で公開していただき、本当に頭が下がる思いです。

今回はご相談なのですが、現在私の環境ではWiFiがローミングの構成になっており、建物の各所にAtomcamが設置され、それらがRTSPの録画サーバーにデータを送っているという形になっております。 Atomcam起動直後は一番近いAPに接続し通信を始めるのですが、APになんらかの問題が発生したり再起動したりすると、Atomcamは次に近いAPに繋がります。 ここまではいいのですが、一番近いAPが復旧してもそちらに再接続されず困っております。

一応調べたところ、このような記事を見つけました。 https://wiki.archlinux.org/title/wpa_supplicant#Roaming ようは、wpa_supplicantのデフォルト設定ではローミングが比較的臆病で、信号が完全に喪失しないと弱いAPに繋がったままになる。 wpa_supplicant.conf内にbgscan="simple:30:-70:3600"と記述を入れることで、信号が-70未満の場合30秒ごとにスキャンしてくれるため、ローミング環境での動作が改善するということだそうです。

ただ、sshからtmpディレクトリ内のwpa_supplicant.conf内に記述するところまでは出来るのですが、それらを適応する方法が分からず手詰まりとなっております。 以前AtomcamはiCamera_appにてwpa_supplicant.confが生成されるため、記述内容を変えるのは難しいと見掛けた気がするのですが、例えばwpa_cli -i wlan0 reconfigureなどで、変更した記述を適応するなどは不可能でしょうか。 試したのですがwpa_cliが存在しないとのことで実行できませんでした… その他にもローミング環境下での何か良い改善方法がありましたら、ご教授いただけましたら幸いです。

takeshi56 commented 2 years ago

私も自宅のネットワークがローミング(802.11rやkまたはvなどに対応したMESHネットワーク)機能がありまして、同じ悩みを抱えています。WX5400HPで現在構築していますが、電波の弱い玄関(AC1)やカーポート(swing)の電波をWX1800HPでMESH中継して、改善を図ろうとしていますが、なかなか思った通りのAPへ接続してくれることはありません。 情報をいただきまして、init.dのスクリプトをrestartしてみました。

[root@atomcam-entrance:tmp]# cat /etc/init.d/S35wifi
#!/bin/sh
#
# skip wifi

case "$1" in
  start)
        ;;
  stop)
        ;;
  restart|reload)
        "$0" stop
        "$0" start
        ;;
  *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

exit $?

[root@atomcam-entrance:tmp]# cat /etc/init.d/S40network 
#!/bin/sh
#
# Start the network....
#

case "$1" in
  start)
        ifconfig lo up
        ;;
  stop)
        ;;
  restart|reload)
        "$0" stop
        "$0" start
        ;;
  *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
esac

exit $?

[root@atomcam-entrance:tmp]# /etc/init.d/S35wifi restart
[root@atomcam-entrance:tmp]# 
[root@atomcam-entrance:tmp]# 
[root@atomcam-entrance:tmp]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq qlen 1000
    link/ether 7c:dd:e9:00:3d:d5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.125/24 brd 192.168.1.255 scope global wlan0
       valid_lft forever preferred_lft forever
[root@atomcam-entrance:tmp]# ifconfig -a
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:516183 errors:0 dropped:0 overruns:0 frame:0
          TX packets:516183 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2444637556 (2.2 GiB)  TX bytes:2444637556 (2.2 GiB)

wlan0     Link encap:Ethernet  HWaddr 7C:DD:E9:00:3D:D5  
          inet addr:192.168.1.125  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12636736 errors:0 dropped:2290269 overruns:0 frame:0
          TX packets:22421903 errors:0 dropped:97 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2482345101 (2.3 GiB)  TX bytes:2501127449 (2.3 GiB)

[root@atomcam-entrance:tmp]# /etc/init.d/S40network restart
[root@atomcam-entrance:tmp]# ifconfig -a
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:516499 errors:0 dropped:0 overruns:0 frame:0
          TX packets:516499 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2446208749 (2.2 GiB)  TX bytes:2446208749 (2.2 GiB)

wlan0     Link encap:Ethernet  HWaddr 7C:DD:E9:00:3D:D5  
          inet addr:192.168.1.125  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:12637458 errors:0 dropped:2290482 overruns:0 frame:0
          TX packets:22423068 errors:0 dropped:97 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:2482510571 (2.3 GiB)  TX bytes:2502788138 (2.3 GiB)

[root@atomcam-entrance:tmp]# 

ただし、適用したwpa_suplicant.confの内容を確認する術がまだ見つかっていなくて、Restartしてなんともない(何も変わっていない)状況です。ひとまず様子を見ているところです。

takeshi56 commented 2 years ago

/tmpを散歩していて気がついたのですが、

[root@atomcam-box:tmp]# cat wifilevel.txt 
-35.
[root@atomcam-box:tmp]# 

AC2にはRSSIを出力するファイルがあるのでしょうか?AC1には同じ場所にありませんでした。

mnakada commented 2 years ago

@accept

試したのですがwpa_cliが存在しないとのことで実行できませんでした…

docker, docker-compose, makeがある環境を用意できれば下記手順でwpa_client, wpa_cliを含んだzipファイルができるのでscpで/media/mmc/updtaeにコピーして再起動すれば実験することは可能です。

atomcam_toolsのdirectoryで

# make login
root@037c24a9454b:/atomtools/build/buildroot-2016.02# make menuconfig

CUIでTarget packages -> Networking applications -> wpa_supplicantとInstall wpa_cli binaryを選択
ExitでConfigをsaveして抜ける

root@037c24a9454b:/atomtools/build/buildroot-2016.02# make

Host側にatomcam_tools.zipが出来上がる。
mnakada commented 2 years ago

@takeshi56 /etc/init..d/S35wifiの中身は空なので、WiFiの再起動はされていないです。 WiFiはatomcamのアプリからwpa_supplicantを呼び出してるので、そのあたりを変更する必要があります。 たしか、誰かがその辺りのscriptの修正を試されていたかと思います。

accept commented 2 years ago

@takeshi56 情報ありがとうございます。 ローミング環境下での悩みを抱えているのが自分だけではないとわかり安心いたしました。

accept commented 2 years ago

@mnakada ありがとうございます。 環境を整えて挑戦してみたいと思います。

accept commented 2 years ago

@mnakada お世話になっております。 先ほど仮想環境にてUbuntuをセットアップし、環境を整えました。 dockerを触ったのが初めてだったため少し戸惑いましたが、ビルドまでこぎつけました。 wpa_cliコマンドも無事使え、検証を始めることができそうです。

一つお聞きしたいのがこちらの環境ではmake loginを実行してもdockerイメージ内のbashが立ち上がりませんでした。

docker-compose exec builder bash
ERROR: No container found for builder_1
make: *** [Makefile:12: login] エラー 1

Makefileを見るとbuildでは docker-compose ps | grep -v exited | grep builder || docker-compose up -d このようにdockerイメージを事前に立ち上げている?処理が入っているように思います。 loginのほうは docker-compose exec builder bash のみだったため、勝手ながらbuildの方のスクリプトを追加し、無事bashを立ち上げることができました。 dockerの流儀があまり分かっていないのですが、これは何か事前にイメージを立ち上げておくのが暗黙の了解といいましょうか、お約束という感じになっているのでしょうか。

hiroki-tagami commented 2 years ago

dockerを入れているサーバを稼働させている場合、コンテナの再ビルドが必要でない限りは 起動すると大体の場合はそのままにしていることが多いかと思います。

当方ではdockerをあまりそういう使い方をしたことがないのでどうするのが正しいのかはわかりかねますが 毎度docker環境をシャットダウン、もしくはコンテナを停止されるような環境を考慮するならば login セクションに docker-compose ps | grep -v exited | grep builder || docker-compose up - を追加するほうが丁寧ではあるかと思います。

accept commented 2 years ago

@hiroki-tagami ありがとうございます。 dockerも色々な使い方があり、奥が深く難しいものですね…

accept commented 2 years ago

報告です。 wpa_cliが使えるようになり、書き換えたwpa_supplicant.confを再ロード出来ることを確認しました。 ですが、bgscanオプションはどうやら動作していないようです。 wpa_supplicantのビルド時にbgscanを使用する設定が必要との記述も見かけたため、そちらもwpa_supplicant.mkを書き換えてビルドし直してみましたがどうやっても動作しないようでした。 自分の知識ではここまででしたが、今後も細々と調査は続けようと思います。

mnakada commented 2 years ago

@accept ,

一つお聞きしたいのがこちらの環境ではmake loginを実行してもdockerイメージ内のbashが立ち上がりませんでした。

はい。すみません。普段makeしてから何かを修正するためにmake loginしてたため最初からmake loginするとdockerが起動してないですね。 あとで修正入れておきます。

accept commented 2 years ago

@mnakada つまらないことをお聞きしてしまいすみません… そのような事情だったのですね。 修正ありがとうございます。 DockerやBuildrootを使ったこともなく、ましてやLinuxを普段使いしているわけでもない自分でもここまで簡単にhackイメージをカスタムしてビルド出来る環境が整えられていたことに、さらに感服いたしました。 issueは1ヶ月ほど残して、私や私と同じ悩みを抱えている方、その他の方の検証など進展がなさそうであれば一旦closeにしようかと思います。 ご教授ありがとうございました。

mnakada commented 2 years ago

@accept

wpa_cli set_network 0 bgscan \"simple:30:-70:3600\"

で設定できませんか?

accept commented 2 years ago

@mnakada 情報ありがとうございます。 コマンド自体は通ります。というより、以前の検証段階でそちらのコマンドも試してはいたのですが、パラメーターをいくら変えてもAPは切り替わらないですね…

ただ、以前検証した際にAtomcamが現在接続しているAPのRSSIはwpa_cli signal_pollで見ていたのですが、周辺に存在するAPは見てなかったと思い、wpa_cli scanwpa_cli scan_resultにて結果を見てみました。 すると本来であれば一番近くにあるはずのAPで、接続時にはwpa_cli signal_pollにて-50ほど出るAPが、Atomcamが他のAPに接続されている状態でscanすると-70付近しか出ていません。

APとの相性なのか、Beamformingの関係なのかはわかりませんが、bgscan以前に根本的な問題があるようでした… スマホのWiFiスキャナでは距離に準じて正しくRSSIが出るので、wpa_supplicantかその近辺のバグなのかもしれません… ただ2番目に近いAPは接続状態に関係なくRSSIがほぼ不変なので、そこもよくわかりません…

mnakada commented 2 years ago

Ver.1.3.8でNetwork設定をiCamera_appから分離して、hack側に移動しました。 WiFi設定を変更する場合は/media/mmc/wpa_supplicant.confで、 ネットワーク構成を変えたい場合は/media/mmc/network_init.shで変更できます。 この2つのファイルの読まれ方は/scripts/network_init.shを解読してください。

accept commented 2 years ago

@mnakada ありがとうございます。 とても助かります。 これで最新版でもビルドし直さずに検証できます。

accept commented 2 years ago

さっそく1.3.8を試してみました。 /media/mmc/下のwpa_supplicant.confが/tmp/system/etc/にコピーされているのを確認し、topにて/tmp/system/etc/wpa_supplicant.confが読み込まれているのも確認しました。 ただ、相変わらずbgscanは動作していないようです。

というのも、bgscanのsimpleではなく、bgscan="learn:30:-45:300:/media/mmc/network1.bgscan"を試してみてもnetwork1.bgscanに何も書き込まれないため、bgscan自体が動作していないんじゃないかと考えています。 touchにて事前にファイルを作成しておいても、/tmpディレクトリ下に配置しても読み書きは行われないようです。 下記のTexas instrumentsフォーラムでもwpa_supplicantのビルド時にパラメーターを指定しないとbgscanが動作せず、エラーも吐かないようなことが書かれているため、Atomcamでもそのような状態になっているのではないかと予想しております。 https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/424894/wl18xx-wpa_supplicant-bgscan-settings

自前でwpa_supplicantのパラメーターを設定しビルドしても、確かに出来上がるイメージサイズは変化するのでなんらかのバイナリの変更などはされていると思うのですが、相変わらず動作はしないというのが現状です。 bgscan自体の情報が少なく、以前はbuildrootでもbgscanを使うよう修正されたこともあったようですが、現在はパラメーターが削除されている?ようです。 https://buildroot.uclibc.narkive.com/xked2Lid/patch-1-1-wpa-supplicant-add-support-for-simple-background-scan

ただ、パラメーターもバージョンによって違いがあるようで、調べた限りでは

NEED_BGSCAN=y //これは要か不明
CONFIG_DRIVER_NL80211=y
CONFIG_BGSCAN_SIMPLE=y
CONFIG_BGSCAN_LEARN=y
NL80211_CMD_ROAM=y
CONFIG_LIBNL20=y
CONFIG_LIBNL32=y
CONFIG_WPS2=y
CONFIG_BGSCAN=y

このあたりを有効にする必要がある?というところまでは調べられましたが、情報が古かったり、wpa_supplicantに対する知識不足もあり、停滞中といったところです。 また、ファームウェアやドライバで実装されていないと動作しないというような表記も見かけますので、もしかしたらwpa_supplicantのリビルドやwpa_supplicant.conf内にパラメーターを記述するだけでは動作しないのかもしれません。 https://www.silabs.com/documents/login/application-notes/an1287-rs9116n-wi-fi-roaming-application-note.pdf

現状このような感じで、私の方では手詰まり感が出ております…。

accept commented 2 years ago

@mnakada すみません、今気づいたのですが以前自前でwpa_cliを有効にしてビルドしたファームウェアを当てているAtomcamをWebUIから1.3.8にアップデートしたところ、確かに1.3.8になっていますがwpa_cliが有効になったままとなっています。 多分SD内のファイルを総入れ替えすれば戻るとは思うのですが、このようなことは起こりうるのでしょうか。 それともアップデートに部分的に失敗している…?可能性はありますか?

mnakada commented 2 years ago

@accept Ver.1.3.8でWiFi設定をhack側に分離したためwpa_supplicant, wpa_cliを追加しています。

accept commented 2 years ago

@mnakada 失礼いたしました。 その可能性も考え、自前FWを入れていない他のAtomcamとも比較してたつもりだったのですが、1.3.8だと思っていたのが1.3.7だったようです…

takeshi56 commented 2 years ago

@accept さん、その後ローミング環境(MESHネットワーク)での運用どのようにされていますでしょうか? 私は結局、ATOMcamのWi-Fi接続先APを固定することでネットワークを安定化させ、一時的な解決としようかと思っています。 wpa_suplicant.confにBSSID(AP側WireressPHIのMACアドレス)を記述する事で、不用意なAPローミングを避けようという考え方です。ATOMcam達の/media/mmcに/tmpにあるwpa_supricant.confをcpして、BSSIDの設定を下記の通り追記しました。

[root@atomcam-entrance:~]# cat /media/mmc/wpa_supplicant.conf 
ctrl_interface=/var/run/wpa_supplicant
update_config=1
network={
        ssid="abc6"
        bssid=a0:b2:c7:df:1b:fa  -->ここを追記しています
    key_mgmt=WPA-PSK
        pairwise=CCMP TKIP
        group=CCMP TKIP WEP104 WEP40

10回ほどリブートしましたが、最初は指定されたAPへ接続しているようです。しばらくこれで様子を見てみようと思っています。 wpa_cliの利用が出来るようになったおかげで、AP毎の電界強度が解ってこの解決策を検証するところまで来ました。 @accept さん @mnakada さん、ありがとうございます。引き続きログの確認を行って見守りたいと思います。

accept commented 2 years ago

@takeshi56 気に掛けていただきありがとうございます。

私も同じようにBSSIDを指定して運用する方向に切り替えていました。 ただ、やはり一時しのぎと言いましょうか、BSSIDを決め打ちしているだけなので汎用性が無いといいましょうか… なんだかなぁと思いながらも運用しているという感じです。 そして、どうしても切断されたり不安定だとまずいところは有線化も検討しており、AC1のテスト機ではnetwork_init.shを食わせて有線接続に成功しております。 対応しているUSBNICが家に転がっていたのが幸運でした。

ただ、やはり外に設置してあるAC2が一番WiFiが不安定なので、データ通信も可能でAtomcamの端子にすっぽりハマる防水対応そうなUSBケーブルが手に入れば、OTGで有線接続化も出来るのになぁなどと考えていますが、そんな都合のいいケーブルはなかなか無いようですね…

BSSIDの指定も、有線化の夢を見れるのも@mnakada 様がNetwork関連をアプリから分離していただき、自前のwpa_supplicant.confやnetwork_init.shを食わせることが出来るようになったおかげです。 本当に頭が下がる思いでいっぱいです。 また、声を上げていただいた @takeshi56 様、Dockerに関してコメント頂いた@hiroki-tagami 様もありがとうございます。

完全とは言えないにしても、とりあえずの運用が可能になったため一旦closeとさせていただきます。 ローミング関連で検証中に何かありましたらまたこちらにご報告したいと思います。 ありがとうございました😌