前の4件 | -
中古のFortigateについて その1(2023/05/23) [ネットワーク機器]
ファイアウォールアプライアンスとして、Juniper SSGにはお世話になったものですが、最近はすっかりFortigate一色ですね。他の選択肢をとるならPaloaltoなんてものもあるようですが。
個人的にFortigateは接点があまりなかったのですが、いざ実際に使ってみたところなかなか面白いですね。基本的に必要とされる機能が、一通り文句ないぐらいの作り込み度合いで実装されています。
Fortigateの便利さに慣れてしまうと、CISCOルータが随分とショボく見えてしまいます。
Fortigateの機能でよく分からなかったもの一つに、ライセンスの定期アクティベーションがあります。一般にUTM機能を利用する場合はシグネチャの「更新」は必要ですが、Fortigateは基本のファイアウォール機能の使用だけでも、定期的にアクティベーションを行うようです。
ファイアウォール機能は基本機能ですし、特別な追加ライセンスを必要とするものではありません。通信環境によっては、インターネットに接続できない完全オフラインで使う場合もありますので、オンラインの定期アクティベーション行為は必須なのか?と疑問に思ってしまいます。
裏を返せば、保守・ライセンス切れの中古Fortigateを買ってまともに使えるのか?ということですね。
私の個人的な調査の結果、結論から言えば
私の調べた限り、UTM系のシグネチャ更新を除けば、オンラインのアクティベーション通信で以下を更新しているようです。
①ISDB(Internet Service Data Base)
②Geo-IP
その2へ続く。
個人的にFortigateは接点があまりなかったのですが、いざ実際に使ってみたところなかなか面白いですね。基本的に必要とされる機能が、一通り文句ないぐらいの作り込み度合いで実装されています。
Fortigateの便利さに慣れてしまうと、CISCOルータが随分とショボく見えてしまいます。
Fortigateの機能でよく分からなかったもの一つに、ライセンスの定期アクティベーションがあります。一般にUTM機能を利用する場合はシグネチャの「更新」は必要ですが、Fortigateは基本のファイアウォール機能の使用だけでも、定期的にアクティベーションを行うようです。
ファイアウォール機能は基本機能ですし、特別な追加ライセンスを必要とするものではありません。通信環境によっては、インターネットに接続できない完全オフラインで使う場合もありますので、オンラインの定期アクティベーション行為は必須なのか?と疑問に思ってしまいます。
裏を返せば、保守・ライセンス切れの中古Fortigateを買ってまともに使えるのか?ということですね。
私の個人的な調査の結果、結論から言えば
問題なく使えるようです
私の調べた限り、UTM系のシグネチャ更新を除けば、オンラインのアクティベーション通信で以下を更新しているようです。
①ISDB(Internet Service Data Base)
②Geo-IP
その2へ続く。
タグ:fortigate
(Galaxy) S Healthの万歩計が使えない その5(2023/04/17) [Android&スマホ]
えー、はい。実際に歩いて実測しました。
普段は時刻を確認するなどで移動中もちょこちょこ電源ONにしているのですが、今回はスマホの省電力時の挙動を明確にするために、常時電源OFF状態を維持するようにします。
歩数カウントの多数決を取るために、以下の3つを比較することにします。
Google Fitは実質Android標準万歩計になると思われ、スマホ省電力の影響を受けないことや、精度良くカウントアップしてくれることを期待しています。
・Galaxy S Health(Androidアプリ)
・Google Fit(Androidアプリ)
・Xiaomi Smart Band 7(ウェアラブルデバイス)
残念ながら、出発前のカウンタ0の時のスクリーンショットを撮り忘れてしまったのですが、途中と最後の2つのスクリーンショットが以下の通りです。
各スクリーンショットの、上のカウンタがS Health、下のカウンタがGoogle Fitとなります。Xiaomi Smart Band 7は腕時計のため(私の)目視結果のみです。
肝心な出発前のカウンタを取り忘れていますが、ここに載せているスクリーンショットの差分だけでも、Google Fitの約2700歩の増分に対し、S Healthの増分は7歩と、明かな異常が観察できました。
スマホの省電力が影響し、S Healthはきちんと機能していないというのが明白ですね。
一応、最終結果としては、
・Galaxy S Health 1341歩
・Google Fit 6440歩
・Xiaomi Smart Band 7 6941歩
でした。
普段は時刻を確認するなどで移動中もちょこちょこ電源ONにしているのですが、今回はスマホの省電力時の挙動を明確にするために、常時電源OFF状態を維持するようにします。
歩数カウントの多数決を取るために、以下の3つを比較することにします。
Google Fitは実質Android標準万歩計になると思われ、スマホ省電力の影響を受けないことや、精度良くカウントアップしてくれることを期待しています。
・Galaxy S Health(Androidアプリ)
・Google Fit(Androidアプリ)
・Xiaomi Smart Band 7(ウェアラブルデバイス)
残念ながら、出発前のカウンタ0の時のスクリーンショットを撮り忘れてしまったのですが、途中と最後の2つのスクリーンショットが以下の通りです。
各スクリーンショットの、上のカウンタがS Health、下のカウンタがGoogle Fitとなります。Xiaomi Smart Band 7は腕時計のため(私の)目視結果のみです。
肝心な出発前のカウンタを取り忘れていますが、ここに載せているスクリーンショットの差分だけでも、Google Fitの約2700歩の増分に対し、S Healthの増分は7歩と、明かな異常が観察できました。
スマホの省電力が影響し、S Healthはきちんと機能していないというのが明白ですね。
一応、最終結果としては、
・Galaxy S Health 1341歩
・Google Fit 6440歩
・Xiaomi Smart Band 7 6941歩
でした。
タグ:S Health
(Galaxy) S Healthの万歩計が使えない その4(2023/04/12) [Android&スマホ]
S Healthのブレ幅が日によって大きく異なるのですが、スマホの省電力機能が犯人だとすると、一つ思い当たる節があります。それは歩きスマホ・・・ではなく、移動中・勤務中のスマホの電源ON時間です。
一般に、スマホは以下のような使い方(状態)になると思います。
(1)スマホを電源ONにする
(2)放置して画面が真っ暗になる
これって、正確に書くと、
(1)スマホを電源ONにする
(2)放置して画面が真っ暗になる(画面が暗いだけでCPUはアクティブ動作中)
(3)一定時間後、真の節電モード状態に移行
になると思われます。
このうち、S Healthが万歩計を正常にカウントアップできない時間は(3)の時間と推測できます。
スマホの使い方は人それぞれですが、私の場合スマホは時計代わりや天気予報等で頻繁に確認するので、移動中や勤務中であっても意外とONにしている時間は多いのです。裏を返せば(3)の真の節電モードに移行している時間が短いということですね。
ただ本当に忙しいときは確認する頻度も落ちますので、(3)に移行している時間が長くなっていると思います。
そのあたりの差が、ブレ幅のムラにつながっているのではないかと。
一般に、スマホは以下のような使い方(状態)になると思います。
(1)スマホを電源ONにする
(2)放置して画面が真っ暗になる
これって、正確に書くと、
(1)スマホを電源ONにする
(2)放置して画面が真っ暗になる(画面が暗いだけでCPUはアクティブ動作中)
(3)一定時間後、真の節電モード状態に移行
になると思われます。
このうち、S Healthが万歩計を正常にカウントアップできない時間は(3)の時間と推測できます。
スマホの使い方は人それぞれですが、私の場合スマホは時計代わりや天気予報等で頻繁に確認するので、移動中や勤務中であっても意外とONにしている時間は多いのです。裏を返せば(3)の真の節電モードに移行している時間が短いということですね。
ただ本当に忙しいときは確認する頻度も落ちますので、(3)に移行している時間が長くなっていると思います。
そのあたりの差が、ブレ幅のムラにつながっているのではないかと。
タグ:S Health
(Galaxy) S Healthの万歩計が使えない その3(2023/04/06) [Android&スマホ]
誤差が大きい場合、犯人捜しをするなら多数決を取るのが適当でしょう。
私はAndroid使いですが、知り合いと1日行動を共にする機会があったので、万歩計を有効にしたiPhoneを持たせてもらうことにしました。その結果、
Xiaomi Smart Band 7: 約11000歩
iPhone: 約10500歩
S Health: 約7000歩
でした。もう噴飯物ですね。誰が犯人か分かってしまいました。
Webを調べましたがS Healthのカウント精度については特に触れられておらず良いとも悪いとも書かれていません。利用者が少ないだけかもしれませんが。
そもそも私がスマホの万歩計アプリの歩数カウントの仕組みがよく分かっておらず、おそらく以下のどちらかではないかと思っています。
①S Healthが直接Andoroidの振動センサーを読み取り、S Health側でノイズカット等を含めた歩数カウントの集計を行っている
②Android側に万歩計API的なものがあり、S HealthはAPIを参照するだけで、直接振動センサーにはアクセスできない
仮に①とすると、S Health側で感度設定の項目があっても良いはずですが、特に見当たらないようです。②の場合、アプリが違えど歩数のカウントの結果としては全てが同一になるはずです。
また、スマホの省電力機能についてはずっと疑念が残っており、以前の調査でシロということにはなっていますが、ここまで差が出てしまう以上、かなり臭いと思っています。
省電力機能が働いてアプリの機能停止時間が発生する場合、①が歩数カウントに失敗するのは確実に分かります。②は問題なさそうに思えますが、APIの仕様によっては問題が生じます。前述の、全ての万歩計アプリで同一結果になるという理論も成立しなくなります。
具体的には、
②-1 APIがカウントアップの「トリガ」だけを連携する場合、アプリ停止中はカウントアップトリガが
読み取れず誤差が生じる(数を数えているのはアプリ側)
②-2 APIは歩数カウンタの「累計 絶対値」を読み取るだけ。アプリ停止時間が発生しても
最新の歩数カウンタが確実に読み取れるなら、引き算(差分)としては常に正常値になる
(歩数を数えているのはAndorid側)
ということです。
①もしくは②にしろ、実験してみる必要がありそうですね。
私はAndroid使いですが、知り合いと1日行動を共にする機会があったので、万歩計を有効にしたiPhoneを持たせてもらうことにしました。その結果、
Xiaomi Smart Band 7: 約11000歩
iPhone: 約10500歩
S Health: 約7000歩
でした。もう噴飯物ですね。誰が犯人か分かってしまいました。
Webを調べましたがS Healthのカウント精度については特に触れられておらず良いとも悪いとも書かれていません。利用者が少ないだけかもしれませんが。
そもそも私がスマホの万歩計アプリの歩数カウントの仕組みがよく分かっておらず、おそらく以下のどちらかではないかと思っています。
①S Healthが直接Andoroidの振動センサーを読み取り、S Health側でノイズカット等を含めた歩数カウントの集計を行っている
②Android側に万歩計API的なものがあり、S HealthはAPIを参照するだけで、直接振動センサーにはアクセスできない
仮に①とすると、S Health側で感度設定の項目があっても良いはずですが、特に見当たらないようです。②の場合、アプリが違えど歩数のカウントの結果としては全てが同一になるはずです。
また、スマホの省電力機能についてはずっと疑念が残っており、以前の調査でシロということにはなっていますが、ここまで差が出てしまう以上、かなり臭いと思っています。
省電力機能が働いてアプリの機能停止時間が発生する場合、①が歩数カウントに失敗するのは確実に分かります。②は問題なさそうに思えますが、APIの仕様によっては問題が生じます。前述の、全ての万歩計アプリで同一結果になるという理論も成立しなくなります。
具体的には、
②-1 APIがカウントアップの「トリガ」だけを連携する場合、アプリ停止中はカウントアップトリガが
読み取れず誤差が生じる(数を数えているのはアプリ側)
②-2 APIは歩数カウンタの「累計 絶対値」を読み取るだけ。アプリ停止時間が発生しても
最新の歩数カウンタが確実に読み取れるなら、引き算(差分)としては常に正常値になる
(歩数を数えているのはAndorid側)
ということです。
①もしくは②にしろ、実験してみる必要がありそうですね。
タグ:S Health
前の4件 | -