|
||||||||||||||||||||||||||||||||||||||||||||||||
明けましておめでとうございます。
各マシンの FreeBSD を最新の 5-current や 4-stable にアップデート。 ノートの 5-current をアップデートしたら xdm からログインできなくなった。 PAM 回り が原因。ちょうどいい機会なので XFree86 を手始めにいろいろ入れ直す。
NHK 教育の再放送見損ねた (;_;)。
NEWS-8 の日の日記を補完。
前の続き。 1/1 時点の 4.5-PRERELEASE の kernel でも NG。梅本さんのところほど 頻繁ではないけれど、やっぱり問題が発生する。
寝ている間や外出時だと対応できないので、 ping で接続状態をチェックして NG なら ppp を kill してから起動し直すスクリプトを作成。 2 分毎に cron で回すことで対症療法を行うことにした。
reichanet ネタ。 lang/ezm3登場。 commit log と pkg-descr の内容が笑える。 CVSup だけ使う人のための modula-3 処理系らしい :-)
cron で ppp チェックスクリプトを回しはじめたけど、問題の現象は起きないな。 たまにしか起きないからテストが難しいぞ :-)
昨日書いたezm3 話の続き。 jdp のメールをみて苦笑。
Date: Wed, 02 Jan 2002 08:59:51 -0800 (PST) From: John Polstra <jdp@polstra.com> To: hubs@freebsd.org Subject: New more portable Modula-3 for building CVSup [途中略] It is my belief that if you follow the simple instructions exactly, you will be able to install ezm3 on any of the supported systems in a single try. No muss, no fuss, no patching, no 25 MB downloads. Please give it a try, and let me know about any problems you run into. Thanks, John "I hate distributing CVSup binaries" Polstra
最後の John "I hate distributing CVSup binaries" Polstraというのが特に印象的 :-)。
今度の ezm3 で作った CVSup は、 modula-3 関係のライブラリだけ static link されるので *1なかなか良い。いままで static link されたバイナリには libc とかまで static link されていたからね。
ということで、 FreeBSD 用の CVSup バイナリの新しいやつ:
NetBSD 用のはそのうち作る予定。
昼過ぎくらいに沖縄の空港にいる 江州さんから電話。綱島の駅で待ち合わせることに決定。
南武線経由で綱島の駅へ。改札口を出て電話しようとしたらちょうど江州さんが 出てくるところだった。タクシーで江州さん宅へ。準備をちょっと手伝ってから 買い出しへ。
近くの酒屋 *1。日本酒の品揃えがかなり良くて、酒好きには危険な店だ :-)。 ワインも揃っているらしいのだが、私はワインは知らないのでパス。
とつまみを買って帰還。
後発組が綱島駅からタクシーに乗って到着。部屋がわからないので私が外に出て 誘導。ちょっと迷って混乱。後発組が買ってきた分があるので酒がさらに増える。
ワインで乾杯。江州さんの沖縄そば、 yuko さんのおでん、こがさんの鳥手羽など 美味しいつまみがいっぱい。いろいろな話をしながら楽しむ。 最初ちょっと余計かと思っていた酒がぜんぶ空いてしまった。
終電を逃してしまった私と (う) さんが残留。泡盛をちびちび飲みながら CD や DVD を鑑賞。眠くなってきたので就寝。
*.EUC -> *.euc* への locale rename が MFC。 4.5-RELEASE 直前のこの時期に MFC するのはちょっと...。
結局、 4-STABLE への変更は backout されることになった模様。
とはいえ、次の次である 4.6-RELEASE までには MFC される可能性が非常に 大きいので、 ports 等の対応を進めなきゃ。
いろいろと議論が続く。
となるかもしれない。
結局、 EUC 関係だけ backout された。
はかますきーさんの こちらのネタ。最寄り駅はだいたい検討がついた *1のだが、「快速を使って乗り換え一回で戻れたことがある」というのがちょっと 不思議。検索してみたのだが、快速は「ホリデー快速甲州号」 *2のことかな。初夏くらいの土休日に武蔵野線と中央線経由で大宮と甲府を 結んでいた臨時快速。とすると乗り換え駅は甲府。
ただ、この列車は一昨年まで運転されてたみたいだけど、 去年は設定されてなかったと思う。
サーバを今日の 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 に加えられた変更で後者が発生するように なったみたい。
at 調布。一次会は洋風居酒屋だった。飲み放題コースを頼んだのだけど 注文してからテーブルに届くまでの RTT が極端に長い店で駄目。
二次会は南口に移動して別の居酒屋。ここで 五反田さんが合流。
23 時過ぎくらいに解散。一次会からかなり飛ばしていたのかけっこう酔ったよ。 帰宅してからしばらく IRC して就寝。
本業方面がけっこう大変。
肉体会へ。忘年会のような特別なイベントでもないのに 20 名以上集まりますか。 いつも通り肉をいっぱい食べて帰還。
久しぶりに作成。
思わぬ用事が多発して、反応が大幅に遅れています。ごめんなさい。
amazon.co.jp に注文してたのが届いた。
Shooting Star のほうは amazon.co.jp のミュージック CD HOT 100 で 2 位を 続けているよ。すごいと言うべきなのか、 amazon.co.jp の利用者が偏っている と言うべきなのか。
ちょっと読まないうちに未読がすごい数になってるよ (;_;)。
今日の昼過ぎに工事。電話がちょっと鳴った *1と思ったら ADSL の接続が切れ、数分後には 8M で接続できた *2。速度は
| 1.5M | 8M | |
|---|---|---|
| 下り | 1200 kb/s | 2600 kb/s |
| 上り | 440 kb/s | 640 kb/s |
といった感じ。
日本のサーバにミラーされてきている CVS リポジトリが変。 cvsup.jp.NetBSD.orgから CVS リポジトリを取ろうとするとエラーになる。 cvsweb.NetBSD.orgも一部のファイルが見れない。
近所の本屋にて。