『WAN切れ』のクチコミ掲示板

ここの過去ログにもありますが、表題の件について悩まされております。
ファームウェアを最新の1.00.38にすればよいとありますが、私のルーターは購入した時点でファームウェアは1.00.38です。

ルーターのログをみてみますと、30分に1回WAN側のIPを取得している時に何らかの拍子に取得できずにWAN切れとなるようです。
(当方CATV接続で、ケーブルモデムの電源を切らない限りIPは固定状態)

ルーターのログを貼りますと、
Sun, 2003-06-22 16:35:58 - ETH0: Normal connectin get IP address
***.***.***.***.　　←　正常にIPを取得できている
Sun, 2003-06-22 17:05:58 - ETH0: DHCP client lost IP.　←　IPを取得できない。以降WAN切れ

対処方法ご存知の方は、カキコよろしくお願いします。

書込番号：1692561

金沢ケーブルテレビのようですが、
・とりあえず、ケーブルモデムの電源を落として数時間放置してみてください。

・それでも駄目な場合は、BA8000Proの設定で、BA8000ProのWAN側ポートのMACアドレスを、それまでケーブルモデムに接続していた機器のMACアドレスと同じにしてみてください。

・ケーブルモデムの機器がおかしいこともあるようです。
http://w2223.nsk.ne.jp/~masako.m/m-diary02-06.html
http://w2223.nsk.ne.jp/~masako.m/m-diary02-07.html

ここに、「今まではお兄さんのパソコンで動作していたわけだから、一度モデムからまたリセットをかけるのだ」とも書いてあるので、ケーブルモデムがそれにつながっている機器のMACアドレスを覚えているようです。上で書いたようにモデムの電源オフでも駄目な場合は、説明書か何かに書いてある方法でモデムをリセットしてみてください。

ところで関係あるかどうかわかりませんが、
ケーブルテレビ側のDHCPサーバが、RFC2131（DHCP）に準拠していないような気がします。RFC2131では「最小のリース期間は1時間」と明記されています。パソコン直結時でもリース時間が30分となっていれば、それはおかしいです。

書込番号：1696690

レスありがとうございます。
> ・とりあえず、ケーブルモデムの電源を落として数時間放置してみてください。

今晩寝るときに、電源切って寝ます。
でも、違うと思います。
うちのプロバは複数台接続が可であり(有料)、まじめに(ｗ)、接続している３台分登録してありますので、モデムに前のMACアドレスが残ってたってへっちゃらだと思うのです。

最初の質問の時に経緯を書かずに失礼しました。
あらためて詳細な経緯をカキコさせていただきます。
２年位前からこのプロバで接続してます。
当初よりLINKSYSのBESFR41を使って何のトラブルもなく使用していました。
３月にケーブルモデムが変わりました(10Mbps→30Mbps)。
BESFR41はWAN側10Mbpsなので、
５月にBA8000Proを購入しました。
多い時で日に2、3度WAN切れにあいます(PCが稼動してあるないにかかわらず)。
という経緯です。

げっちゅるさんのレスで気になったのが、 ケーブルテレビ側のDHCPサーバが…　の文章です。
30分に1回WAN側のIPを取得というのは、BA8000ProがWAN側のIPを取得しているのと違うんですか？

書込番号：1698781

MACアドレスの問題でないとすると、、、

30分で通信できなくなる直前までインターネットは使えているのでしょうか？使えているならば、ポート相性が原因である可能性が消えます。

DHCPサーバはIPアドレスをDHCPクライアントにリースするときに、リース時間も通知します。（RFCではその最小時間が１時間と決められています。）
一般的なDHCPクライアントは一度IPを取得すると、
・リース時間*0.5以降、DHCP requestを使ってIPアドレスを更新しようとする。
・それでも更新できない場合、リース時間*0.875以降DHCP discoverを使って更新しようとする。
・それでも更新できずにリース時間が経過した場合に、IPを失います。

軽く見た限り、BA8000Proの0.5や0.875の際の動作は正常のようです。（リース時間が１時間の場合。）
そのログを見る限り30分でIPをlostしているということは、もともとのリース時間が30分であるような気がします。（リース時間が30分の場合のBA8000Proの動作はやってみないとわかりませんが）
パソコン直結時に「ipconfig /all」でDHCPリース時間を確認しても30分だったら、そのISPがRFCに反していることは明白なので、「１時間以上にしてよ」と要求することもできますし、今後のことも考えるとするべきだと思います。それが原因であるかどうかは不明ですが。

とりあえず現時点の対処方法としては、駄目もとで、一回初期化してみるとか交換してみるとかしかありませんね。

書込番号：1699747

レスありがとうございます。
> ・とりあえず、ケーブルモデムの電源を落として数時間放置してみてください。

これはやっぱり効果がなかったです。

> 30分で通信できなくなる直前までインターネットは使えているのでしょうか？
はい、問題なく使えてます。

30分毎にIPを取得しているのは、BA8000Proの設定かと思ってたのですが、DHCPサーバのリース時間だったのですね。
詳細な解説ありがとうございました。
パソコン直結してipconfig /allをやってみました。
やはり30分でした。
一応プロバにメール送ってみます。

書込番号：1703371

リース時間30分のLinux DHCPサーバを立ててみて試しました。
結果は、BA8000ProのDHCPクライアントは正常にIP更新していきました。
なぞです。

結局のところそのISPでは、最初のDHCP DiscoverでIPが取得できるのに、
更新のDHCP Requestはもちろん、RebindingのDHCP Discoverでも取得できない、ということになります。訳が判りません。

書込番号：1706490

プロバより回答が来ました。

> ＩＰアドレスのリース期間経過時には、
> 継続情報をセンターより自動配信して、通信の継続性を確保しています。

中略
> ＪＰＮＩＣより、ＩＰアドレスが必要数確保できない状態が続いていますので、
> 残念ですが、(リース時間の変更は)今のところは出来ません。

との事です。

それと、わざわざテストまでしていただきありがとうございます。
WAN切れも、無い時は２、３日起こらないことがありますので…

プロバのメールにある　> 継続情報をセンターより自動配信して　の継続情報がプロバの30分とBA8000Proの30分で微妙な誤差で、先にBA8000Proの30分が過ぎてIPを失い、プロバの継続情報受け取れてないことなのでは？
って素人考えですが、どうでしょうか？

それと、
> BA8000Proの0.5や0.875の際の動作は正常のようです。
とありますが、それはログで確認できることですか？
もしそうなら、差し支えない範囲で該当部分のログを貼り出していただければ、参考にできるかもしれませんので、お願いします。

今日のWAN切れログ
Fri, 2003-06-27 19:03:10 - ETH0: Normal connectin get IP address ***.***.***.***
Fri, 2003-06-27 19:33:11 - ETH0: DHCP client lost IP.

書込番号：1707787

> 継続情報をセンターより自動配信して、
DHCPの仕組みでは、DHCPクライアントからDHCP RequestやDHCP DiscoverやDHCP Informを送らない限りDHCPサーバはリース時間を通知しません。
http://www.bekkoame.ne.jp/%7Epoetlabo/LIBRARY/rfc2131j.txt

しかもリース時間×0.875の「再割り当て(Rebinding)」のDHCP DiscoverブロードキャストでもIP取得できない、というのが謎です。（DHCPクライアントが起動時に出すのもDHCP Discoverブロードキャストだから）

> 無い時は２、３日起こらないことがありますので…
ということは、DHCPメッセージの互換性問題の可能性もほとんどありません。

> ＪＰＮＩＣより、ＩＰアドレスが必要数確保できない状態が続いていますので、
> 残念ですが、(リース時間の変更は)今のところは出来ません
からの勝手な想像ですが、単純にDHCPサーバのアドレスプールが不足しているかも。
RFCに反してまで（リース30分を拒絶するクライアントが存在してもおかしくない危険を犯してまで）、たったの30分というみみっちい時間を節約しているということは、おそらく慢性的にアドレス不足のはずです。
（だったらユーザー募集を一時中断して欲しいくらいですが、そこが中小ISPのつらいところかも）

で、さらに節約の効果を出すために、DHCPサーバから定期的にARPを出して、（ARPには信頼性がまったくないので途中で消えたりして）クライアントが１回でも応答しなければ、そのリースを解除して他のクライアントに回し、しかもアドレスプールは常にほぼ満杯状態なので、IPを取り上げられたクライアントは当分どうしようもない、ということも考えられます。
また、普通DHCPサーバはISP全体に1個ではなく、一定区域ごとにDHCPサーバがあります。ISP全体ではちょっとだけIPアドレスに余裕があるけど、ともちんパパ　さん区域のDHCPサーバのアドレスプールが特に不足していることもありえます。

> それはログで確認できることですか？
すいません、WAN側パケットを観察していただけでログは見ていませんでした。

どうしようもないときの最後の手段。
１．BA8000Proが無事IPアドレス取得できた時、「アカウント管理画面」の「状態」には、
　Connected [IPAddress Subnetmask Defaultgateway DHCPTime]
と表示されます。ここのIPアドレス、サブネットマスク、デフォルトゲートウェイと、DNSサーバアドレス、もしあったらドメイン名もメモしておく。

２．すかさずアカウントの[修正]ボタンを押して、
　DHCPクライアント機能：無効
　DNSサーバアドレス設定方法：無効
　さっきメモしたアドレス、サブネットマスク、ゲートウェイ、DNSサーバアドレスを入力する。

３．２で、ドメイン名もあった場合のみ、「LAN側ネットワーク」画面のドメイン名欄に入力し、パソコンを再起動。

これで半永久的にIP使えます。
一見、他のユーザー（DHCPクライアント）に迷惑をかけそうな設定ですが、DHCPサーバがしっかりしたものであれば、DHCPクライアントにIPアドレスをリースする前に、PingやARPでそのIPが使われていないかチェックします。PingやARP応答がありそのアドレスが既に使われていると判った場合、DHCPサーバは他のIPをリースするので問題はおきません。

書込番号：1709552

もしかしたら、とってもｱﾌｫな事が原因だったかもしれません。
もうしばらく様子を見てWAN切れがないようなら、それが原因と断言しても良いでしょう。
またWAN切れが起こるなら、「どうしようもないときの最後の手段」を取らせていただきます。
もう２､３日様子を見させてください。

書込番号：1714347

あ、もしかして、ステルスモード有効にしていますか？

DHCPサーバがPingを送出し、クライアントがそれに応答しない場合、DHCPサーバがIPを取り上げてしまう仕様かもしれません。
（ステルスモード有効の場合でも、ルータはARPには絶対に応答しますので、DHCPサーバがARPでクライアント生存確認していたらこういう問題は起こらないのですが）

それでも再取得できるときとできないときがあるのは謎ですが、そのIPを取り上げてしまった後に、「そのIPを他のクライアントにリースしてしまった」場合と「そのIPはまだあいている状態」の場合の挙動の違いかもしれません。

もし、DHCPサーバの仕様が
- （ARPではなく）PingだけでIPアドレスの利用状況確認をしていて尚且つ、
- ルータのステルスモードが有効の場合、
ルータをDHCPにしようが固定IP（最後の手段）にしようが問題が発生してしまいます。
もしステルスモード有効ならば無効にしてみてください。

書込番号：1715852

ちなみに、DHCPを使う一般的なプロバイダではARPでIPの確認をします。
Yahoo! BBもそうです。

なぜなら、Pingに応答しないクライアントが存在する可能性があるからです。「pingには絶対応答しなければならない」という決まりもないし。

書込番号：1715870

げっちゅるさん、またまた詳細な解説ありがとうございます。

ステルスモードは今は有効にしています。
WAN切れの嵐のときは無効にしていました。

土曜日の朝にこれが原因かな？というものに気付いて設定を変え、以降WAN切れはなくなってます。
多分あれが原因でしょう。

ここで問題です。
私のWAN切れのｱﾌｫな原因とはいったい何だったんでしょうか？
ヒントは「デフォルトのまま使ってました」です。

正解は近日公開！

書込番号：1717077

デフォルトとはルータ設定でしょうか？
ホスト名くらいしか思いつかないです。

書込番号：1720675

またWAN切れです。

正解はホスト名だったのですが、どうやらこれがWAN切れの原因ではないようです。
でも、以前と比べると、WAN切れの確率が低くなっているようです。

ステルスモードを無効に変更してみました。
これでまたしばらく様子を見たいと思います。

書込番号：1725288

起こったり起こらなかったりして、起こる時も不定期ということは、やっぱりプロバイダ側の問題かも。

書込番号：1727058

> やっぱりプロバイダ側の問題かも
いえいえ、そう言い切れないのです。
LINKSYSのBESFR41では一度たりともWAN切れになってませんから。
プロバとBA8000Proの相性が悪いのかなぁ？

書込番号：1728388

またWAN切れになってしまいました。
「どうしようもないときの最後の手段」をやってみました。
またしばらく様子を見たいと思います。

もしこの設定でまたWAN切れになった場合、BA8000Proの不具合でしょうか？
それともプロバのせい？

書込番号：1728613

- 取得できるときは取得できる。
- 互換性の問題が起こるとは考えにくい、DHCP discoverでも取得できない。

ということからして、個人的にはプロバイダが怪しいかなと思っています。
DHCPサーバを少数に集約したりしたことを契機に、そのようなことが起こることもある、というのを人から今週聞きました（また聞きなので本当かどうかはわかりませんが、DHCPサーバが貧弱だとありえます）

最後の手段をとる場合は、ステルスモードをオフにしておいたほうがいいでしょう。そうしないとDHCPサーバの使用によっては他人に迷惑をかけてしまいます。（そもそもあまりいい手段ではないですが）

書込番号：1728934

今のところ順調です。
ですが、イレギュラーな使い方なので何とかしてみたいです。

で、WAN側パケットの観察って難しいですか？
やり方を解説してあるサイトをご存知でしたら、URLをお願いします。

書込番号：1733743

今ごろ起きました。（時間がもったいない。）

WAN側パケットのとり方は、ダムハブがあれば比較的簡単です。環境がWindowsであることを前提に書きます。
１．必要なもの。
ダムハブ、パソコン最低１台、LANケーブル
ダムハブとは、スイッチハブのことではありません。安いリピータハブです。スイッチハブ全盛の今はあまり売っていませんが、10BASE5ポートのものなら比較的簡単に手に入るでしょう。
http://buffalo.melcoinc.co.jp/products/catalog/item/l/lgh-mp/index.html
http://www.corega.co.jp/product/list/hub/hub5pn.htm
http://www.planex.co.jp/product/hub/eh50805.shtml
のようものです。

２．ソフト
http://winpcap.polito.it/install/default.htm
から、「WinPcap 3.0」をダウンロード。
http://www.ethereal.com/distribution/win32/
から、「ethereal-setup-0.9.13a.exe」をダウンロード。

３．インストール
必ず、「WinPcap 3.0」、「ethereal-setup-0.9.13a.exe」の順番でインストールしてください。

４．設置
モデム--Hub--ルータ
とつないで、そのハブの空いたポートにキャプチャするパソコンもつなげます。つまりHubにルータのWAN側ポートとパソコンが並列に接続されます。

５．使い方
”ethereal 使い方”などのキーワードでgoogleすれば、たくさん出てきます。簡単に言うと、メニューの[Capture]-[start]を押して、[interface]を選んで[OK]を押すだけです。

５．注意
・[Capture]-[start]では、[filter]の[Name resolution]はすべてオフ（スイッチが浮いている状態）にしたほうが負荷がかかりません。

・[Capture]-[start]では、[capture packets in promiscuos mode]は必ずオン（スイッチが沈んだ状態）にしておいてください。

・ISPがグローバルIPを複数割り当てるサービスでない限り、そのパソコンがDHCPクライアントでIP取得してしまうとルータがIP取得できません。
その場合は、「172.16.0.1」などいい加減な固定IPをパソコンに割り当ててからHubに接続しましょう。（ただしその場合、キャプチャパソコンはインターネットできません）

・キャプチャパソコンにグローバルIPを取得させてもいい場合、そのパソコンの防衛策は別途考えてください。

・普通にキャプチャすると、キャプチャパソコンの送受信するパケットや同じネットワーク内のほかの通信などすべてが記録されます。DHCPパケットだけをキャプチャするには、[Capture]-[start]で現れる画面の[filter]欄に、
udp port 67
と書いて[OK]を押せばいいです。

・長期間キャプチャするなら、キャプチャしながら同時にファイル保存しておいたほうがいいです。キャプチャする際の[Capture]-[start]で、[File]ボタンを押して、適当なフォルダを選択し、一番下の欄に適当なファイルをつけてOKを押します。

書込番号：1734682

もしキャプチャデータの判断に迷ったら教えてください。
hotmailなどの捨てアカウントを双方で作って送信してもらえれば私が見てもいいです。

書込番号：1734692

なんどもすいません。
ファイル保存の際、拡張子はつけなくてもいいです。どうしてもつけたかったら、「.dat」や「.cap」でもいいですが。

書込番号：1734699

詳細な説明を頂きましてありがとうございます。
リピータハブですか。。。
スイッチングハブなら今手元にあるのですが、
http://buffalo.melcoinc.co.jp/products/catalog/item/l/lsw10100-5pw/index.html
これがダメなら、新たに購入しないとダメですね。
ハブが10Mbpsだと、そこがボトルネックになってしまうので、100Mbpsの物があったらいいのですが。。。
今週中には何とか用意して試してみたいと思います。

> ISPがグローバルIPを複数割り当てるサービスでない限り、
うちのプロバはIPを複数当ててくれます。

PCは引退しているSEマシンがありますので、それで試してみようと思います。
Win機で出来るのは楽でいいです。
ケーブルモデムとルーターの間に、NICを２枚挿したUNIX機でやるのかと思って冷や冷やしてました。

書込番号：1735622

とりあえず今手元にあるハブでやってみました。
etherealの使い方も調べないままとりあえず動かしてみました。
何とかキャプチャ出来るようですね。
使い方を調べて本格的に使ってみたいと思います。

書込番号：1740116

WAN切れの時のデータをキャプチャする事が出来ました。
このデータをここに貼り付けたいのですが…
どうやればいいんだろう。。。

書込番号：1747376

＞とりあえず今手元にあるハブでやってみました。
スイッチングハブでキャプチャしてしまうと、基本的にブロードキャストパケットしか採取できません。

よかったら捨てメールアカウント作ってそこに転送してもらえれば見ますが。
ただし、そのファイルは圧縮してどのくらいの容量ですか？
大きすぎるとメールではちょっと無理なので。

書込番号：1752167

20:43:07 aaa.aaa.aaa.aaa DHCP Request # パケット採取用のPCのIP
20:44:14 bbb.bbb.bbb.bbb DHCP Request # BA8000proのIP
20:59:07 aaa.aaa.aaa.aaa DHCP Request # パケット採取用のPCのIP
21:10:29 bbb.bbb.bbb.bbb DHCP Request # BA8000proのIP
21:11:30 bbb.bbb.bbb.bbb DHCP Request # BA8000proのIP
21:12:31 bbb.bbb.bbb.bbb DHCP Request # BA8000proのIP
21:13:32 bbb.bbb.bbb.bbb DHCP Request # BA8000proのIP
21:14:16 0.0.0.0 DHCP Discover
21:14:21 0.0.0.0 DHCP Discover
21:14:32 0.0.0.0 DHCP Discover
21:14:33 aaa.aaa.aaa.aaa DHCP Request # パケット採取用のPCのIP
21:14:50 0.0.0.0 DHCP Discover
21:15:23 0.0.0.0 Boot Reqest from 00:00:00:00:00:00 # BA8000proのmacアドレス
21:15:34 0.0.0.0 DHCP Discover
21:15:39 0.0.0.0 DHCP Discover
21:15:50 0.0.0.0 DHCP Discover
21:16:08 0.0.0.0 DHCP Discover
21:16:42 0.0.0.0 Boot Reqest from 00:00:00:00:00:00 # BA8000proのmacアドレス
21:16:50 0.0.0.0 DHCP Discover
21:16:57 0.0.0.0 DHCP Discover
21:17:08 0.0.0.0 DHCP Discover
21:17:26 0.0.0.0 DHCP Discover
21:17:59 0.0.0.0 Boot Reqest from 00:00:00:00:00:00 # BA8000proのmacアドレス


> スイッチングハブでキャプチャしてしまうと、基本的にブロードキャストパケットしか採取できません。
> よかったら捨てメールアカウント作ってそこに転送してもらえれば見ますが。
とりあえず、該当部分を拾い集めましたので見てもらえますか？

当日は20時40分ごろキャプチャを開始しまして寝ました。
21:14にはWAN切れになっていたみたいです。
その前にごく短時間でDHCP Requestを繰り返したのが気になります。

気になるといえば、
うちのプロバのリース時間は30分なので、DHCP Requestは15分ですよね。
パケット採取用のPCは確かに16分間隔でDHCP Requestを繰り返してます。
ところが、BA8000proは正常時でも26分間隔でDHCP Requestを繰り返してます。
BA8000proの故障？


> そのファイルは圧縮してどのくらいの容量ですか？
圧縮しない状態で1MBです。

書込番号：1753397

スイッチを使うとよくわからなくなります。

＞BA8000proの故障？
いや、そういう意味では多分違います。
というのも、更新のDHCP requestはユニキャストで送信してもいいのですが、
（というか、ユニキャストのほうがネットワークには好ましい）
スイッチ経由でのキャプチャはユニキャストは基本的に採取できません。
（スイッチのMACアドレステーブルに登録されていないMACアドレス行きのパケットならばユニキャストでも取れますし、スイッチのMACテーブルのフラッシュ時間にもよります）

BA8000Proも、最初の頃のDHCP requestはユニキャストで送信していたと思います。したがってあまり原因究明にはならないかも。
一応、作ってみました。
[e-mail]

書込番号：1754786

げっちゅるさん 、メール送りました。
よろしくお願いいたします。

書込番号：1755180

メールありがとうございました。
記載された設定をしてみました。
またしばらく様子を見ます。

書込番号：1760351

お久しぶりです。
その後、どうですか？

書込番号：1784798

お久しぶりです。
おかげさまでその後は順調です。

今度の火曜日にISPのメンテナンスでインターネット接続の一時停止があります。
この時にIPアドレス変わってなお且つWAN切れが起きなければ完璧といえると思います。
これを乗り切れるのかが正念場です。

ただ、２つほど気にかかることが…
ログに
ETH0: Normal connectin get IP address ***.***.***.***.
が全く出なくなりました。

それと、パケットをキャプチャしても、
***.***.***.*** DHCP Request
が出なくなりました。

出なくてもWAN切れが起こらなければいいんでかまわないのですが、、、
とにかく火曜日が正念場です。

書込番号：1796241

ISPのメンテナンスはごく短時間で終わったようです。
IPも変わりませんでした。
とりあえずOKです。

書込番号：1808484