たかつです。

さっそくのご返答ありがとうございます。
さっきのメールにも書きましたが、

・LANアダプタを LAN用と PPPoE用とで入れ替えて、re0 を ppp に使っても発生する
・CTUにはネットサーフィン用に別途ブロードバンドルータ(こちらもCTUにPPPoE接続)が繋がっており、こちらの通信は問題ない
・障害発生時に、Windows機から Interlink に接続すると、問題なく接続できる

という状況です。あと、書き忘れてましたが
・CTUの電源を入れ直す
・LANケーブルを変えてみる
・CTUのポートを変えてみる
・NIC側のオートネゴを止める(CTU側は固定設定できませんでしたのでNIC側だけ)
・HUBを通す(上述のWindows機テスト時には、HUBを通してFreeBSD機の直前で分配接続してました)
・USB NIC を使ってみる(同じNICで、Windows 機では安定してました)
というのも試してみてダメでした。

記事 <4b53e204.3030...@fmp.to> で
        Paseriさんは書きました

> LAN ケーブルを違うものと交換してみる。
> nic を別物に変える。
> 何でもいいので、正しく働いてくれそうな hub を CTU と nic の間に挟んで様子をみる。
> オートネゴシエーションが有効になっているようなら、nic CTU 共に固定させてみる。

このあたりは実践済です。

> lqr 有効環境下でそのパケットを見失うぐらいものすごい勢いで通信している

LQRはデフォルトのままで無効になってるはずです。また、LQR有効下でLQRを見失うなら
回線切断されるはずですが、
今のトラブルは「見かけ上リンクしているが、まともに通信できない」という状況で、
障害発生中もログを見る限りは、 LCP ECHO については、 問題なくやりとりできてる感じです。

というわけで

> CTU の故障
> fxp(4) の故障
> LAN ケーブルがネズミにかじられている
> フレッツ網に何らかの障害発生しているかも知れない
> lqr 有効環境下でそのパケットを見失うぐらいものすごい勢いで通信している
> 電気特性の不一致

これらの可能性はどれもないと思ってます。
#もしかしたら、中途半端な状態のCTU故障って可能性は捨て切れませんが…

上述のUSB NIC でのテストについては、
・内蔵の fxp0 で運用中に障害発生
  →(OSは再起動せずに) USB NIC を挿して、そちらからのPPP接続に切り替えると、接続可能
・そうやって USB NIC をしばらく使っていると、同様の障害発生 
  →fxp0に配線を戻しても接続できないまま
  →USB NIC をWindows機に差し替えると、Win機からはUSB NIC経由で問題なく接続できる

といった状況もありましたので、ハードウェア的なトラブルというより、
FreeBSD側のソフトウェアの問題か、
CTUとFreeBSDのソフト的な相性問題の可能性が高そうなのですが…
これ以上、どうトラブルシューティングすればいいのか途方にくれてます。


-- 
PROJECT TEAM DoGA 高津正道                            ta...@doga.jp
                     PROJECT TEAM DoGAのホームページ → http://doga.jp/
1月18日(月) 今日のマーフィーの法則    [ウインフィールドの「行く先の道順」の金言]
道を教える人が「簡単にわかりますよ」と言えば言うほど、迷子になりやすい。

メールによる返信