フレッツモアで使用するモデムMN2の不具合について 2003.01.24

2002.12 に、フレッツ ADSL 8M -> フレッツADSL モア(12M) に切り替えた。モデムも新しいものが必要ということなので、MN2に取り替えた(レンタル)。しかし、つながらない。最終的には、つながるようになったので、同じ現象の方は参考にしてください。

詳しい現象は以下の通り。

OK: Windows PC -- 8M モデム -- Flets, プロバイダ
OK: Linux -- 8M モデム -- Flets, プロバイダ
NG: Windows PC -- 12M モデム -- Flets, プロバイダ
NG: Linux -- 12M モデム -- Flets, プロバイダ

(Linux は redhat 7.2, rp-pppoeを使用)

113 故障担当に問い合わせたところ、MN2 のファームの不具合だとのこと。 1 月に入って、ファームの新版がリリースされたとの連絡をNTTからもらった。どうやら、12/21 にはファームの新版がリリースされていたらしい。早速、バージョン1.11 にアップグレードして、接続を試してみる。

OK: Windows PC -- 12M モデム -- Flets, プロバイダ
NG: Linux -- 12M モデム -- Flets, プロバイダ

なぜか、Linux だけうまくいかない。

rp-pppoe の DEBUG モードで、adsl-start してみると、PADI に対する PADO がタイムアウトしている。検索してみたが、ケーブルがちゃんと接続されていなかったりする場合にこのエラーがよく出るらしい。でも、8Mではちゃんとつながるからそんなことはないはず。

NTTに問い合わせたところ、8M 用と12M 用のモデムの違いは、DHCP機能がついているかどうかだけなので、DHCPをオフにして試して欲しいといわれた。 Linux の PPPoE 側のインタフェースには、もともとIPは振っていないし、 DHCPでIPアドレスを取得するように設定していないので、関係ないだろうと思いつつ、トライしてみた。案の定、Linux から接続できない。

Linux マシンの Ether もしくは、rp-pppoeがなんか悪さしているかもしれないので、もう一台、調査用のLinux マシンを持ってきて、眠っていたHUB(スイッチングではない)で以下のような構成を作った。

                   +-----+
Linux PC    -------| HUB |-------MN2
Windows PC  　　　 |     |　(MN2はカスケード接続 or クロスケーブル使用)
                   +--+--+
                      |
                     Linux(調査用)

調査用のマシンでは、tcpdump と pppoe-sniff を走らせ、Linux PC と Windows PC をつなぎ変えながら、それぞれの接続要求パケットの監視を行った。

Linux PC からは, PADI が 3回でてそれで終了。デバッグモードのadsl-start のログと同じ結果になった。ということは、Ether Card の不具合ではなく、 PADO のパケット自体が MN2 から来ていないということだ。さて、Windows PC はというと、ちゃんと PADO が帰ってきて無事接続終了。うーん、わからん。

なんとなく、Windows PC から、MN2 のデフォルトIPアドレスである 192.168.1.1 に ping してみる。ちゃんと ping は通るようだ。ためしに, ping が通らない状況で接続したらどうだろうということで、Windows PC を MN2 に直接つないで、Windows の Ether の IP アドレスを開放して、MN2 の DHCP をオフにしてみる。すると、今度は、接続できないではないですか。では、IPアドレスを振ってみよう。ということで、手作業(DHCP経由でなく)で IPCONFIG で、192.168.1.2 を振ってみる。今度は、ping が通らない。 192.168.1.1 と192.168.1.2 の間で通信ができない(もちろんネットマスクはちゃんとあっている)ので、すくなくとも、MN2 のバグがあることが判明。たぶん、DHCP 経由で取得したIPに対してしか、arp テーブルがちゃんと作られないか、一旦、Ether のリンクが切れてしまうと、arp テーブルがクリアされて、次にリンクアップしたときに arp テーブルがちゃんと作られないということだろう。

つまり、PC の Ether の MAC アドレスを MN2 に認識させるためには、ping が通る状況でないといけないということである。NTT 側では、DHCP 機能が付いたかついていないか以外は、8M と 12M のモデムには違いがないという回答だったので、これは完全に間違い。「MN2 では、ping が通る状況に持っていかないと PPPoE の接続ができない」というバグが埋め込まれていたということです。しかも、MN2のリンクを一旦落としてしまうと、ちゃんとIPを振っても ping が通らなくなる。

しかたないので、HUB を経由して接続することによって、Linux の電源を落としても、MN2のリンクは落ちないようにした。また、MN2 との接続用のEther にも IP を振った。これで、ping が通るようになり、PPPoE 接続もできるようになった。(まだやっていないが、MN2 の DHCP をオンにして、Linux 側で MN2 側の Ether の IP を取得するように設定してもうまくいくかもしれない。)

バグについては、NTT に報告した。最初は、NTT 側では、正式には Windows しか対応していない、仕様であるという返事だったが、

Windows でも、ping が通らない状態にして PPPoE 接続要求をかけるとうまくいかない。 → Windows でもだめ
しかも、8M と 12M のモデムの違いはDHCP の有無のみだと明言している。マニュアルには、ping が通る状態にするという意味でIPアドレスを振らなければいけないという記載が一切ない。 → 仕様ではない

という事実から、バグであることを認めた。これを直すかどうかについては、うやむやになったが、約1ヶ月8Mで運用していたので、その間の12Mと8Mの差額は返金してもらった。