2018年1月30日火曜日

wxr1900dhp3 が LAN -->> WAN でパケット拒否ログを大量に吐く問題

本件は以下のような処理の過程で発生しているのではないか?

と、バッファローに本日問合せています。

話せば長くなるのでいきさつは割愛しますが、LAST_ACK が絡んでいそうだ、ということで次のことを試してみました。
====================================================

端末側で netstat したときの結果(何度か行い LAST_ACK 状態を検出したときの結果)と不要ログ(LAN 側から外向きのパケットが Deny になるログ)を突き合わせてみました。

u0_a301@K00R:/ $ netstat -an
Proto Recv-Q Send-Q Local Address          Foreign Address        State
tcp       0      1 192.168.xxx.yyy:51454   31.13.82.36:443        LAST_ACK
tcp       0      1 192.168.xxx.yyy:51452   31.13.82.36:443        LAST_ACK
tcp       0      1 192.168.xxx.yyy:49140   31.13.82.1:443         LAST_ACK
udp       0      0 0.0.0.0:1900           0.0.0.0:*              CLOSE
udp       0      0 0.0.0.0:1900           0.0.0.0:*              CLOSE
udp       0      0 0.0.0.0:1900           0.0.0.0:*              CLOSE
udp       0      0 0.0.0.0:1900           0.0.0.0:*              CLOSE
udp       0      0 0.0.0.0:1900           0.0.0.0:*              CLOSE


u0_a301@K00R:/ $


上記の LAST_ACK 状態時に、LAN 側からの外向きのパケットがファイアウォールではじかれたときのログは次のとおりです。

2018/01/30 10:52:37 <141>[MACアドレス] APabcdefghijkl : FIREWALL: TCP connection denied from 192.168.xxx.yyy:51454 to 31.13.82.36:443 (br0)
2018/01/30 10:52:37 <141>[MACアドレス] APabcdefghijkl : FIREWALL: TCP connection denied from 192.168.xxx.yyy:51452 to 31.13.82.36:443 (br0) 
2018/01/30 10:52:37 <141>[MACアドレス] APabcdefghijkl : FIREWALL: TCP connection denied from 192.168.xxx.yyy:49140 to 31.13.82.1:443 (br0)

Ephemeral Port からの要求がはじかれています。


これらの結果から考えられるシナリオは、以下のようなことと推察しました。

--------------------◇--------------------◇--------------------◇--------------------

Web 等のプロセスが終了時に戻りパケットを待つ LAST_ACK 状態に遷移する。

通常ならば、すぐに FIN+ACK(戻りパケット)が戻ってきて CLOSE 処理へ遷移するが、
例えばネットワーク遅延や負荷がかかっていたりした場合、戻りパケットが届くまでに
時間がかかってしまう場合があり、ここでタイムアウトしているのではないか?
SPI(ステートフル・パケット・インスペクション):keep-state の FIN の戻りパケットを許可するタイムアウト時間はデフォルトの1秒と思われる。

この時間を過ぎると、ファイアウォールが閉じて戻りパケットを受け入れてくれない。

そのため、FIN+ACK(応答パケット)が戻ってこられない。
FIN パケットを送った Web 等のプロセスは戻りパケットを待ち続けるが、LAST_ACK になった。

このときに Web 等のプロセスは FIN パケットを一定時間再送し続ける。

(20秒間、2秒ごとに再送し続けているようです)

上記のような不要ログ(同じ内容のログ行が複数行続く)は連続的に吐かれていることもこの推定を裏付けていると思える。

しかしその FIN パケットもすでにタイムアウト時間を過ぎてしまっているためファイアウォールにはじかれているのではないか?


これが「不要ログ」として記録されていると思われる。
--------------------◇--------------------◇--------------------◇--------------------


Web 等の実際的な処理は済んでいて、終了処理中のできごとなので実害はないように思われるが不要ログが大量に吐かれることになっていると思われる。

また、IP フィルターで「LAN-->>WAN:80,443,993 等を通過設定」するとこれらの不要ログがなくなることも、推定を裏付けていると思える。


本事象ならば、FIN パケットのタイムアウト時間を 1秒から 3秒程度にすると殆どが解消すると思われる。

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

と、バッファローに問合せました。



推定間違いかもしれませんが、どういう反応があるか注視したいと思います。








2018年1月26日金曜日

wxr1900dhp3 のファームウェアを Ver.2.53 に戻しました

wxr1900dhp3 は未だにバグが解消しません。


【2018/03/26 追記】フリーズしました

DHCP 機能をオンにした 3/12 (月) 15:43 から 丁度 2週間経過した 3/26 (月) 15:43 にフリーズしました。

DHCP のリースタイムは 24 時間設定にしていました。
また、同じ時間で NTP 更新もされますが、こちらも更新間隔は 24 時間の設定です。

フリーズは DHCP デーモンが疑われますが、NTP クライアントもシロとはいえません。
時間的に符合するのはこの二つですが、ログにはそれらしき痕跡が残っていませんので類推の域を出ません。

いずれにせよ、フリーズ事象が再発したわけです。

何かのリソースの食いつぶしと思われ、やはり DHCP デーモンの疑いが濃厚な感じがします。

気づいたのは 3/26 18 時を過ぎていて、電源断から 10 分以上経って再起動しました。
V6 Plus 接続は 18:30 になっていますので、また経過をみたいと思います。


各種設定は異常となる要因を避けた設定で使用していますので、一応安定動作はしています。

 ○ DHCP はオフにしてオンですが固定アドレスで使用
 ○ 無線LAN はオフ
 ○ セキュリティ : ファイヤウォールはすべてオン
   IP フィルター : 80/443/993/8080 について中から外向きを通過設定(不要ログ防止策)
   PPPoE : パススルー
   その他機能はすべてオフ
 ○ アプリケーションはログの USB メモリへの自動記録と共有可能にしている以外はすべてオフ


バッファローには発生事象と、わかる限りの状況や想定される発生契機などを詳しく伝えていますが、まだ明確に答えはきていません。



Internet --> Internet --> インターネット@スタート でないと繋がらない問題は Ver.2.55 で修正した、という連絡はもらいましたが、これは Ver.2.53 では問題がなかった項目です。


しかも MAPe ルールの更新間隔は Ver.2.53 では JPNE との仕様どおりに3時間ごとに行われていますが、Ver.2.54 も 2.55 も更新間隔は 4〜24時間と不規則なままです。


つまり MAPE 方式に限れば Ver.2.53 から改悪になっているわけです。



この Ver.2.53 後のアップデート(グレードダウンにしか見えない)は次の内容です。

●Ver.2.55 [2018.1.10] 【不具合修正】
  以下の設定を両方とも行っている場合、v6プラスに接続できなくなることがある問題を修正しました。 
・[詳細設定]-[Internet]でIPアドレス取得方法に「v6プラス接続を利用する」を選択している。 
・[詳細設定]-[IPv6]でIPv6接続方法に「NDプロキシを使用する」または「IPv6パススルーを使用する」を選択している。

●Ver.2.54 [2017.11.1] 【不具合修正】 
・一部のフレッツ光回線において、IPv6のDNSサーバーアドレスが取得できない問題を修正しました。 
・v6プラスが利用できる回線において、フレッツ網側の状況に依存し、まれに回線自動判定が正常に  動作しなくなる問題を修正しました。 
・干渉波自動回避機能が有効である場合、本製品の周辺にマルチバイト文字を含んだSSIDが  設定された無線親機を検出した場合、本製品の無線が使用できなくなることがある問題を修正しました。 

【機能追加】
 ・IPv4マルチキャストプロキシ機能を追加しました。 
・ビッグローブ株式会社の「IPv6オプション」対応しました。


どうも 「ビッグローブ株式会社の『IPv6オプション』対応しました」というあたりに問題があるのではないかと推測しています。

接続関連ではこの対応が一番怪しく思えます。


そこで、Ver.2.53 に戻してみることにしたのです。


以前に Ver.2.53 に戻したときに「勝手に Boot 問題」が発生していましたが、これは NVRAM に保持された何かが悪さしていると考えて、完全放電状態にして使うようにして解消した、と思っていましたので、Ver2.53 に戻したときもこの手順は踏襲しました。


その結果、一応安定動作し、MAPe ルール更新も3時間ごとに行われています。


Ver.2.55 でまる13日間、接続状態を保持してはいましたが、いろいろ考えた結果、Ver.2.53 に戻すのが一番安定する、と考えた次第です。


それはバッファローの「アップデート」が「ダウングレード」でしかないということに思いが至ったせいです。



バッファローは、一旦 Ver.2.53 に戻り、そこから問題を解消し直すような修正に戻すべきだと考えます。


悪い修正に修正を重ねても事態はちっとも解消していかないと思います。




LAN から WAN へのアクセスブロックログが大量に吐かれる問題は相変わらずあります。


IP フィルターで 80/443/993/8080 を「通過」設定すると不要ログはなくなります。


そういう設定をしていいかどうかの判断が難しいのですが、LAST_ACK 問題ならば影響はないと考え、とりあえず設定して大量の不要ログ吐き出しを防止しています。


この不要ログは全ログの 90 % 以上を占めており、実に煩わしいのです。。。。。






2018年1月18日木曜日

孫にも WLAN


仏に住んでいる娘一家の長男の部屋が、Orange Box(Orange S.A. : 旧 France Telecomの HGW のような無線ルーター)の置いてある居間から離れていてネットスピードが遅いと嘆いていた。

PLC でつないでいたそうだが 1Mbps がやっとみたいだった。

PLC は同じ分電盤配下の系列でないと期待したほどにはスピードはでない、というとどうすればいい? というので・・・・・


 一昨年帰省した折りに調べて Free Mobile が SIM フリーで格安、しかも 100GB/月
 まで使えて 20 ユーロ/月額だから、これを契約して使えばいい、と(当時は最大 50
 GB)。


 ただ、孫の iPhone は Orange の縛りがあって SIM フリー化は制約があるという。


 それなら、Android 端末(SIMフリー)の空いている1台を渡すから、これに Free
 Mobile の SIM を挿してテザリングすれば Mac も iPhone も iPad も使えるよ、と
 いって持ち帰らせた。

・・・・・


一応これはこれでよくはなって 20 Mbps はでているようだけど、100GB 使い切ることもあるらしく、使い切ったあとが遅くなり困っているようだった。

100GB を使い切るのは音楽や動画、ゲームなどをやるせいだろうけど今の若者には友だち付き合い上、必要なんでしょうねぇ。

また、意外とバカにならないのが iCloud や Google Drive などのクラウドの同期などでバックグラウンドで消費されるパケット量の問題も大きい。

バックグラウンド通信は今の PC や Mac、スマホでも問題の通信ですが、完全に止めるのは今は難しい。

スマホの設定やアプリケーションフィルターである程度は可能だが、イタチごっこみたいなところがあってネットを使う以上は必要悪と割り切るしかないのかも。

  ➡ 誰かいい知恵があれば是非に教えて頂きたいものです。
  スマホの場合 Noroot Firewall、Mac の場合 Radio Silence も試しましたが、
  ホントにイタチごっこです。

  いま、tripMode を試していて、これは割と使えるかもです。
  使い方が上の二つに比べてとても簡単で、9割位はブロックできそうです。



横道にそれちゃいましたが、本題に戻します。

帰省した折に渡そうと思っていた whr-600d ✕2台に無線LAN 親機と子機設定して、オレンジボックスにつなげばいいようにして航空便で送った。


今年9月には英国の大学にいく予定だから、半年間しか使わないのだけれど英国から仏に大学が休みに入って戻ったときなどに便利だからまぁいいか。


あるいは、英国の大学の寄宿舎で使うことがあるかも知れないし。



こんな感じ。


設置方法など説明文書も日本語で多分大丈夫だけど、英語の方が間違いないと思い作成して印刷し一緒に送った。

デフォゲのアドレスを確認したので電源つなぐだけでお互いにつなぎ合うように、何も設定しなくてもいいようにしてあります。




それで結果は、というと相変わらず低速状態みたいです。

距離が遠すぎてスピードが上がらない問題もありそうですが、Orange 自体のネットスピードが激遅らしいのです。


諸外国は、私が使っている V6Plus のようなサービスではなく、V6 へ移行途上、という状況のようですし、V6 にしたからといって早くなる保証はなさそうですし。


国内の V6 プラスはユーザー数がまだ少ないので JPNE をはじめとする VNE 各事業者は今のところスピードを確保できていますけど、この先ユーザーが増えたときのスピード低下は懸念されます。


それにしても孫のネット環境、どうしたもんかなぁ・・・・・





【2018/05/05 追記】

少しは改善されたそうですが、まだ遅い状態は続いているようです。




以前は1Mbps 程度だったらしいので、孫にいわせれば「よくなったよ」ということだそうですが、我が家が何倍も速いのを知ってすごく驚いている。

大もとのオレンジボックス(オレンジのルーター)のところでどれくらいのスピードなのかがわからないので、なんともいいようがないのですが、おそらく改善可能と思っています。

でもネットワークオンチなので、どうしたらいいかなぁ。










2018年1月11日木曜日

wxr1900dhp3 のファームウェアアップデート


1月10日付アップデートが公開されました。


変更内容は次のようになっています。

--------------------------------------------------
Ver.2.55 [2018.1.10]【不具合修正】以下の設定を両方とも行っている場合、v6プラスに接続できなくなることがある問題を修正しました。 ・[詳細設定]-[Internet]でIPアドレス取得方法に「v6プラス接続を利用する」を選択している。・[詳細設定]-[IPv6]でIPv6接続方法に「NDプロキシを使用する」または「IPv6パススルーを使用する」を選択している。
--------------------------------------------------



確かに、修正内容のとおり ver2.54 で「V6プラス接続」では接続できなかったのが接続できるようにはなりましたが、これ以外のもっと重要な問題はまだ修正されていません。


今回の修正は、とりあえず「インターネット@スタート+NDプロキシ」で回避できていた問題です。


これは ver.2.53 から ver.2.54 へのアップデートのバグは明らか。
元に戻っただけのことです。



ですがこんなことよりも、「突然フリーズ問題」、「突然 Boot 問題」、「不要ログ問題」などの方がもっと重要です。


バッファローはもっと真剣にバグ修正に取り組んで欲しいものです。

発生した問題点は発生時の条件など、詳しく伝えてあるのですがナシのつぶてです。

➡ 1月10日に再度問い合わせましたところ1月12日に返信がありました。


 基本的には指摘した内容の不具合を認めた上で、再度調査協力依頼が責任者といわれる
 方からありました。

 また、今回のファームウェアアップデートで「V6 プラス接続」の NG が修正されて
 いるということも触れられていました。


結論的にいいますと ver.2.55 にはアップデートしていません。
ver.2.53 で使用しています。




2018年1月10日水曜日

V6プラスと PPPoE 接続での速度比較(2018年1月上旬測定)


@nifty の PPPoE も悪い数字ではありません。

1日を通して概ね5〜60 Mbps でています(深夜帯以外は)。

測定は、PPPoE ルーターに PC (Linux) を LAN 接続して測定しました。

たまに 10 Mbps くらいに低下することはありますが、引き続いて測定するとほぼこの水準に戻っている程度なので、問題はありません。


@nifty 測定値
IPアドレスは @nifty 払い出しのアドレス












@nifty 測定履歴




















以前の某Bプロバイダはもっと低い数字でしたから @nifty は結構いい線いっています。

ping 値も以前は 15〜18 ms でしたからこれも改善されています。

@nifty はお薦めしていいプロバイダでしょう。









V6プラスの方は概ね 88〜92 Mbps です。

これは当マンションの共用部ルーターの性能限界値に近い数字ですから、これ以上にはなりません。

もっと最新型のルーターだと 100 Mbps を軽く越えるらしいのですが、NTT 東は故障でもしない限り交換はしないそうです。


こちらの測定は WXR1900DHP3 の 5GHz 無線LAN 接続の Mac での測定値です。

LAN 接続だともう少し上がります(+2〜3Mbps)。


v6プラス測定値
IPアドレスは JPNE 払い出しのアドレス


v6プラス測定履歴



V6 プラスは非常に安定的な速度で、いつ測っても殆ど同じ水準で速度低下はありません。



まぁ、どちらで使っても体感速度は違いを感じませんから、いい方だと思います。


今のところは V6 プラスにするほどでもありませんけど、先々はわかりません。







ビフォー・アンド・アフター

ルーター周りを少し変えました。

左がビフォー、右がアフターです。

写真では見えませんが、ボードの、ルーターのアンテナ部の裏側にはアルミ箔を貼ってあり、反射器の役割をさせています。

反射器を付加すると 10dbくらい電波強度が改善します。

WLAN は 2.4GHz で波長は 11.8 cmなのでアンテナから 3cmくらい離れる位置に反射器を配置するのがちょうどいい感じです。

もちろん 5GHz でも有効です。


現在はメインルーターの無線LAN はオフにしています。










これまでは wxr1900dhp3(V6プラス用)だけを使っていましたが、いろいろ対応
した結果 wxr1900dhp3 は安定してきたようなので、今回 PPPoE ルーターを追加
しました。


 dd-wrt ルーターには OpenVPN サーバー機能も入っていますので、これを使うため
 でもあります。

 空いているのに使わないのは無駄ですから。


 メインルーターは wxr1900dhp3 のままですが、PPPoE パススルー設定してあり、
 後段に dd-wrt ルーターを PPPoE ルーターとして配置しました。


 またこの dd-wrt ルーターは DDNS、OpenVPN サーバーとしても動作しています。


 元は whr-300hp2(リサイクルショップで 2,000円で購入)ですが、バッファロー
 ルーターは WAN / LAN の MAC アドレスが同一なので、戻りの LAN をそのまま
 メインルーターに接続すると arp がループしてうまくありませんので、NVRAM 上
 で LAN 側の MAC アドレスを変更してあります。


 バッファローの純正ファームウェアの場合は、 MAC アドレスは WAN 側を変更
 できますが、dd-wrt はチョッと仕組みが違うのでコマンドで LAN 側を変更します。


 こうすることで、すべて同じローカルアドレス空間に属させ、メインルーターもサブ
 ルーターも自由にアクセスできるようにしてあります。


 右下の小さな黒い箱は ATA(HT701)で、ブラステル電番をアナログ電話機で使う
 ためのモノです。

 
 スマホにもブラステル電番は登録してありますので(Grandstream Wave)、ウチで
 もソトでも自宅の電話は受けられますが、家族用には一応アナログ電話機の方がいい
 かな、と。


 その上の小さい箱は Raspberry Pi3 B で、Asterisk を収容してあります。


 接続された機器類をどちらのルーター配下で使うかは、デフォルトゲートウェイで使い
 分けます。


 現在 Linux PC のみ dd-wrt ルーターで使い、それ以外はスマホを含めてメインルー
 ターで使っています。


 接続上は ATA / Raspberry Pi3 B は dd-wrt のポートに挿していますが、デフォルト
 ゲートウェイは メインルーターなので、dd-wrt の LAN ポートは HUB としての扱い
 です。








2018年1月4日木曜日

V6 プラス接続用 WXR1900DHP3 の「勝手に Boot」問題

最新ファームウェアは 「2017-11-01 Ver.2.54」ですが、いろいろ問題があるので
一つ前の Ver.2.53 に戻しました。

戻す前は Ver.2.54 でまる5日間、フリーズもなく稼働はしていました。

DHCPサーバー機能をオフにしたことで「フリーズ事象」はなくなった、と考えています。


しかしながら、Receive rule が3時間毎ではなく数時間〜24時間くらいの間で一定しないのが気に入らなくて Ver.2.53 に戻すことにしたのです。



ファームウェアを戻すと初期化状態になりますので再設定します。


 12月26日(火)11:06 ファームウェア戻した後の V6 プラス再接続


戻してみると MAPe の Receive rule は3時間ごとに行われています。

Ver.2.54 では時間間隔が一定していませんでしたし、チェックした範囲での最短でも 7時間、最長は約 24時間後でした。



Ver.2.53 でも DHCP サーバー機能はフリーズ事象を避けるためにオフ にしています。



また、Ver.2.54 では Internet -->> Internet -->>「V6 プラス接続を使用する」では接続できない状態でしたが、Ver.2.53 ではチャンと機能します。

これにより再接続時の回線種別判定がなくなります。



LAN からのバックグラウンドでのインターネットアクセス時に大量の不要ログを吐く問題は、どちらのバージョンでも解消しません。

平均的に1件/1分間くらいなので絶対量はルーターの性能に影響するほどではないのですが、その他の有効なログが埋没して、稼働状況を見極めるのにはログスクロールするのが長くて支障をきたします。


これは、ブラウザのアドブロックデバイス側を VPN を通すことで CE での処理対象外にして不要ログの吐き出しをしないようにできます。

最初は operaVPN が手軽かな、と思いましたが接続先が海外(シンガポール)なのでスピードがかなり低下します。

また、某国の企業に買収されたので情報漏洩の面でちょっと不安もあります。


有料版ならばノートンセキュリティが一番信頼がおけますが、無料版はさほど選択肢がありません。


そこで国内サーバーを扱っている OpenGate を利用することにして、クライアントアプリもそれに合わせて次のようにします。


 スマホ、タブレット:OpenGate OpenVPN Connect
 Mac         :OpenGateTunnelblick


接続先の速度に依存します。

不要ログは激減しますが、まだ少し出ます。


ただ、OpenGate はつながったり、つながらなくなったりと安定しません。

これは、公式にサーバーサービスしているわけではないので、停止していたりして常時使える状態を保障していませんから仕方がないのかも知れませんが、常時接続には向きません。

operaVPN の方が安定性は抜群ですが、スピード低下と某国系という安全面の不安が・・・

また何のために V6 プラス にしてるのか、ということもあり早々に VPN は止めました。



その結果不要ログはいまだに発生しています。
ファームウェアが改修されるまで仕方がないと諦めました。



Ver.2.542.53 よりも問題が増えており、何のためのファームウェア更新なのか? とっても不思議、というかバッファローの V6Plus 対応への今の混乱ぶりを物語っているのかも知れません。

一日も早くこれらの不具合を修正したファームウェアを出して欲しいものです。






ところが・・・

Ver.2.53 で突然 Boot する事象が発生、再接続はすぐに行われるのですが、なぜなんでしょうか。

ログにはそれらしき痕跡はありませんので原因は不明です。

勝手に Boot 後の接続から概ね、30〜40時間経過すると発生します。
また一度発生してその Boot 後に一旦接続された 2〜3時間後にまた勝手に Boot が走るのです。


ルーターにリークでもあってそれで Boot に走るのでしょうか。
Boot 後でも1日保たずに繰り返しますので、何か保持した状態があって、それが悪さをしているのでしょうか。
リセットもしましたがこの「勝手に Boot 事象」は解消しません。


フリーズ事象」がなくなった、と思ったら今度は「勝手に Boot 事象」発生です。


結局 V.2.54 に再びアップデートしたのですが、こちらのバージョンにしてもなぜか最初の Receive rule のしばらく後で Boot が走るクセがついたような感じになってしまいました。

バージョンの違いが原因ではないようです。

無線をオフにしたり、1週間いろいろ試行錯誤しますが、「勝手に Boot 事象」は解消しません。



考えた挙句に、買ってきた状態からの手順を踏んでみることにしました。

つまり、完全に電源を切ってメモリやコンデンサーなどが不揮発で残らないような状態に戻すわけです(完全放電状態)。


1.まずはシャットダウン(背面のボタンで電源オフにする)。

2.一旦電源ケーブルも抜きます。

  「電源ボタン」オフでシャットダウンから10秒程度待って、オンにして再起動しても「勝手に Boot 事象」が発生するからです。

  「電源ボタン」がいわゆるパワーオフ/オンになっていないようなのでいま一つ信頼が置けないのでケーブルも抜いたわけです(考えにくいことですが)。

  なぜこの機種に「電源ボタン」があるのか、どういう意味があるのかは不明です。
  これまでのバッファローのルーターには付いていません。

  以前に発生していた「フリーズ事象」の場合は「電源ケーブル」を抜いて、再度差し込まないと再起動できませんでした。

  でも、電源ケーブルの抜き差しで起動はできています。

  なのに、なぜ「電源ボタン」があるのか?

  例えば「USBメモリを Unmount してから抜いてください」に似た動作があるのでしょうか(書き出し処理が完了していないような動作)。

  WindowsPC でよく出ていたブルー画面で「ちゃんとシャットダウンしろ」みたいな身勝手なことでもあるのでしょうか。
  「オレはチャンとシャットダウンしたいのにお前が勝手にブルー画面になっているのに、そのメッセージはクソだ」みたいなことです。

  背面のツメは「Manual」、「Router」にしておきます(最初からしていますが)。

3.モデムの電源ケーブルも抜きます(こちらはスイッチがありませんから)。

4.10分ほどこの状態で放置し、その後モデムに給電します。

5.モデムがリンクアップした後で、5分ほど経過したら、ルーターの電源ケーブルを差し込み、ブートします(背面の電源ボタンを押し込む)。

6.あとは接続を待ちます。



なぜかこの手順を踏むと「勝手に Boot 事象」はなくなったように思います。

ほぼ2日間 Boot は走っていませんし、rule 受信も3回(Ver.2.54)行われていますので、以前の発生状況から勘案して解消したのではないかと考えます。


これって何なんでしょうか?



Boot を繰り返すような事象に遭われている方は、上の手順を踏んでみてください。



【2018-1-8  9:22  追記】

最初の Boot / 接続からまる6日間(144 時間)を経過しましたが、「勝手に Boot 事象」は発生していません。

治まったとみていいでしょう。





これまでに発生の V6Plus 接続関連の問題は以下のとおりです。

以下の各項の内、2項と3項は Ver.2.54 で発生
その他は Ver.2.53/2.54 共通に発生

1.フリーズする
  ➡ DHCP サーバー機能をやめて固定アドレスで使う

2.Ver2.54 では「Internet -->> Internet -->> V6プラス接続を使用する」で接続不可
  ➡「インターネット@スタート」設定する、または Ver.2.53 に戻す

3.Ver.2.54 では MAPe の rule 更新が3時間毎に行われない
  ➡ 影響があるかどうかわからない(とりあえず無視、または ver.2.53 に戻す)

4.設定項目の変更で安易にリロードされ、再接続になる項目がある
  ➡ 現時点では仕方がないので無視

5.LAN -> WAN なのにファイヤーウォールがブロックログを大量に吐く
  ➡ CE 処理のバグか(?)
   避けるにはスマホや PC などを VPN を使って使用し、
   ブラウザのアドブロックをする、または諦める

6.ログ・ファイルを外部メモリに転送設定しているときに排他エラーを起こすことが
  あり、このときに「外部メモリが壊れた」メッセージがでる(壊れてはいない)
  ➡ 外部メモリを直接参照せずに、一旦 PC 側の任意フォルダへコピペしそこを開く
   ようにする、または外部メモリへのログ転送をやめる

7.勝手に Boot が繰り返される
  ➡ 完全電源断から起動し直す(本稿・前記参照)

8.その他
 ① パスワード変更でログインできなくなった、という当ブログ閲覧者からの報告あり
  ➡ 私自身はこの事象には見舞われていないが、もし発生の場合はリセット後の
   初期パスワードを使うしかありません

 ② 無線LAN で "wl0: wlc_reset: !!!BIG-hammer!!!"  がログに記録される
  ➡ これは採用しているチップの問題のようです。熱暴走・干渉時・チップバグ
   のいずれかが原因のようで、バッファロー機に限った話ではなく同じチップを
   採用した、例えば Cisco でも発生しているようです

   チップがこれを検出時はチップ自体がリセットを行うようで、数秒程度で回復し
   ます
   ユーザーレベルだけでなく、採用したメーカーでも手の出しようがないようで、
   無視するしかなさそうです




以上がこれまでの問題点と回避手段または無視して構わない(と思います)項目です。