2018年4月28日土曜日

WXR1900DHP3 がフリーズするので接続方法を変えてみた

V6プラス設定するとフリーズが頻発するようになってしまったので、WXR1900DHP3 は一度リセットし、デフォルト設定のままで V6 接続するようにし、これには Mac のみを接続するようにしました(ファームウェアバージョンは V2.53 です)。

家庭内のネットはすべて WXR1900DHP3 から PPPoE スルー先の DD-WRT ルーターで PPPoE 接続し、WXR1900DHP3 の V6プラスが不調でも家庭内のほかのデバイス等に影響がでないようにしました。


WXR1900DHP3 は、

リセット → 電源SWオフ → 電源ケーブル抜き → 10分以上放置 → 電源ケーブル差込み → 電源SWオン → インターネット@スタートで V6プラス接続(NDプロキシ接続される)

にしました。



==============================================================

その前に WXR1900DHP3 での PPPoE を試してみました。

2日半ほど稼働させ、それだけで判断するのは難しいのですが、PPPoE 接続だと安定しているように思えます。

WXR1900DHP3 での PPPoE 接続での速度計測もしました。

以下はそのときの結果です。

4月27日 am 06:00 〜 4月28日 am 06:00 の1時間ごと(pm 06:00 〜 am 01:30 は 30 分ごと)の速度を測ってみました。


プロバイダは @nifty です。

我が家での状況をみると 70 Mbps 以上が、1日のうち 20 時間あります。

マンションタイプなのでフレッツネクストの NGN 基本性能は概ね 95 Mbps です。

インターネット接続状態で 90 Mbps 前後が実速度最大値ですから、@nifty はオススメできるプロバイダといえます。

@nifty 以前に使っていた某Bプロバイダは、よくて 40 Mbps 程度でしたからおよそ2倍で、かなり安定的な速度です(地域差はあると思いますが)。







グラフの左側の平坦なところは V6プラス接続時のもので速度は 90 Mbps 前後で安定しています。


そこから先(グラフの右方向)はかなり変動があり、それでも am 06:00 〜 pm 06:00 は 70 Mbps 以上です。

ところが夜になると段々と速度低下して pm 10:30 にはナント 3.08 Mbps まで低下していました。

再び 70 Mbps 以上に回復したのは深夜の am 01:00 です。


つまり、

  01:00 〜 18:00 70 Mbps 超
  18:00 〜 21:00   徐々に低下し 20 Mbps まで落ちる
  21:00 〜 23:30 さらに低下し最低では 3.08 Mbps(1回だけ。他は 10数 Mbps)
  23:30 〜   1:00 徐々に回復し再び 70 Mbps 超に戻る

という感じです。

21:00 〜 23:30(または 24:00 頃まで)の速度低下が著しい。


上り速度はどの時間帯でも 80 〜 90 Mbps 超ですので、こちらは問題ありません。


普段は、こんな時間帯にネットを使うことはまずないので(早寝早起きなので w)、実害(?)はないのですが、やはり V6プラスの高速安定性にはかないません。


ちなみに私のブログを閲覧くださっている方々のトラフィックは次のようになっています。



ネット速度が低下する時間帯にページビュー最大になっています。

1日の食事時間帯と思える am 06:00 頃、昼前・昼後、18:00 頃がトラフィックが少ない時間帯です。

概ね毎日、こういうトラフィック状況です。


ネット速度が夜遅くに低下する時間帯がやはりトラフィックも多いようです。

==============================================================




さて、冒頭のネット接続環境の見直しの件に戻ります。

WXR1900DHP3 側のアドレス空間はリセット時(工場出荷時)のままです。

一方、DD-WRT 側は、これまで家庭内アドレス空間としていたアドレス体系に変更しました。

これによって、家庭内の WiFi-AP や、WiFi- 中継機、ほかのデバイス等は変更はなく DD-WRT(PPPoE)の配下に入ります。

万一 WXR1900DHP3 のV6プラス接続が異常(フリーズやリブートなど)に陥っても DD-WRT 配下のネットワークへの影響はなくなります。


いままでは「 V6プラスがメイン/DD-WRT(PPPoE)がサブ」でしたが、今回これを逆に「 DD-WRT(PPPoE)がメイン/V6プラスがサブ」にしたわけです。

これには、Mac 以外は Linux PC も含めてすべてが対象です。



そして、Mac の LAN からは V6プラスとし、WiFi からは PPPoE 側がアクセスできるようにしました。

Mac だけは「 V6プラスがメイン/DD-WRT(PPPoE)がサブ」としました。



WXR1900DHP3 の不調でも DD-WRT の PPPoE は切れませんので影響は Mac のみになり、使っているとわかります。


これで暫くは運用してみます。




V6プラス自体は非常にオススメなのですが、WXR1900DHP3 が不安定で突然ネットが切れている、という状況に見舞われ、安心してこのルーターを V6プラス用で使えないのが非常に残念です。


バッファローには早くこの状況を打開してもらいたいものですが、ファームウェア V2.55 から一向に改善が進む状況が見通せません (´;ω;`)。


2018年4月25日水曜日

WXR1900DHP3 がフリーズを繰り返す

2018/04/24 に突然フリーズしました。

これまでに「いろいろ設定変更」などをしていて変更内容によっては V6プラスが強制的に再接続されるケースがあります。


設定変更はファームウェアを変えたり(v2.55 ←→ v2.53)、IP フィルターを設定・修正したり、DHCP をオン・オフしたり、ログの USB メモリへの記録を停めてみたり・再開してみたり、とにかくどういう設定が安定するのか、試しているのです。

つまりはまったく安定していないということです。

ですから、「いろいろ」試すしかないのです。

他に、これはという V6プラス対応ルーターがないので仕方ありません。



今年に入って以降、フリーズは以下のように発生しています。

 1月 2日:この日までは「勝手にブート」を繰り返す状態でした。
       それでリセット・10分電源オフで放置、電源入れ直しました。

 1月11日:1月2日以降で最初のフリーズ
 3月26日:2度目のフリーズ(この間2ヶ月半)
 4月 1日:3度目のフリーズ( 〃 6日間)
 4月17日:4度目のフリーズ( 〃16日間)
 4月20日:5度目のフリーズ( 〃 3日間)
 4月24日:6、7、8度目、と3回発生

徐々にフリーズする間隔が短くなり、昨日(4月2日)は3回も発生しました。

何なんでしょうか?


1月11日〜3月26日の間はフリーズは発生していませんが、設定変更やファームウェアの入れ替え等でブートをし直したり、V6プラス接続をやり直したりを、何回か行っています。




今朝(4月25日)はリセットをしてみました。


リセット後は、設定し直し・電源ボタンオフ・電源ケーブル抜き・10分間放置・電源ケーブル挿し・電源ボタンオン、として再起動しています(V2.53)。

ところがなぜか 接続設定を「V6プラス接続を使用する」としているのに接続後は「インターネット@スタート」になっています。

再度「V6プラス接続を使用する」にして再接続しました。


V6プラス接続されたのはいいのですが、ログにファイヤーウォール関連が記録されません。

そこで「管理設定」→「ログ」→「拡張設定・4項目にチェック」→「設定」して、強制再接続が走り、接続後からログにファイヤーウォール関連ログが記録され始めました。


思うに、MAP-Eルールテーブルの定期的な書き換えや、IP フィルター設定変更等で、これらが関連する NAT テーブルが壊れることがあるのではないか、その結果、これに関連したプロセスが暴走してフリーズするのではないかと思えます。


一旦フリーズぐせがつくと、電源オフオン(ケーブル抜き差し)では正常に戻らず、リセットするしかないように思います。

つまり、ブートのやり直しだけではテーブル類が初期化されないように見えます。
(考えれば当たり前のことか? せっかく設定した内容が初期化されては意味ないですものね)



過去には「勝手にブート」事象を繰り返す、ということもありました。

今回は「勝手にフリーズ」事象を繰り返す状態に陥り、事象こそ異なりますが、すべては NAT 関連テーブル破壊に起因するのではないか、と思えるのです。

あとは、資源(メモリ資源)の食いつぶし、セマフォの食いつぶしまたはセマフォロックがハズれないなども考えられますが、おそらくテーブル類が壊れてのことと思われます。

壊れ方によって、「勝手にブート」か「勝手にフリーズ」になると思います。


壊れる要因は IP フィルターの設定変更、MAP-Eルールの書き直しなどではないでしょうか。

その結果 NAT 関連テーブルが正常ではなくなり、異常事象につながっているのではないでしょうか。


DHCPdが関連してのフリーズがあるかも知れない、と以前に書きましたが、これは別原因かも知れません。


ファームウェアは V2.53〜V2.55 のどれでもフリーズ事象は発生します。

根本的な問題が解消していないからと思われます。



V2.54 は後退し、V2.55 で修正されたかのように思えますが、MAP-E ルールの受信は V2.53 が一番安定しています。

それで V2.53 で使っています。


またしばらく様子見です (’;ω;’)

いったいいつになったら安定ファームウェアがでるんだろう・・・・・





【追記】

4月25日 14:02 にまたフリーズしました。

どうもフリーズぐせが治らない。

一回、V6プラスを離れて PPPoE で接続してみることにしました。



これを書いている時で PPPoE 接続開始から22時間以上経過していますが、稼働継続しています。

この状態で1週間程度は様子見してみます。


まぁ、PPPoE でも 65 Mbps 〜 85 Mbps の速度はでていますので V6プラスと体感的には差は感じません。







気になったことでは、LAN → WAN 方向のパケットで破棄されるものがあり、これが結構な量、ログに記録されます。

これは V6プラスだけの現象かと思っていましたが、PPPoE でもでます。


破棄されるパケットは Ephemeral Port で外へ出ようとするパケットです。

V6プラスでも同じく Ephemeral Port からのものが破棄パケットですので、このルーターは Well-known Port 以外は問題があるとみなしているのでしょうか。


V6プラスの場合と少し異なるのは、V6プラスの場合 Ephemeral Port のうちの 240 個の割当てられたポート以外がブロックされているということです。




少し調べてみました。

推定は、次のようなシナリオです。

① スマホやタブレットのアプリが通信の際に送信元ポートとして Ephemeral Port を
  使っているのではないか。
② WXR1900DHP3 は Ephemeral Port からの送信リクエストは拒否しているの
  ではないか。

  また、V6プラスの場合、割当てられたポートは通過なので、割当てられたポート以外
  が拒否されているのではないか。


本来ならば、ルーターの NAPT によって、例えば [443 ➡ Ephemeral Port] に変換 してリクエストするはずですが、Ephemeral Port からの送信リクエストは変換しようがないので、弾くと思われます。

アプリが自由に使えるポート番号はこの Ephemeral Port です(Linux の場合 32768〜61000。IANA 勧告は 49152〜65535)。

WXR1900DHP3 は Linux ベースなので 32768〜61000 を Ephemeral Port としていると思われます。

 
沢山あるアプリがそれぞれ勝手に Ephemeral Port を使っていると思われ、これがルーターから外向きに出ていくパケット破棄につながっていると思います。




送信元から送信先にそれぞれ、どのポート番号を使っているかをパケットキャプチャーしてみます。


そのための準備として

タブレット ➡(WiFi)➡ MacBookAir ➡(LAN)➡ WXR1900DHP3 ➡ インターネット

という環境を準備します。

MacBookAir は Wireshark を起動します。

タブレットの方は NoRoot Firewall を起動してすべてのアプリについて保留設定しておきます。


この状態で、タブレットのアプリを起動します。

アプリの通信は NoRootFirewall で保留されます。

次にこのアプリの保留を解除します。

そうすると、Wireshark に通信状態がキャプチャーされます。

これを見たところ、確かに Ephemeral Port から 443 や 80 に向けてパケットが飛んでいます。




推定を裏付ける結果です。

ですが、破棄ログが大量に吐き出されるのは非常に煩わしい。


この推定どおりならば、外向きはすべてのポートに対して IP フィルターで許可設定すれば破棄はないのでログには記録されないことになります。










2018年4月22日日曜日

IPv6 サイトへのアクセスを確認する方法

IPv6 サイトへのアクセスができているかどうかを確認するには www.iijmio.jp にアクセスすると確認できます。

このサイトは IPv4 での接続か IPv6 での接続かをホームページ上で知らせてくれます。


【iijmio.jp の HP より抜粋】

■アイコンについて

v4アイコン お客様がIPv4ネットワーク経由でIIJmioのWebサイトをご覧になっていることを示しています。
v6アイコン お客様がIPv6ネットワーク経由でIIJmioのWebサイトをご覧になっていることを示しています。



V6プラスで接続・表示の事例

















www.iijmio.jp にアクセスして、一番上の ログイン の右側部分に

 CONNECTED  Via IPv6  とあれば IPv6 でのアクセスができています。

IPv4 の場合は  CONNECTED  Via IPv4  となります。



ちなみに、ブラウザの URL アドレスバーに www.iijmio.jp の IPv6 アドレス を大括弧 [ ] でくくって [2001:240:bb81:8b00::85] を入力することでも確認できます。

この場合、サイトが IPv6 に対応している場合はちゃんとホームページが表示されますが、対応していないと何も表示されません。


IPv4 の場合は直接に IP 指定の場合、160.13.17.45(www.iijmio.jp の IPv4 アドレス)と入力しますが、IPv6 の場合は [2001:240:bb81:8b00::85]とするわけです。


iijmio.jp の場合、IPv4 アドレス 160.13.17.45 または、www.iijmio.jp のいずれを入力しても、自ネットのインターネット接続が IPv6 ならば   CONNECTED  Via IPv6  になります。

逆に自ネットのインターネット接続が IPv4 ならば   CONNECTED  Via IPv4  になります。



V6プラス接続設定しているはずなのに  CONNECTED  Via IPv4  となる場合は、ルーター設定を誤っていますので見直しをしてください。






2018年4月21日土曜日

GS Wave にアップデート

2018/04/01 に 1.0.2.21 にアップデートされていましたが、04/20 付アップデートで 1.0.3.8 になりました。


1.0.2 から 1.0.3 に変わっていますが、基本機能に変更はありません。



❏ 1.0.2.20 ➡ 1.0.2.21(前回)
 ・カラーテーマの追加

❏ 1.0.2.21 ➡ 1.0.3.8(今回)
 ・GDS Early Media
  GDS3710という IP ドアフォン(企業の受付などに置いてあるドアフォン)との間で
  アーリー メディアをサポートするということのようです。

  このデバイスは内線 IP 電話 として各個人ごとに導入も可能なようですので、こういう
  利用法を想定してのものと思われます。


GDS2710


  SIP におけるアーリー メディアは、呼出し接続する前、メディアがフローを開始した
  ときに定義されます。
  メディア チャネルは、コール接続の前にセットアップされます。
  これらのチャネルは、発信側に聞こえる呼出音を提供するために使用されます。

  ドコモのメロディーコールと同じですね。

  GDS3710 側で設定した呼出音を切り分けて呼び出し元の GS Wave に知らせると
  いうことでしょう。

  詳細不明ですが、部署ごとまたは個人ごとに GDS3710 を設置した場合に、呼出音
  を変えるとかに使うのではないかと思われます。


  GS Wave を IP 電話のソフトフォンとしての利用では使う場面はないと思います。


 ・IPv6 サポート
  すでに欧州では IPv4 アドレスが枯渇、他地域でも現実的にすぐに枯渇に向うでしょう。

  そのために IPv6 化は焦眉ですが、ITSP の IPv6 化に備えてのアップデートと思われ
  ます。

  国内の ITSP は現時点ではまだ IPv4 ですがいずれ IPv6 化は避けられません。


  IPv6 問題はスマホに割当てられる IP アドレスがグローバルアドレスの場合、これもいずれ
  枯渇しますのでキャリア側でも IPv6  化は必須です。



ちなみに、FQDN で IPv6 アドレスを引くにはターミナルから次のようにします。

通常の IPv4 を引く場合:

 $ nslookup
 > www.ocn.ne.jp
 Server:        1.1.1.1
 Address:    1.1.1.1#53

 Non-authoritative answer:
 Name:    www.ocn.ne.jp
 Address: 153.254.170.142
 >

IPv6 を引く場合:

 $ nslookup
 > set type=AAAA  ← DNS のタイプを IPv6 に設定して引く
 > www.ocn.ne.jp
 Server:        1.1.1.1
 Address:    1.1.1.1#53

 Non-authoritative answer:
 www.ocn.ne.jp    has AAAA address 2001:218:200d:253:153:254:170:142

 Authoritative answers can be found from:
 >

この例では 2001:218:200d:253:153:254:170:142 が IPv6 アドレスです。



当然ですが、IPv6 アドレスがない場合は、IPv6 アドレスは表示されません。

IPv4 アドレス引きに戻すには、

 > set type=A ← DNS のタイプを IPv4 に設定して引く

とします。






 


2018年4月8日日曜日

WiFi と SSID 設定

ルーターや無線 LAN AP(アクセスポイント)で WiFi を使うときにデフォルトで使っていませんか。


これは侵入や乗っ取り被害のリスクを高めてしまいます。

私の住むマンションでも下・左・右の住居からと思われる WiFi の電波が飛んできますが SSID はデフォルトで使っている人たちばかりです。
メーカー名がわかります。

また、パスワードすら変更していなくてデフォルトの "password" などをそのまま使っている人さえいます。

よそのルーターに簡単にログインできちゃうケースもあるのです。


デフォルトのまま使っているところは IP アドレスもデフォルトのままなので簡単に入れちゃうのです。

いまの WiFi 機器は WPA2/AES 設定されているのが当たり前になっていて暗号化キーは破りにくいのですが SSID2 が WEP のままだと、割りと簡単に破れ、ログインできちゃえば何でもやりたい放題です。

ゲーム機を使っている人たちの中には、そのような設定の人たちは少なくありません。

IT リテラシーの乏しい一般の方々はマニュアルも殆ど読まないのでしょうね。

購入した機器に設定ガイドは附属していても取説(マニュアル)は大抵の機器には附属していなくて Web で製品サイトを検索しダウンロードして見なくてはならないことが、こういう方々には面倒なのでしょう。


結論的にいいますと SSID は,

 "数字_文字列_nomap"

のような名称がいいと思います。
文字列は複雑である必要はありません。

SSID はどうせアクセスポイント名としてわかってしまうからです。

ですから逆にわかりやすい名前付けでいいと思います。

先頭の数字は WiFi リストの上位にもってくるために付加します。
自分が見つけやすいからです。


後ろの "_nomap" は Google に位置情報を記録させずにオプトアウトする設定です。

Google の位置情報サービスに登録されたアクセス ポイントを管理する



上のサイトにオプトアウトする方法が記載されていて "_nomap" を付加するように記載されています。



SSID のステルス設定はオススメしません。

これは、

 ・ステルス設定しない場合と比して接続手順が少し複雑になること
 ・子機側が常に SSID を探すことになるので、隠蔽したはずの SSID を知らしめる
  ことになること

からです。

つまり有効なセキュリティ対策にはならない、ということですね。



WPA2/AES の暗号化キーは重要です。

しかしながら 8 桁あれば十分で、英数大小文字混在のランダム性の高い文字列であればまず問題ないでしょう。

"ランダム文字列 8桁" でネット検索してみるとその有効性が高いことがわかります。

英数大小文字では 62 種の文字列の組み合わせになります。
この組み合わせ数はとてつもなく大きい数ですので、まず一致させることは極めて困難です。



ルーターの ID は変更できる機種とできない機種がありますが、変更できる場合でも ID よりもパスワードが大事です。


パスワードもまた、8桁あれば十分で、英数大小文字混在のランダム性の高い文字列で先の WPA2/AES とは別の文字列にするといいでしょう。


SSID と違い、暗号化キーやパスワードはこのランダム性と組み合わせ数が非常に重要です。

ひと昔前は記号を含めるとか、定期的にパスワードを変更せよ、とかいわれていましたが、いまは逆に変更はせずに記号も要らない、といわれています。

組み合わせ理論からすれば "8桁の、英数大小文字混在のランダム性の高い文字列" で十分だからです。


変更は、変更時にキャプチャーされるリスクを伴いますからインターネットを遮断して行うことです。






WiFi Analyzer というスマホ用アプリがあり、WiFi 電波強度やチャンネルの混み具合などがわかって大変重宝しますが、2018/04/07 のアップデートで位置情報を有効化しないと使えなくなってしまいました。

これって、すご〜〜く問題ですよね。

速攻でアンインストールして、WiFi Analyzer Classic を使うように変えました。

同じ製造元ながら Classic はいまのところ位置情報はオフでも使えます。