|
||||||||||||||||||||||||||||||||||||||||||||||||
サーバを今日の 4.5-RC に上げてみた。ときどき PPPoE のコネクションが 切れるのだが、その際には
Jan 10 23:30:41 ppp[XXX]: tun0: Phase: Received NGM_PPPOE_CLOSE (hook "tun0") Jan 10 23:30:41 ppp[XXX]: tun0: Phase: deflink: Device disconnected Jan 10 23:30:41 ppp[XXX]: tun0: CCP: deflink: State change Stopped --> Closed Jan 10 23:30:41 ppp[XXX]: tun0: CCP: deflink: State change Closed --> Initial Jan 10 23:30:41 ppp[XXX]: tun0: Phase: deflink: open -> lcp Jan 10 23:30:41 ppp[XXX]: tun0: IPCP: deflink: LayerDown: XXX.XXX.XXX.XXX [snip] Jan 10 23:30:41 ppp[XXX]: tun0: Phase: deflink: Enter pause (3) for redialing. Jan 10 23:30:44 ppp[XXX]: tun0: Phase: deflink: Connected! Jan 10 23:30:44 ppp[XXX]: tun0: Phase: deflink: opening -> dial Jan 10 23:30:44 ppp[XXX]: tun0: Phase: deflink: dial -> carrier Jan 10 23:30:45 ppp[XXX]: tun0: Phase: Received NGM_PPPOE_SUCCESS (hook "tun0") Jan 10 23:30:45 ppp[XXX]: tun0: Phase: deflink: carrier -> login [snip] Jan 10 23:30:46 ppp[XXX]: tun0: IPCP: deflink: LayerUp. Jan 10 23:30:46 ppp[XXX]: tun0: IPCP: myaddr XXX.XXX.XXX.XXX hisaddr = XXX.XXX.XXX.XXX
という感じで再接続しにいくようになった。
どうしてこうなったのか理由は検証していない *1けど、前に比べたら良くなったかな。
するための省令改正が決まったらしい ( 経済産業省の PDF)。 Subject: に ！連絡方法無！とさえ明記すれば、 SPAM 受け取り拒否の窓口を設ける必要がない。 相手の意向に関係なく勝手に送りつけ続ける行為に 経済産業省がお墨付きを与えたわけですね。手元の端末で読まずに捨てることは可能だけど、携帯電話や PHS で 「受信するのにお金がかかる」という問題は相変わらず。
電話会社側で特定 Subject: のメールをフィルターするようなサービスも 考えられるけど、こんなフィルターしにくい文字列 *1にしているところは明らかに SPAM 業者保護育成が目的だからだろうな。
これの続き。
Jan 16 16:00:01 ppp[XXXX]: tun0: Phase: deflink: write (1): Message too long
というエラーが出て ppp が異常終了する原因がとりあえず判明。
これは src/usr.sbin/ppp/physical.cの 810 行め付近の
ssize_t
physical_Write(struct physical *p, const void *buf, size_t nbytes)
{
log_DumpBuff(LogPHYSICAL, "write", buf, nbytes);
if (p->handler && p->handler->write)
return (*p->handler->write)(p, buf, nbytes);
return write(p->fd, buf, nbytes);
}
の write が失敗するために発生している。ここは PPP で接続先にデータを送る 書き込みをする部分。エラーになるデータを dump してみると
00 21 60 06 62 c2 00 20 06 40 3f fe 05 05 20 22 .!`.b.. .@?... " 00 00 00 00 00 00 00 00 00 01 20 01 02 18 04 99 .......... ..... 00 01 00 00 00 00 00 00 00 02 00 50 0d d5 ac 44 ...........P...D 35 29 44 e3 14 c1 80 11 81 c4 08 fd 00 00 01 01 5)D............. 08 0a 00 1b b3 63 00 30 63 3a 63 2e .....c.0c:c.
のようになっている。これは PPP のカプセル化されたデータ (RFC 1548)。 最初の 00 21 が protocol field で、以降のデータが IP であることを示している。
次の 60 以降が IP パケットだが、 6 で始まることから明らかに IPv6。
IPv4 Header Format (RFC 791)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Header Format (RFC2460)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv4 Header で Total Length が格納されているところは IPv6 Heaer だと Flow Label となっている。 PPP は Flow Label のデータを IP パケット長 と勘違いし、巨大な IP パケットを送り出そうとしているらしい。でも、 PPPoE では MTU 以上の大きさは送れないので write が失敗している。
physical.c の physical_Write() の引数 nbytes には Flow Label から計算される 値が入っているのを確認できた。
tun0 から IPv6 パケットが出ていこうとするのが原因なので、これをフィルター すれば良い。
# ip6fw add deny log all from any to any via tun0
を行えばよい。10 時間ほどテストしたがこれで大丈夫みたい。
状態が悪いときには 2 〜 3 分に 1 回 ppp がエラー終了していたので、 対策できてよかった。
同じ例が報告されてないのが不思議だった点も納得。 12 月下旬以降の 4-STABLE kernel なマシンを PPPoE な IPv6 ルータとして使っている人が非常に少数派という だけなのだろう :-)。
kernel 内部のコード *1のどの変更が原因かはまだ調べてない。
謎は、なぜ tun0 から IPv6 パケットが出ていこうとするのかということ。 IPv6 の default route は gif0 に向いているので tun0 から出るのは明らかに変。 ip6fw でフィルターしたログを調べてみても gif0 から出ていくべきパケット ばかり。
SD は龍池さんと波田野さんが記事書いてる。浅見さんは多忙で core を辞任したことを自分で書いてる。 SD の連載も近くやめるみたい。
(1/19 追加: typo 修正しました。指摘ありがとうございました)
録画していたビデオを鑑賞。主題歌が KEY の折戸氏作曲, I've アレンジだというので おねがいティーチャーを見てみたんだけど、うーんこういう話ですか (^_^;;。
問題は二つ。
某所の IRC で聞いてみた結果、前者は以前から発生していた模様。 12/12 から 12/23 の間に 4-STABLE に加えられた変更で後者が発生するように なったみたい。