|Home|私のLinux活用記録-Home-|

私のLinux活用記録

-Page23-

項目

kh23-01[Vine Linux 3.x チップス]
kh23-02[フレッツ光プレミアムにおけるMTU問題]

[Vine Linux 3.x チップス]

作成：2005年12月10日
追記：2006年05月12日

Vine Linux 3.0 がリリースされてすでに久しいので、今更チップスを掲載するのはタイミングがずれているのですが、これまで合計 5台の PC を順次 Vine 2.6 から 3.0 ⇒ 3.1 ⇒ 3.2 へとアップグレードした際に遭遇したトラブルについての対応メモが溜まってきたので、今後役立ちそうなものをチップスとして整理しました。

内容的には、必ずしも Vine Linux に直接関係しない事項もありますが、この機会に併せて掲載しました。

kh23-01.01 Windows XP のパーティションを圧縮する
kh23-01.02 日本語ターミナルを起動する
kh23-01.03 マウスを正しく認識させる
kh23-01.04 ユーザID とグループID を一致させる
kh23-01.05 NFS マウントの失敗対応
kh23-01.06 GRUB による起動用フロッピーディスク作成
kh23-01.07 Emacs 関連のインストールと設定
kh23-01.08 vim の設定と jvim インストール
kh23-01.09 gcnmz, mknmz の異常な挙動

戻る

Windows XP のパーティションを圧縮する

新品の Windows XP ノートPC に Linux をインストールには、どうしても Windows XP のパーティション(/dev/hda1) を圧縮して、Linux 用のパーティションを確保しなければなりません。

新品の PC にこれを行うのは、なかなか勇気のいるものです。もし Windows XP がこわれた時は、再インストールを覚悟しなければなりません。

私の場合、機種は IBM ThinkPad R40e あまり高級な機種ではありません。ハードディスク容量は 20GB で、4GB は隠し領域(再インストール用ファイル)、残り 16GB が Windows XP 用に使われています。

QTParted を使う

Windows XP のファイルシステムは NTFS です。パーティションを圧縮するツールとして PartitionMagic が有名ですが、残念ながら有償ソフトです。Linux をインストールするために有償ソフトが必要と言うのは本末転倒なので、無償ソフトを探していたら KNOPPIX がありました。

KNOPPIX は、CD-ROM とメモリーだけで起動する Linux です。ハードディスクにインストールしなくても起動します。この中にQTParted というツールが入っています。

私が使用した KNOPPIX は、バージョン 3.4 ですが、デフォルトで起動すると ACPI のロードでフリーズしてしまうので、オプション付で起動します。

boot:failsafe
or
boot:knoppix noacpi

KDE の画面が立ち上がったら、メニューから「Root Shell」を起動します。
QTParted を実行するには root権限が必要なので、前もって root のパスワードを登録します。

# passwd
Enter new UNIX password:********
Retype new UNIX password:********

rootパスワードを登録したら、KDE「システム」フォルダー中の「QTParted」を選択・起動します。rootパスワードが要求されるので、先に登録した rootパスワードを入力します。あとは、QTParted画面の操作で NTFS の圧縮と /dev/hda1 パーティションの切り直しを行うことができます。

[参考] http://www.stackasterisk.jp/tech/systemConstruction/dual01_02.jsp

ntfsresize を使う

実は QTParted は NTFS をリサイズするコマンド ntfsresize の GUIフロントエンドとして開発されたツールです。なので、ntfsresizeコマンドを使えば、コマンドラインから NTFSパーティションの圧縮を行うことができます。私には、こちらの方が、コンピュータが何をやっているか解かりやすく、信頼感があります。

前述の KNOPPIX3.4 があれば、ntfsresize が使えます。Root Shell から ntfsresizeコマンドを実行します。入力文字を間違えると一発でディスク内容が消えることになりかねないので、入力は慎重に行います。

■ ハードディスクのパーティションを表示
# fdisk -l /dev/hda

■ /dev/hda1 NTFS の圧縮可能なサイズをチェック
# ntfsresize --info /dev/hda1
[注]
圧縮可能なサイズが表示されます。

■ /dev/hda1 NTFS のリサイズをテスト
# ntfsresize --no-action --size .....M /dev/hda1
[注]
.....M には、上の --infoオプションで表示された圧縮可能サイズよりおおきいサイズを MB 単位の数値でセットします(もちろん Linux に使用するための残りのサイズも計算して)

■ /dev/hda1 NTFS のリサイズを実行
# ntfsresize --size .....M /dev/hda1
[注]
これを実行するともう取り返しがつきません。入力はくれぐれも慎重に!!
.....M の値は忘れないようにメモしておきましょう。
Current volume size と Current device size が表示されます。Current volume size はリサイズした NTFS のサイズ、Current device size は元の /dev/hda1 のサイズです。これは、NTFS はリサイズされているが、/dev/hda1 は未だリサイズされていない状態を表しています。

■ partition table と MBR情報の保存
フロッピーディスクが使えるなら、以下のコマンドを実行して、情報を保存します。出力ファイルをターミナルに出力して、メモしてもいいでしょう。
# sfdisk -d /dev/hda > hda.pt
# dd if=/dev/hda of=hda.mbr bs=512 count=1

■ /dev/hda のパーティション切り直し
# fdisk /dev/hda
Command(m for help):p      // パーティション情報表示
Command(m for help):d      // パーティションを削除
Partition number(1-4):1    // パーティション1 を削除
Command(m for help):n      // パーティションを作成
Command action
 e extended
 p primary partition(1-4)
p                          // primary partiton(1-4) を選択
partition number(1-4):1    // パーティション1 を作成
First cylinder(1-xxxx, default 1):1  // デフォルト値を設定
Last cylinder or +size or +sizeM or +sizeK(1-xxxx, default xxxx):+.....M
// ここで指定するパーティション1 のサイズ .....M の値は、以前にリサイズした
// NTFS のサイズより少し大きくしておく必要があります。 
Command(m for help):t      // パーティションのタイプ設定
Partition number(1-4):1    // パーティション1 のタイプ設定
Hex code(type L to list codes):7     // HPFS/NTFS タイプを設定
Changed system type of partition 1 to 7(HPFS/NTFS)
Command(m for help):a      // パーティションをアクティブ(ブート可能) にする
Partition number(1-4):1    // パーティション1 をアクティブ(ブート可能) にする
Command(m for help):p      // パーティション情報表示(正しく設定されているか確認)
Command(m for help):w      // パーティションテーブルを書き込み(保存)
Command(m for help):q      // fdisk を終了

[注]
ここで行っていることは、/dev/hda1 をリサイズした NTFS のサイズより少し大きめに設定した後、あらためて HPFS/NTFSパーティションとして再設定する操作です。最後に /dev/hda1 をブート可能にして、保存します。

[参考] http://mlf.linux.rulez.org/mlf/ezaz/ntfsresize.html

戻る

日本語ターミナルを起動する

Vine 3.x では、日本語ターミナル kon が使えなくなりました。日本語が使えるターミナルを起動するには、VESAフレームバッファを使って Linux を起動します。Vine の GUI起動画面が表示されたときに、[Esc] キーを押下するとテキストモードの起動画面に変わります。ここで、以下のいずれかを入力すれば、Linux 起動後、対応する解像度の日本語ターミナルが起動します(/etc/inittab の runレベルが 3 となっていることが前提です)。
boot: linux vga=0x301(640x480)
boot: linux vga=0x303(800x600)
boot: linux vga=0x317(1024x768)

[参考]
Vine Linuxオンラインマニュアル第 4章Vine Linuxの基本操作(http://vinelinux.org/manuals/login-1.html)

戻る

マウスを正しく認識させる

X Windows でのマウスの認識は、/etc/X11/xorg.conf ファイルで設定されています。以下、問題解決のために行った xorg.conf ファイルの書き換え内容を記述します。

PS/2 マウスの認識

PS/2 マウスを装備した PC の場合、デフォルトのインストールでは、X Windows でマウスの動きが異常となり、GUI 画面の操作ができません。とりあえずは、[Ctrl]+[Alt]+[F6] でターミナルに切替え、runレベルを 3 にしてリブートします。

xorg.conf ファイルのデフォルトの設定は、以下の様になっています。

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/psaux"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "yes"
EndSection

Section "InputDevice"
        Identifier  "Mouse9"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "AlwaysCore"
EndSection

レガシーの PS/2 マウスの場合、Option "Device" "/dev/psaux" が該当するので、設定を以下の様に書き換えます。

Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        Option      "Protocol" "PS/2"
        Option      "Device" "/dev/psaux"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "yes"
EndSection

Section "InputDevice"
        Identifier  "Mouse9"
        Driver      "mouse"
        Option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "AlwaysCore"
EndSection

IBM ThinkPad R40e のポインティングデバイス設定

IBM ThinkPad R40e(A4ノートPC) の Track Point と USB マウスを正しく認識させます。まず、Track Point が、上記 xorg.conf において、どの option "Device" "/dev/xxxx" に対応するのかをチェックします。

安全のために、すべての Window を閉じておきます。仮想ターミナルを起動し

# cat /dev/psaux

を実行します。
Track Point をほんの少し動かす(大きく動かさないように) と、仮想ターミナルに意味不明のコードが出力されます。この出力があれば、Track Point が /dev/psaux として認識されています。
何も出力がない場合は、操作したポインティングデバイスは、/dev/psaux には対応していないことになります。
確認の終了方法は、出力があった場合は、[Esc]-->[Ctrl]+[C] で出力状態を終了します。出力がなかった場合は、[Ctrl]+[C] で終了します。

同様に、

# cat /dev/input/mice

を実行し、USBマウスの出力があること確認します。

次いで、Track Point をポインティングデバイスとして優先させる(AlwaysCore とする)ため、xorg.conf を以下の様に書き換えました。

# USB マウス用設定
Section "InputDevice"
        Identifier  "Mouse0"
        Driver      "mouse"
        option      "Protocol" "IMPS/2"
        Option      "Device" "/dev/input/mice"
        Option      "ZAxisMapping" "4 5"
        Option      "Emulate3Buttons" "yes"
EndSection

# Track Point 用設定
Section "InputDevice"
        Identifier  "Mouse9"
        Driver      "mouse"
        Option      "Protocol" "PS/2"
        Option      "Device" "/dev/psaux"
        Option      "ZAxisMapping" "4 5"
        Option      "AlwaysCore"
EndSection

ちなみに、Track Point(Option "Device" "/dev/psaux") に対して、
Option "ZAxisMapping" "4 5" は不要かもしれません。

[参考] http://www.gentoo.org/doc/ja/xorg-config.xml

戻る

ユーザID とグループID を一致させる

記憶がそれほど確かではないのですが、Vine 3.0 になってから?、/etc/group のグループ ID を確かめると、"cdwrite" というグループがグループ ID 500 で登録されるため、インストール時に設定したユーザ名(以下、INIT_USER とします) のユーザ ID は 500 となるのに、グループID が 501 となってしまいます。

このため、後で追加したユーザについても全て、ユーザ ID とグループ ID が 1 ずれてしまいます。

これまで、ユーザ ID とグループ ID は同じになる前提で、ファイルやディレクトリのアクセス権を管理してきたので、INIT_USER 登録に対して、ユーザ ID 500、グループ ID 500 となるよう、修正しました。

■ グループ "cdwrite" の削除
# groupdel cdwrite

■ ユーザ INIT_USER の削除
# userdel INIIT_USER
[注]
このコマンドを実行しても、/home/INIT_USER/ は削除されません。
/home/INIT_USER/ を削除したい場合は、
# userdel -r INIT_USER
とします。

■ ユーザ INIT_USER を再登録
# adduser INIT_USER
# passwd INIT_USER

■ グループ "cdwrite" をグループ ID 499 で登録
# groupadd -g 499 cdwrite

以上で、INIT_USER に対して、ユーザ ID 500、グループ ID 500 が設定されます。

戻る

NFS マウントの失敗対応

Client を Vine 3.2 kernel-2.4.31-0vl1.8 にアップグレードしたところ、起動時に NFSマウントに失敗します。ちなみに、Client側は /etc/fstab に NFSマウントを記述しています。また、Server側は Vine 2.6 を使っています。

Client の boot.log のメッセージは、以下のようになっています。

・・・・・・・・・・・・
Sep 24 08:37:15 ibmr40e portmap: portmap startup succeeded
Sep 24 08:37:15 ibmr40e nfslock: rpc.statd startup succeeded
Sep 24 08:37:16 ibmr40e autofs: autofs startup succeeded
Sep 24 08:37:16 ibmr40e random: Initializing random number generator: succeeded
Sep 24 08:37:16 ibmr40e mount: mount: RPC: Remote system error - Network is unreachable
Sep 24 08:37:16 ibmr40e mount: mount: RPC: Remote system error - Network is unreachable
Sep 24 08:37:16 ibmr40e netfs: Mounting NFS filesystems: failed
Sep 24 08:37:16 ibmr40e netfs: Mounting other filesystems: succeeded
・・・・・・・・・・・・

念のため、Vine 3.0 の kernel-2.4.27-0vl7.6 で起動すると正常に自動マウントされます。

原因がよく解からないのですが、どうも NFSマウント時にネットワークが未だ確立できていないように見受けられます。対症療法的ですが解決策として、以下の 2通りの方法で対応しました。

■ デーモンの起動順を変更する

boot.log によれば、NFS に関係しそうなデーモン portmap, nfslock, autofs は、正常に起動していますが、どうも netfs がネットワーク未通によって起動に失敗しているようです。そこで、/etc/rc.d/rc3.d/ 配下の起動デーモンへのリンク S25netfs を S53netfs に変更して起動を遅れさせてみたところ、うまくマウントできました。

■ /etc/rc.d/rc.local に mount コマンドを記述して、起動プロセスの最後で NFSマウントを実行する

/etc/rc.d/rc.local の最下行に NFS の mount コマンドを記述します。
mount -t nfs ph700:/mnt/hda8 /mnt/ph700/hda8 -o exec,dev,suid,rw

この方法では、起動途中でエラーメッセージがでますが、最後に正しくマウントされます。

[注]
ph700:/mnt/hda8 ⇒ Server(ph700)側の NFSディレクトリ(/mnt/hda8)
/mnt/ph700/hda8 ⇒ Client 側で NFS をマウントするディレクトリ

戻る

GRUB による起動用フロッピーディスク作成

私の場合、ブートローダに LILO を使ってますが、Vine 3.x になってから、FD の容量の問題でブート用フロッピーディスクが作成できなくなりました。Windows の再インストールが必要になった場合など、MBR が上書きされてしまうと、Linux の起動手段がなくなってしまいます。ブート用 CD-ROM を作るという手もありそうですが、FD で起動する方法を探していたら GRUB があることを知りました。以下、GRUB を使った起動ディスクの作成方法を記述します。

必要なパッケージ

■ grub-0.97-i386-pc.ext2fs
FD に書き込むイメージファイル
download from ftp://alpha.gnu.org/gnu/grub/

■ rawwritewin-07.zip
イメージファイルを FD に書き込むツール(Windows で実行)
download from http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm

手順

■ イメージファイルを FD に書き込む
ダウンロードした 2つのファイル、grub-0.97-i386-pc.ext2fs, rawwritewin-07.zip を Windows の適当なフォルダに配置します。

次いで FD をドライブにセットしてから、rawwritewin-07.zip を解凍し、生成した rawwritewin.exe を実行します。[Image File] として、grub-0.97-i386-pc.ext2fs を指定し、[Write] を実行すれば、イメージファイルが書き込まれます。作成された起動FD は、ext2 フォーマットになっています。

■ FD に /boot/grub/memu.lst を作成し、編集する
上記で作成した FD で起動した時に、OS選択メニューが表示されるように、FD に /boot/grub/memu.lst ファイルを作成します。

Vine 3.x の場合、このファイルが /boot/grub/menu.lst として存在します。Linux を起動し、上記 FD をマウントして、Linux の /boot/grub/menu.lst を FD の /boot/grub/ 配下にコピーします。Windows や他のディストリビューション、あるいは異なるカーネルバージョンを用いてマルチブートメニューにしたければ、好みに応じて編集します。

[注意]
Linuxカーネルバージョンがアップグレードされた場合、FD の menu.lst に書き込んだ Linuxカーネルバージョンも変更する必要があります。これは結構面倒な作業(というより忘れてしまいそうな作業)なので、FD の menu.lst に書き込んだ Linuxカーネルについては、カーネルのアップグレード後も削除しないで Linux の /boot/ 配下に残しておけば、FD の menu.lst のメンテは不要となります。

[見本]
参考までに、menu.lst の見本を以下に記述しておきます。

default=0
timeout=10
splashimage=(hd0,5)/boot/grub/splash.xpm.gz
title Vine Linux (2.4.26-0vl15)
    root (hd0,5)
    kernel /boot/vmlinuz-2.4.26-0vl15 ro root=/dev/hda6  resume2=swap:/dev/hda2
    initrd /boot/initrd-2.4.26-0vl15.img
title Windows
    rootnoverify (hd0,0)
    chainloader +1

HD のパーティションの指定方法が lilo.conf の場合と異なります。
hda ⇒ hd0 ; hda1 ⇒ (hd0,0) ; hda2 ⇒ (hd0,1) ; ・・・・・
hdb ⇒ hd1 ; hdb1 ⇒ (hd1,0) ; hdb2 ⇒ (hd1,1) ; ・・・・・
・・・・・
splashimage は、メニュー画面の背景画像なのでコメントアウトしても差し支えないでしょう。

[参考] http://www.atmarkit.co.jp/flinux/rensai/linuxtips/800grubbootfd.html

戻る

Emacs 関連のインストールと設定

追加のインストール

Vine 3.x インストール直後に Emacs を起動すると、xdvik-search のインストールが要求されます。これに関連して、aspell-el もインストールしました。

# apt-get update
# apt-get install xdvik-search
# apt get install aspell-el
# apt-get clean

追加の設定

HTMLファイルを Emacs で開くと、通常は文字コードが JIS として表示されます。私は、EUCコードで HTMLファイルを作成しているので、編集後は都度 M-x [Enter] f euc-jp-unix として EUCコードに変換して保存していました。

ところが、何故か原因が不明ですが、インストール直後から、HTMLファイルが EUCコードとして認識されるケースに遭遇しました。未だその理由がはっきりしていないのですが、これをきっかけに、HTMLファイルを EUCコードで読み込ませる方法を調べたところ、~/.emacs.el の設定を追加すれば可能であることが解かりました。

HTMLファイルは、通常 "yahtml" モードで読み込まれます。~/.emacs.el を調べると、以下の記述があります。

;; YaHtml-mode
(setq auto-mode-alist
      (cons (cons "\\.html$" 'yahtml-mode) auto-mode-alist))
(autoload 'yahtml-mode "yahtml" "Yet Another HTML mode" t)
(setq yahtml-www-browser "mozilla")

この記述の
(setq yahtml-www-browser "mozilla")
を
(setq yahtml-www-browser "mozilla"
      yahtml-kanji-code 3)
とすれば、HTMLファイルは EUCコードで読み込まれます。

ちなみに、yahtml-kanji-code の値は、1=Shift JIS, 2=JIS, 3=EUC です。

[参考]
http://www.namazu.org/~tsuchiya/elisp/yahtml-mode.html

戻る

vim の設定と jvim インストール

Vine 3.x になってから vi を使うと、何かやたらと単語の背景に色が着きます。特に単語検索を行うとその色が消えず、編集中のカーソルがどこにあるかも判別しがたくなります。これを解消するには、vim の設定ファイル /usr/share/vim/vimrc の設定を以下のように変更します。

■ 反転表示の取消
set hlsearch -> set nohlsearch

■ カラー表示の取消
syntax on -> syntax off

なお Vine 3.x では vim がデフォルトインストールされますが、jvim をインストールすれば、以前のすっきりした、余計な機能のない vi が使えます。私は、vim をアンインストールし、jvim に切替えています。

戻る

gcnmz, mknmz の異常な挙動

追加：2006年05月12日

正確にいつからとは特定できないのですが、今年になってから、月曜の朝に Namazu の検索ページ(namazu.cgi の画面) を表示すると、「現在、1 の文書がインデックス化され、。。。。」と表示されています。実際の文書数は、1000 を越えているのですが、何故か月曜の朝になるとこの現象が出て困っていました。その都度、全ての NMZ.* ファイルを削除し、mknmz を再実行するという応急処置で対応していました。

私の場合、cron を用いて mknmz を毎日早朝に実行、gcnmz を毎日曜日 mknmz 実行後に実行しています。現象から推察すると、この異常は、日曜日の gcnmz を実行後、次の mknmz を実行したときに発生しているように見受けられます。何度か現象の再現を試みた結果、異常が発生したとき、 mknmz が以下のエラーログを出力していることにに気づきました。

Argument "1,331" isn';t numeric in addition (+) at /usr/bin/mknmz line 2099.
Argument "1,331" isn't numeric in addition (+) at /usr/bin/mknmz line 2099.
Argument "1,331" isn't numeric in addition (+) at /usr/bin/mknmz line 2099.
Argument "1,331" isn't numeric in addition (+) at /usr/bin/mknmz line 2099.
Argument "1,331" isn't numeric in addition (+) at /usr/bin/mknmz line 2099.
Argument "1,331" isn't numeric in addition (+) at /usr/bin/mknmz line 2099.
Argument "1,331" isn't numeric in addition (+) at /usr/bin/mknmz line 1993.

/usr/bin/mknmz の 2099 行目で "1,331" が数値ではないと言っているようです。該当する行の Perl スクリプトは、

 
    if ($buf =~ /()\s*(.*)\s*()/) {
        my $total_files_count = util::commas(get_total_files() + $docid_count
                                   - $DeletedFilesCount - $UpdatedFilesCount);

となっています。どこかから、トータルファイル数を読んでいるように見受けられます。試行錯誤で調べた結果、NMZ.status からトータルファイル数を読んでいることが判りました。そこで、NMZ.status が場合によってどう変わるかをチェックした結果、以下のようになっていました。

通常日の mknmz 実行後
files 1331
keys 544974
argv -k -O      ../namazu       bicycle bukkyo  canon   freelink        link
linux   syasin
cwd /mnt/hda8/Web/public_html

gcnmz 実行後
files 1,331
keys 544,974
argv -k -O      ../namazu       bicycle bukkyo  canon   freelink        link
linux   syasin
cwd /mnt/hda8/Web/public_html

gcnmz 実行後に mknmz 実行後
files 1
keys 544974
argv -k -O      ../namazu       bicycle bukkyo  canon   freelink        link
linux   syasin
cwd /mnt/hda8/Web/public_html

エラーログと NMZ.status の変化から容易に推察できることは、gcnmz が間違った形式(「,」付き) のファイル数を NMZ.status に出力していて、mknmz がこのファイル数の読み込みに失敗したために、ファイル数を「1」にしてしまうという異常のようです。

現象の直接原因は判ったわけですが、どこを直せば正常にできるのか、そもそも、gcnmz のバグなのか ? と思い悩んだ末、とりあえず対症療法で対応することにしました。
cron で実行する gcnmz 実行スクリプトを以下のように設定し、NMZ.status の「,」付きファイル数を正常な数値に書き換えてしまうことにしたのです。

-------------------- gcnmz 実行スクリプト --------------------
#!/bin/sh
date > /usr/local/bin/gcnmz_log
gcnmz /mnt/hda8/Web/namazu >> /usr/local/bin/gcnmz_log 2>&1
cd /mnt/hda8/Web/namazu
mv NMZ.status NMZ.status.bk
perl -pe 's/,([0-9]{3})/\1/g' NMZ.status.bk > NMZ.status
--------------------------------------------------------------

一応これで異常現象はおさまり、ほっとしています。ところで、これは gcnmz のバグなのでしょうか ? 本当は、namazu.org のメーリングリストに質問すべきなのでしょうが、以前にある質問をしたところ、Vine が未だに古い namazu 2.0.13 を使っていることを難詰された経緯があり、質問をためらってしまいました。できれば、Vine もバージョンを最新のものにしていただきたいものです。

ただし、今回の問題は namazu 2.0.13 の問題ではないように思います。何故かと言うと、最新の namazu-2.0.13-1vl4.1.i386.rpm がリリースされたのは、2005年01月01日ですから、直接の原因であるとは考えられないからです。現象が発現した時期にアップグレードされて関係しそうなパッケージは、2006年01月01日にリリースされた perl-5.8.2-0vl4.2.i386.rpm ですが、素人が根拠のない嫌疑をかけるようなことは謹むべきでしょうね。

戻る

[フレッツ光プレミアムにおけるMTU問題]

作成：2007年01月04日

定年退職にともない、単身赴任先の横浜から滋賀県大津市にもどることになり、昨年12月に全てのネットワーク、サーバ機器を大津市に移転しました。とりあえずは、So-net ADSL 3M を契約したのですが、私の居住地ではどうも接続が不安定で、頻繁に接続が切れます。

これでは公開Webサーバの運用が難しいので、フレッツ光プレミアムに変更しました。接続が頻繁に途切れることもなく、快適に使用できているのですが、ある日、短いメールは発信できるのに、少し長いメールは発信できないことに気づきました。

通信技術の詳しいことはよく解らないまま、試行錯誤の結果、MTU の設定を修正することで解決できたので、その結果を以下に整理しました。

kh23-02.01 問題発生状況
kh23-02.02 原因の推測
kh23-02.03 対策
kh23-02.04 参考情報

戻る

問題発生状況

問題発生状況下でのネットワーク構成、インターフェース、パケットフィルタリングは、以下のようです。

通信・ネットワーク構成

　　　　　　　　　　　インターネット
　　　　　　　　　　　　　　│
　　　　　　　　　　　　プロバイダ
　　　　　　　　　　　　 (So-net)
　　　　　　　　　　　　　　│
　　　　　　　　　　　　　光回線
　　　　　　　(NTT西日本 フレッツ光プレミアム)
　　　　　　　　　　　　　　│
　　　　　　　　　　　　　┌┴─┐
　　　　　　　　　　　　　│ONU │
　　　　　　　　　　　　　└┬─┘
　　　　　　　　　　　　　　│
　　　　　　　　　　　　　┌┴─┐
　　　　　　　　　　　　　│CTU │
　　　　　　　　　　　　　└┬─┘
　　　　　　　　　　　　　　│
　　　　　　　　　　　　ppp0│Grobal IP
　　　　　　　　　　┌───┴───┐
　　　　　　　　　　│　　ルータ　　│
　　　　　　　　　　│公開Webサーバ │
　　　　　　　　　　├───────┤
　　　　　　　　　　│ローカルサーバ│
　　　　　　　　　　│[Telnet, FTP] │
　　　　　　　　　　├───────┤
　　　　　　　　　　│ (Vine Linux) │
　　　　　　　　　　└───┬───┘
　　　　　　　　　　　　eth0│192.168.0.3
　　　　　　　　　　　　　　│
　　　　　　　　　　　　　┌┴─┐
　　　　　　　　　　　　　│HUB │
　　　　　　　　　　　　　└┬─┘
　　　　　　　　　　　　　　│
　　　　┌─────────┼─────────┐
　　　　│　　　　　　　　　│　　　　　　　　　│
　　eth0│192.168.0.5 　eth0│192.168.0.4 　eth0│192.168.0.2
┌───┴───┐　　┌──┴───┐　　┌──┴───┐
│ローカルサーバ│　　│ローカルPC-1│　　│ローカルPC-2│
│[Samba , NFS] │　　├──────┤　　├──────┤
│[Telnet, FTP] │　　│(Vine Linux)│　　│(Vine Linux)│
├───────┤　　│(WindowsXP) │　　│(Windows98) │
│ (Vine Linux) │　　└──────┘　　└──────┘
└───────┘

ネットワークインターフェース(ifconfig の出力結果)

■ ルータ

ppp0 リンク方法:Point-to-Pointプロトコル
inetアドレス:59.146.28.xxx P-t-P:210.247.16.1 マスク:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1438 Metric:1
eth0 リンク方法:イーサネットハードウェアアドレス xx:xx:xx:xx:xx:xx
inetアドレス:192.168.0.3 ブロードキャスト:192.168.0.255 マスク:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

■ ローカルPC(メールクライアント)

eth0 リンク方法:イーサネットハードウェアアドレス xx:xx:xx:xx:xx:xx
inetアドレス:192.168.0.xxx ブロードキャスト:192.168.0.255 マスク:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

パケットフィルタリング

■ ルータ

ESTABLISHED パケットは、INPUT, OUTPUT, FORWARD いずれも ACCEPT
ICMP パケットは、INPUT, OUTPUT, FORWARD いずれも DROP
INPUT は、port 80tcp(http), 443tcp(https) のみ ACCEPT
OUTPUT は、port 53udp(dns), 80tcp(http), 123udp(ntp), 443tcp(https) のみ ACCEPT
ローカル-->インターネットの FORWARD は、port 21tcp(FTP), 1024-tcp(FTP), 25tcp(smtp), 53udp(dns), 80tcp(http), 110tcp(pop3), 123udp(ntp), 443tcp(https) のみ ACCEPT

■ ローカルPC(メールクライアント)

ESTABLISHED パケットは、INPUT, OUTPUT, FORWARD いずれも ACCEPT
ICMP パケットは、INPUT, OUTPUT, FORWARD いずれも DROP
INPUT は、ESTABLISHED 以外 DROP
OUTPUT は、すべて ACCEPT

戻る

原因の推測

参考情報 1. MTU 設定に関する情報(引用)

: Bフレッツ、フレッツ・ADSLのPPPoEとは以下の相違点があります。そのため、端末（ルータ、PPPoEクライアントソフト）によっては、ご利用いただけない場合もあります。
〔データのパケットサイズ（MTUサイズ）〕
　フレッツ・光プレミアム：1438Byte
　Ｂフレッツ　　　　　　：1454Byte
PPPoEセッション接続時に行う地域IP網側とのネゴシエーションにより自動的にMTUサイズの調整を行いますが、利用端末によってはネゴシエーションができずにパケットが破棄される場合があります。その場合は端末設定でMTUサイズを1438byte以下に設定してください。

参考情報 2. PPPoE 接続に関する情報(引用)

PPPoE を利用する場合、例えば

端末(受信側) では MTU=1454,MSS=1414
サーバ(提供側) では mtudisc=1
ルータ(経路機器) では ICMP DU FN をきちんと返すこと、パケットの分割・組立の動作を確認

などとしておく。

参考情報 3. MTU 設定に関する情報(引用)

ネットワークで送信可能なパケットの最大サイズをMTUという。IPパケットのサイズがMTUサイズを超えるとパケットの分割処理が行われる。これをIPフラグメンテーションという。
フラグメントしたIPパケットはファイアウォールでブロックされることがある。その結果、サイトによってWebページが見られなくなったり、接続不能になったりするトラブルが生じる可能性がある。
このような場合は、ネットワーク・インターフェイスのMTUを変更して、フラグメントが起こらないようにすればよい。

補足

MTU: Maximum Transmission Unit / 送信時の最大転送単位

MSS: Maximum Segment Size / TCPで通信を行なう際に指定する、データの受信単位(セグメント)の最大値。

ICMP DU FN: ICMPパケットのタイプで、destination-unreachable(DU) の内の、fragmentation-needed(FN) タイプ

以上を総合的に考察すると、ルータは、ppp0 MTU=1438 となっているので、ルータと光回線の接続は問題なさそうです。問題の原因としては以下が推測されます。

ルータの eth0、クライアントPC の eth0 はいずれも MTU=1500 なので、これが原因でパケットが So-net の SMTPサーバに届かない。
ICMPパケットは、ルータおよびローカルPC のすべてのネットワークインターフェースで DROP しているので、DU FN パケットが通らず、フラグメンテーション処理ができない。
そもそも、So-net の SMTPサーバが、IPフラグメンテーションを受け付けない。

戻る