ぐるぐるnest hub その1 インターネット未接続となる問題  徹底調査で解決 

「WiFiに繋がらない」、「インターネット未接続となる」などで検索すると多数の記事が見つかり、そこには「使用デバイスの不具合」、「無線LANルーターに不具合」などの記載があり、その対処は「スマートフォンの機内モードのONとOFFを切り替える」とか「スマートフォンのネットワーク設定をリセット・再設定」とか書いている。その対処で動くようになることがあるかもしれないが、原因が特定できておらず、再発する可能性が高い。つまり解決したことにはならないことが多々あるに違いない。

  ここでは、ほかのサイトに書かれていない(稀な?)パターンの調査&解析とその解決までの記録である。 タイトルを「ぐるぐるnest 」としたが”その1”ではnestの話を書こうとしていたところ発生した別パターンのトラブルについて書く。

症状:

AndroidスマホをWiFiにつないで使用していた。ある時点までは問題なくWiFiを利用できていたが、部屋を移動して別の無線LANを使用して元の部屋に戻ってきWiFi接続を切り替えるとWiFi(無線LAN)には接続できているが「インターネット接続なし」となりネット利用できなくなる。
 同じ無線LANに接続してほかのIoT機器(Google home、SiwtchBotHubやNature Remo)はインターネットに接続できている。

 この状態で、他のサイトの記事を参考に対処するなら、Androidスマホの再起動や、WiFiオンオフの設定や無線LANの再起動だろう。 いずれの対処も効果なく症状に変化はなかった。過去には似たような症状のときに、無線LAN再起動することで復旧したことはあったが、今回はそのパターンではなさそう。
「原因特定なくして解決なし」ということで原因調査を開始した。

解析編:

まず大まかな切り分けから。
 よくあるサイトの対処手順を参考に切り分けてみる。
1. まずスマートフォンそのものが壊れていないかを確認
  他の無線LANにつないで使う分には問題なく使える
→ 「 スマートフォン そのものの故障」ではない
2.「スマートフォンの機内モードのONとOFFを切り替える
  OFFにするとつながらない。ONに戻しても「インターネット接続なし」の状態に変化はない。 →「機内モード」の問題ではない
3.「スマートフォンのwi-fiのONとOFFを切り替える
OFFにするとつながらない。ONに戻しても「インターネット接続なし」 の状態に 変化はない。 →「WiFi ON/OFF」の問題ではない
4. 「スマートフォンのネットワーク設定をリセット・再設定
 無線LANに接続できているので、スマートフォン側の設定の可能性は極めて低い。もし、設定の問題だとしてもいきなり再設定ではなく設定が妥当か確認する作業が必要だろう。 ということで、後で確認する。
5.「スマートフォンを再起動
スマートフォンが異常な状態になっているなら、これで復旧するかもしれない。
 再起動しても 「インターネット接続なし」 の状態に 変化はない。 →  一時的な異常な状態という問題ではない。

 ということで、よくあるWiFi接続問題を取り扱うサイトには書かれていない何らかの問題が発生していると推測された。

戻って、スマートフォンのネットワーク設定を詳細確認してみた。 設定詳細を開くと、スマートフォンに払いだされたIPとゲートウェイIPは目を疑うものだった。いや、これではインターネットにつながるはずがない。これで、無線LANに接続できているのにインターネットに接続できない直接的な原因は理解できた。
 なぜそうなったかの調査と根本対策は。ここから始まる。
とりあえず復旧させてみよう。”プライバシー….” という項目を長押しするとMACアドレスをランダムにするかデバイス固有のものにするか切り替えることができる。これを使ってIPアドレスをDHCPに再払い出しを要求してみる。 とりあえずIPアドレスは想定通りのものに変わりインターネット接続は復旧した。
 →これで、 「インターネット接続なし」 の直接の原因は”割り振られたIPアドレスにある”ことが確認できた。

 問題の「目を疑ったIPアドレスとゲートウェイIP」は、遠く離れた場所に最近追加した無線LANの無線LAN側のDHCP設定で指定したものだった。
 ここまでの状況を図で整理すると次のようになる。


この挙動は、かなりありえないことが起きていそうなことが理解できるだろう。ただ、事実起きているのだから、この事象発生には何か原因があるのは間違いない。こういう問題は、”ありえない”と最初から起こりそうにないことを除外してしまうと永遠に解決できなくなる。切り分け調査を一歩一歩進めるのが解決への近道である。

 さて切り分けをどうするかを考えようとしていた矢先、「インターネット接続なし」問題が再発した。 今度は、  ”プライバシー….”を使ってIP再払い出しを試みるも復旧しなかった。なおかつ、IP再払い出し要求をするたびに確かにIPが変わっている。そのIPは無線LAN③用のものだ。無線LAN③からIPが払い出されているのは間違いなさそうだ。では、どのような経路で払い出されているのだろう。WiFi接続の認証後、IP払い出し要求するときに無線LAN③からの電波を受け取っているのだとしたら、… 
 無線LAN③の電源を切ることで解決できそうだ。しかし、必要だから無線LAN3を用意したわけで、いつも電源を切っておくわけにはいかない。そこで、まず電源は切らずに無線LAN③のWAN側のケーブルを抜線してみる。

暫定対処

無線LAN③のWAN側のケーブルを抜線して 、スマホで「 IP再払い出し要求 」をすると正しいIPが払い出されて、インターネット接続に成功した。
 これで、このトラブルのメカニズムを理解できた。
ここまでの文面で分かる人は理解できたかもしれない。少し難解なところもあるので、再度整理しておこう。

トラブル原因と仕組み

仕組みは上の図の通りである。 問題は、無線LAN③のDHCP動作である。DHCPはLAN側設定であって、WAN側に流れるものではない。 無線LAN①に接続した機器は通常ブロードバンドルータが払い出したIPを利用する。これにより、IPは192.168.1.xxx、ゲートウェイIPは192.168.1.254となる。しかし問題発生時はIPが192.168.80.xxx、ゲートウェイIPが192.168.80.1となっていた。
 192.168.1.xxとなるか、192.168.80.xxとなるかは、どちらのDHCPからの応答が早いかなど運しだいという状況だったわけだ。スマホ以外のIoT機器に問題がなかったのはたまたまといってよいだろう。いつかは同じ状態に陥っていたかもしれない。また、IoT機器は設計上リトライ回数を増やすなどが我慢強い復旧策を実装しているのが効いているかもしれない。
 いずれにしても、根本原因は判明した。

根本対策

問題原因は分かり、無線LAN③のWANケーブルを抜くことで解決したが、192.168.80.x系のIoT機器が使えない状態なので、いつまでもこの状態にしとくわけにもいかない。
 
 無線LAN③の設定を見直してみる。 そもそも192.168.80.x系の通信がWAN側に漏れるのを防ぐべきで、基本的にはガードできているようだ。 だが、実際にDHCPのUDPパケットはWAN側から無線LAN③に到達して、それに対する応答をしている。 無線LAN③のWAN側パケットフィルタを見るとデフォルトで多数の設定が組み込まれているがDHCPパケットの破棄設定はなかった。

  そこで、DHCPパケットをフィルタリングすることとした。根本対策は、「ネットワーク構成変更jする際は、境界を越えてDHCPパケットが流れないように設定を確認する、また設定を行う」とする。
 ※ネットワーク機器メーカは妥当になるように製品開発を行う際は十分に検討・検証してほしい。

最後に

トラブルの対処法は、小手先の対処では再発する。根本原因を調査して根本対策しましょう。
  ちょっと、長くなりました。 タイトルの「ぐるぐるnest」は次の機会に書きます。このネタも今回と同じくらい長くなる予感がします。。。

音声コマンドで、Google Nestやテレビ(Chromecast)にスマート非対応のWebカメラの画像を表示してみる(hsbox使用)

スマート対応されたIPカメラも登場してきていますが、現時点のWebカメラのほとんふどは未対応でしょう。そこでスマート非対応のWebカメラからGoogle Nestやテレビに映し出すことにトライします。もう一つポイントは”プログラミングしない”ということです。hsboxを使用し、設定だけで実現します。

システム構成:
IFTTTで 「Google Assistant」 をトリガに使用。
※機種によっては監視カメラ自体のアラームをトリガにできます

②IFTTTの 「Webhooks」で、hsboxのAPIを操作。

③ hsboxのメニューのコマンドで画像をURL指定指定して
スマートデバイスに 「cast」を実行

  ④ Google Nestなどの スマートディスプレイや、
Chromecastが WebカメラにURLにアクセスし
ディスプレイやテレビに画像を表示

ここでは、hsboxのスマートサービス連携機能クイックスタートガイドの設定が完了している前提で書きます。 つまり、「メニュー ゼロ」の呼び出しで、ディスプレイや テレビにhsboxのトップメニューが表示されるところまでの設定が完了している前提です。

■①トリガの設定、② 「Webhooks」 の設定

①、②は上記の前提条件の設定状態で完了しています。個別の「シングルワード」での呼び出し設定を行うことで、より操作しやすくなります。

■③メニューのコマンド設定

hsboxのメニューファイルをダウンロードします。設定変更していないなら、どのファイルも同じです。すでに変更していて、追加したい場合は、boxmenu.txtをダウンロードして編集します。

設定例:
 メニューの 625番に 玄関に着けたWebカメラ(http://192.168.20.50:80/snapshot.jpg)を表示するコマンドを登録してみます。

625番なので、 boxmenu.txt ファイルの626行目をつぎのように更新します。※ boxmenu.txt ファイル の行は追加削除しないでください。行番号がメニュー番号に対応しています。先頭行(1行目)が、メニュー0番なので、メニュー625番は、626行目に相当します。

302,http://192.168.20.50:80/snapshot.jpg,-,625: 監視カメラ (玄関),カメラ,-


Google home ,nestに プログラミングなしでプッシュ通知をやってみる(hsbox使用)

以前、「雨が降りだしたら自動で排水」という記事を書きました。今回は、これを拡張して、”排水”の前に、「雨が降り出しました」と音声でプッシュ通知することにトライします。もう一つポイントは”プログラミングしない”ということです。hsboxを使用し、設定だけで実現します。

システム構成:
    IFTTTで 「Weather Underground」 のトリガを使用。
※このイベントの精度を向上できるほかの方法がないか後日検討

IFTTTの 「Webhooks」で、hsboxのAPIを操作。

hsboxのメニューのコマンドでスマートデバイスでの
「文字列読み上げ」を実行

  Google home や Google Nestなどのスマートスピーカー、
スマートディスプレイ、 Chromecastを備えたテレビで
音声によるプッシュ通知

ここでは、hsboxのスマートサービス連携機能クイックスタートガイドの設定が完了している前提で書きます。 つまり、すでに「メニュー ゼロ」の 発話でhsboxのトップメニューが、ChromecastをつないだテレビやGoogle Nestに表示される状態ということです。
 
前提条件はここまでです。 以下は、プッシュ通知の設定方法です。

■プッシュ通知の設定する

まず、通知するためのイベントを設定します。
以前に作成したレシピに追加します。

以前「雨が降りだしたら自動で排水」レシピを作成したときは、まだ1つのレシピに1つのサービスしか実行できず、複数実行したいときはすこし技が必要でした。
現在は、下のように「+」を押すと実行するサービスを追加できます。
  降雨イペントの作り方は、以前に作成したレシピを参照してください。

複数のスマートデバイスへのプッシュ通知は、複数サービスを書くことで実現できます。

■通知サービスの設定

Webhooksの設定でつぎのようにURLを設定します。
自ドメインはグローバルIPアドレスでも可能ですが、通常は動的にIPアドレスが変わるのでDDNSを利用して取得したドメイン名を利用してください。
ポート番号は、ルータで指定したポート番号を指定してください。ルータで家庭内LANのIP、ポートに変換する良いでしょう。変換先はhsboxのIPとポート番号を指定してください。hsboxのIPは、ルータでのIP払い出しを固定化するか、hsboxの固定IP追加機能を使用して動的に変わらないようにするとよいでしょう。hsboxのポート番号は、hsboxの仮想サーバ機能のポート番号指定で任意のポート番号を指定してください。

上記の①から③についての設定について説明します。
①hsboxのboxapiキーです。
hsboxの「スマートサービス連携」で指定したキーを設定します。
②プッシュ通知を設定したメニューの番号です。
  「雨が降りだしました」 は、デフォルトで 333番に登録されているのでこれを指定します。 メニューに任意の通知メッセージを設定できるのでそれを使うこともできます。また、動的にメッセージを変えることも可能です。
③プッシュ通知を実行するターゲットのスマートデバイスコードです。
   「スマートサービス連携」の「グループ」設定に登録したスマートデバイスのコードを設定します。 tgtは指定しない方法もあります。指定しない場合は、hsboxに設定されているカレントグループにプッシュ通知されます。

POSTで設定する場合は、上のようにBodyを設定します。 GETでURLのみで指定することも可能です。

以上で、プッシュ通知をプログラミングなしで実現できました。
他にも工夫次でいろいろできそうです。

WordPress5.4.2セキュリティ修正リリース   5.2.7も自動適用

 2020/6/10にWordPress5.4.2がリリースされた。これにはセキュリティ修正が含まれている。 修正 https://core.trac.wordpress.org/query?milestone=5.4.2&group=component&col=id&col=summary&col=milestone&col=owner&col=type&col=status&col=priority&order=priority

 このリリースにはセキュリティ修正のほかに強化も含んでいる。5.4系を使っているなら上げるほうがよいだろう。 5.2系は 5.2.7でとりあえずよいのか…。 5.2.6、5.2.7の修正内容は見えない感じです。

パッチはリリースしているのに、修正内容が分からないのはいまいちです..

WordPress5.4.1リリース  セキュリティ修正を含む が … 5.2.6も自動適用された

 2020/4/29にWordPress5.4.1がリリースされました。これには7件のセキュリティ修正が含まれています。ただ相変わらず修正内容に関する情報公開がぬるい。修正のほかに強化項目も含まれているので何用のリリースなのか分かりにくい。

■5.4.1での修正内容は

 情報公開で、分かりにくいポイントはいくつかあるが、ぱっと見どれがセキュリティ修正かわからない。NVD、JVNには4/30時点では、まだ情報公開されていないようです。修正内容のほとんどはバグ作り込みが、WP5.4となっています。そして2件の修正対象のバグ作り込みバージョンは5.3となっています。 これはREST APIに関するものです。 この修正では、5.2以前のものはなさそうなので、 5.2系を使っているところは様子見でよさそう。

 REST APIの件がセキュリティ修正かどうかが気になる。 #49648はプロパティのアトリビュートが取れない問題、#49645も同様にREST APIを使ったシーンで情報が取れない問題だ。これは、セキュリティかどうかに関係なくアップデートしておいたほうがよさそうです。 アップデートするとなると気になるのは、5.4や5.4.1で強化された項目の残バグの状況です。 

■残留バグ、つぎの修正の予定は?

すでに5.4.2を作業中のようです。これも強化を含む修正で、5.1で作り込んだバグの修正も含みそうです。 

■それで、どうする?

5.4.1については、 5.3系には適用するのでよいでしょう。 5.2以前は5.4.2が出るのを待つので良いでしょう。5.2は5.2.6が自動適用されました。
それからNVDなどの情報もチェックしましょう。

■追記:5.2.6の内容は?

5.4.1の修正内容ではなく、5.4.2で作業中のテーマの更新を先行して出したようです。WordPressの修正一覧ではマイルストーン、バージョンともに5.2.6はまだ登録されていません。 修正内容もチェックしておきましょう。

WordPress5.4がそろそろリリースされそう。 セキュリティ修正は?

 2019/12/13にWordPress5.3.1 セキュリティパッチがリリースされてから、セキュリティ修正はまだないが、5.4でどうなるかちょっとみてみた。 修正内容の管理も5.4もできている。

■5.4での修正内容は

 今時点で5.4がリリースされるような状況ではない感じがする。 最悪5.4はスキップして、5.5か という感じさえする。というのは、#49685 など、マイルストーンを5.5としている。修正できたら5.4にセットしなおすのかもしれないが。。。

それから、5.3以前の作り込みバグの修正はなさそうです。いずれも5.4での問題の修正とされている。

■4/2追記:

5.4リリースされていました。
結構クローズされていない状態でリリースされているようだ。 修正内容の項目数は、先日みたときより4倍くらいに増えている。まだまだ修正中という感じですね。となると、5.4.1のリリースもすぐかもしれない。 それから、5.4での強化のいろづけが簡単にできるようになるのはよさそう。。。 でも、大きめの残バグがあるので、5.4へのバージョンアップは修正パッチが出てからにしよう。

・脆弱性

2020年もプラグインがらみの脆弱性が多数報告されている。 プラグインのほうもチェックしておかないと。。。

セキュリティパッチでないのに短期間でWordPress5.3.2がリリース。 5.2系のパッチは?

 WordPress5.3.2が12/18にリリースされた。 5.2.6はリリースされているかは自動適用されていないので不明。5.3.2での修正内容からは5.3.1で作りこまれた致命的なバグとわかります。これが短期間でのリリースの理由でしょう。ないことです。1件のバグ(#48145)は煮え切らない解析の結果、5.3での修正(#45821)の影響で発生していると判断して、修正を行っている。意外にPHP側に問題があり、その問題回避をしているのかもしれない。 いずれにしても、5.3.2は5.3以降に発生した問題の修正なので、これらの対処のために5.2.6がリリースされることはなさそう。  それから、 分かりにくいが5.2.5が登録されていた。  
 そのほか5.3.2リリースでは、5.3系のアップデートはこれで終わりで次は5.4とされている。なので、5.3系へのアップデートは様子見とします。
 ただ、5.3.1に上がってしまっている環境については、5.3.2にアップデートすることとします。

■それより、プラグインのパッチは?

 プラグインについては、当てられるものはパッチ適用する。

WordPress5.3.1 セキュリティパッチが出たけど、5.2.5が適用された。

 WordPress5.3.1 セキュリティパッチが12/13にリリースされた。 同時に、5.2.5もリリースされたようだ。5.2.5についてはセキュリティパッチのページには掲載されていない。5.2.5が適用されたことは期待値どおりだが、5.2.5のことが情報公開されていない点がいまいちだ。修正内容の管理も5.3.1は情報があるが、5.2.5の情報がない。相変わらず管理が不十分な感じはぬぐえない。

■で、パッチ適用はどうする?

 手動でのパッチ適用は、5.3.1しかできないようだ。これは5.3.に誘導する策略なのかと違ってしまうが、、、。 まずは、テストサイトで5.3.1の検証を行う。そこで、問題が無ければ、ほかの本番系サイトにも適用していく流れにするしかなさそうだ。…..  困ったものだ。

WordPress5.3はとりあえず様子見

 WordPress5.3が11/12にリリースされたので、別に構築したWordPress検証サイトで動作確認しています。

■更新する際に留意しておきたい点

 WordPress5.3へコンテンツの更新を行った後に、DBの更新が行われる。DB構成が更新されていそうです。どこが更新されたのかは、ぱっと見ではわかりません。
 → 更新でトラブルが発生した場合、書き戻しするにはDBの書き戻しも必要となる。更新&検証の際には、切り戻し時間にDB書き戻し時間も考慮しておく必要がある。当然だが、更新直前にDBデータのバックアップを行う時間も考慮しておく必要がある。

■WordPress5.3での変更点の確認

 エディタ機能が強化された。  メニューに「ブロックのグループ化 」が追加されています。 
 全体的にはあまり大きな強化や変更はない。急いで更新したいというものはない。また、更新に関して、問題も特に問題はなかった。そのため、とりあえず5.3の適用は保留し、今後提供されると推測されるセキュリティパッチがで提供されたタイミングで更新することにする。

WordPress5.2.4セキュリティパッチ

5.2.4セキュリティパッチが適用されてました。動作的には問題ないようなので、パッチ検証環境以外にも適用します。

 このほかに、5.3 Release Candidate が出ています。特にほしい機能があるわけではないので、取り換えず様子見です。

 そして、以前に旧版へセキュリティパッチの話を書きましたが、5.1.3が同時にリリースされていました。パッチリリースのところには情報公開されないのですね。ちょっと不親切な感じがします。