みたのブログ

NFS v4 の SSH トンネル

ファイヤーウォールやプライベートネットワークのなかのマシンを NFS マウントしたいときもあると思います。SSH ポートフォワーディングができて NFS v4 が利用できるなら、以下のように三つのことだけやればできると思います。想定しているネットワークは下の方の図を参照してください。

1. insecure エキスポートオプション

NFS v4 サーバーでファイルシステムを insecure オプションをつけてエキスポートします。

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
/opt    *(rw,fsid=0,insecure)

2. SSH ポートフォワーディング

NFS サーバのポート番号 2049 と NFS クライアントのローカルの適当なポート番号 (例えば 12049) を SSH サーバ経由でポートフォワーディングします。

root@nfsv4client # ssh -f -N -C mita@sshd.example.com -L 12049:nfs4d.example.com:2049

3. port= マウントオプション

ローカルホストのポートフォワーディングしたポート (ここでは 12049) に対して port= マウントオプションを指定してマウントします。

root@nfsv4client # mount -t nfs4 -o port=12049 localhost:/ /mnt/nfs

また /etc/fstab に以下のようなエントリを追加しておいてもいいと思います。

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
...
localhost:/     /mnt/nfs        nfs4    noauto,port=12049       1 0

簡単にするため NFS v4 の基本的な設定については省略してしまいましたが Projects: NFS Version 4 Open Source Reference Implementation: などが参考になると思います。

カーネルに組み込まれたモジュールの場合はどうですか

サーバセレクトという雑誌の六月号のボツになった記事のつづきです。

カーネルに組み込んでビルドされたモジュールのモジュールパラメータを設定したい場合は、カーネルのブートオプションとして設定する必要があります。

例えば e100 ネットワークドライバをカーネルに組み込んでビルドし、そのモジュールパラメータ debug を 1 に設定したい場合は e1000.debug=1 というブートオプションを与えます。

つまり、以下のようにブートオプションを設定します。

<モジュール名>.<モジュールパラメータ名>=<モジュールパラメータ値>

またカーネルに組み込まれたモジュールについての情報は modinfo コマンドで表示することはできません。ただし、カーネルイメージ vmlinux があれば、つぎのようにして組み込みモジュールパラメータの一覧を知ることができます。

$ nm -n vmlinux | grep __param_str_ | \
  awk '{ print "p (char *) 0x" $1}' > list-param.cmd
$ gdb -batch -x list-param.cmd vmlinux | awk '{print $4}'

モジュールパラメータの一覧はどうやったらわかりますか

サーバセレクトという雑誌の六月号のボツになった記事の抜粋のつづきです。

モジュールについての情報を得るには modinfo コマンドを利用します。設定可能なモジュールパラメータの説明だけ表示したい場合はつぎのようにします。

# modinfo -p <モジュール名>

モジュールをロードしたあとに動的に変更できるものや、設定値を参照する価値のあるモジュールパラメータは sysfs ファイルシステムの以下のファイルから読み書きできるようになっています。

/sys/module/<モジュール名>/parameters/<パラメータ名>

ブートオプションの一覧はどうやったらわかりますか

サーバセレクトという雑誌の六月号ボツになった記事の抜粋のつづきです

Documentation/kernel-parameters にブートオプションの一覧や解説が書かれています。ただし、カーネルコンフィギュレーションによっては無効のものもありますし、このファイルには記述されていないものもあります。

もし利用しているカーネルイメージ vmlinux があればつぎのようにしてブートオプションの一覧を得ることができます。

$ nm -n vmlinux | grep __setup_str_[a-zA-Z_] | \
  awk '{ print "p (char *) 0x" $1}' > list-setup.cmd
$ gdb -batch -x list-setup.cmd vmlinux | awk '{print $4}'

ただし、vga ブートオプションや parse_cmdline_early() (arch/i386/setup.c) のなかで設定されているような一部のブートオプションは表示されません。

障害に備えて役立ちそうなブートオプションを教えてください

会社の業務の一環でサーバセレクトという雑誌の六月号に 4 ページ記事を書きました、 いま日本にもどっているので、ちょっと気になって確認してみたところページの都合上いくつかボツになっている部分があったので、それを抜粋して紹介します。

• panic=
• panic_on_oops=

kernel.panic と kernel.panic_on_oops カーネルパラメータと同じ設定をするブートオプションです。

なぜ同じような設定がカーネルパラメータとブートオプションの両方にあるかという理由は、カーネルパラメータは通常 /etc/sysctl.conf の設定ファイルに記述されたものがシステムの起動スクリプト実行中に設定されます。それ以前に パニックや Oops が起こる場合に備えて、デフォルト値 (panic=0, panic_on_oops=0) 以外に設定したい場合に利用します。

• log_buf_len=<buf_len>

ログバッファの値をバイト単位で指定します。 SysRq-t などで大量のカーネルログを出力させたとき、ログバッファが溢れてしまう場合にはこのオプションでログバッファのサイズを大きくすることができます。ログを dmesg コマンドで見る場合には -s オプションで充分大きな値を指定する必要があるかもしれません。

以下の二つのブートオプションは起動時のトラブルに役立ちます。

• initcall_debug=1

カーネルの各初期化関数または、カーネルに組み込んでビルドしたモジュールの初期化関数を実行する前にその関数名を表示します。

Calling initcall 0xc03bc72c: init_mbcache+0x0/0x16()
Calling initcall 0xc03bc742: dquot_init+0x0/0xd3()
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Calling initcall 0xc03bc815: dnotify_init+0x0/0x22()
...

• earlyprintk=vga vga=ask

printk() の出力を画面に表示するため機能が初期化される前の可能な限り早い段階でカーネルログが画面に表示できるようになります。ブートローダがカーネルイメージを読み込んだあと画面になにも表示されないままになってしまう場合は、これを試してみる価値があります。

• nmi_watchdog=

NMI ウォッチドッグ機能によってローカルタイマー割り込みが長時間発生していないことを検知して Oops メッセージを出力させます。コールトレースを調べれば、どこでロックアップしたか分かります。(Documentation/nmi_watchdog.txt)

 

Ext3 ファイルシステムで削除したファイルを復元について (2)

grep で削除したファイルの内容が含まれているブロックを探す際に、二つ落し穴があることが分かったので補足しておきます。

[1] ファイルに含まれている先頭の行のキーワードで検索する場合

たとえば、自作の Python スクリプトをうっかり削除してしまったものの、中身について全く記憶がない場合、とりあえず Python スクリプトの先頭ブロックをリストアップしようと、次のようにしたくなるかもしれません。

# grep -a -b '#!/usr/bin/python' /dev/hda1

しかし、たとえばそのファイルのひとつ前のブロックが何か別のファイルの末尾のブロックで次のようなレイアウトになっていたとします。

29fbf90   L   A   R   =   y  \n  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
29fbfa0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
*
29fc000   #   !   /   u   s   r   /   b   i   n   /   p   y   t   h   o

grep の -b オプションで出力されるオフセットは、マッチしたパターンが含まれている行の先頭の位置です。マッチしたパターンの先頭の文字の位置ではありませんでした。だから grep -b はひとつ前のブロックの改行の次のオフセットを表示してしまいます。

これを避ける簡単な方法をいろいろ考えたのですが、grep の代わりに次のように perl で検索するというのもいいかもしれません。

# perl -n -e 'BEGIN { undef $/; }' -e 'while (m/<パターン>/g) { printf "%d\n", pos(); }'

#!/usr/bin/perl

$block_size = 1024;
$blkno = 0;
open(FH, "< /dev/hda1") or die "can't open $!";
while (read(FH, $block, $block_size)) {
        if ($block =~ m|\#!/usr/bin/python|) {
                print "$blkno\n";
        }
        $blkno += 1;
}

[2] ファイルサイズがブロックサイズより大きくて、キーワードが二つのブロックにまたがっていて、さらにその二つが連続したブロックに割り当てられていなかった場合

これにひっかかるケースはまれかもしれませんので、検索するパターンをちょっと変えれば避けれると思います。

Ext3 ファイルシステムで削除したファイルを復元について

うっかりファイルを消してしまったりすることは、よくあると思います。

いろいろ事情があって、ext3 ファイルシステムで削除したファイルの復元について、半日ぐらい調べていました。 恥ずかしながら ext2 の場合も同じだろうと ext2 の場合の復元方法を一生懸命テストしたり、古い文書やメーリングリストの議論に惑わされたりしながら、やっと Linux ext3 FAQ のなかの ext3 の開発者のひとりの引用を読んで調査が終了しました。

Q: How can I recover (undelete) deleted files from my ext3 partition?

つまり ext2 の場合は、ファイルを削除するとき inode を "deleted" としるしをつけるだけなので、 debugfs コマンドの lsdel で削除された inode の一覧を得ることができるし、その削除された inode 番号に対して debugfs コマンドの dump でファイルの中身もだいたい復元できることが期待できます。

# debugfs -R lsdel /dev/sdb1 > /tmp/lsdel.lst
# vi /tmp/lsdel.lst <間違って削除した日時とかで該当しそうな行だけ残す>
# awk '{printf "dump <%d> /tmp/undel.%d\n", $1, $1}' /tmp/lsdel.lst > /tmp/debugfs.cmd
# debugfs -f debugfs.cmd /dev/sdb1

しかし ext3 の場合は、ファイルを削除すると、inode からデータブロックへの参照をきれいにクリアするので inode からデータブロックをたどることができません。唯一の望みは grep でファイルの断片を見つけることぐらいとのことです。

1. まず、ブロックデバイスでもディスクイメージでもいいのですが、 dumpe2fs コマンドなどでブロックサイズを調べます。 この ext3 ファイルシステムのブロックサイズは 4096 バイトでした。

# dumpe2fs /dev/sdb1
...

Block size:               4096
...

2. grep の -b オプションでキーワードがマッチしたオフセットを表示するようにして、なにかファイルに保存しておきます。

# grep -a -b 'BEGIN RSA PRIVATE KEY' /dev/sdb1 | awk -F: '{print $1}' > list

追記: この grep での検索にはいくつか落し穴があったので、こちらのエントリも参照してください。

3. キーワードが含まれているブロックをファイルに保存します。

# cat list | while read i; do
    dd if=/dev/sda1 of=$i.data bs=4096 count=1 skip=$(($i/4096))
  done

4. 見つかったブロックの中身をひとつひとつチェックして削除したファイルを地道に探します。

メールとか自分で書いたプログラムとかのユニークなキーワードをおぼえていたら削除したファイルでもなんとか復元できるかもしれません。ファイルサイズがブロックサイズより大きくても、 ext3 はなるべく近くのブロックに割り当てるようにしているのでファイルシステムがひどく断片化していなければ、その辺の連続したブロックに同じファイルの内容が保存されている可能性が高いと思います。実際、ある 50KB ほどの削除してしまったテキストファイルを多分無傷で復旧できたということだけ伝えておきます。

Hamming weight

お金を払っていないので一週間遅れでしか読めないのですが LWN.net Weekly Edition というのを毎週目を通すようにしています。

先週号を一週間遅れで見ていると、 A summary of 2.6.17 API changes と題されたリリース間近の 2.6.17 での主なカーネル API の変更点がリストアップされている記事があり、そのなかで僕が少しまえにした変更について一行ふれられていました。

* A whole set of generic bit operations (find first set, count set bits, etc.) has been added, helping to unify this code across architectures and subsystems.

パッチは Patch: generic bitops からたどってもらえると見れるのですが、ほとんどが単純で地道な作業なのでつまらないと思います。ただし、セットされているビット数を数える速い方法については見る価値はあるかもしれません。

セットされているビット数のことを "Hamming weight" とか "popcount" (population count) といった呼び方をされるようです。たとえば 32-bit の整数の hamming weight は、ひとつひとつビットをチェックして数えていくより、つぎのようにしたほうが少ないステップで計算できます。

static inline unsigned int generic_hweight32(unsigned int w)
{
        unsigned int res = (w & 0x55555555) + ((w >> 1) & 0x55555555);
        res = (res & 0x33333333) + ((res >> 2) & 0x33333333);
        res = (res & 0x0F0F0F0F) + ((res >> 4) & 0x0F0F0F0F);
        res = (res & 0x00FF00FF) + ((res >> 8) & 0x00FF00FF);
        return (res & 0x0000FFFF) + ((res >> 16) & 0x0000FFFF);
}

まず 32-bit の整数は 32 個の 1-bit ビットフィールドで、それぞれのビットフィールドが 1-bit の hamming weight になっていると考えることができます。つぎに 1-bit ビットフィールドを二組づつ組み合わせて足すと 16 個の 2-bit ビットフィールドは、それぞれのビットフィールドが 2-bit の hamming weight になっています。このようにくりかえしていけば、もとの 1 個の 32-bit フィールドの hamming weight が計算できます。

n-bit の hamming weight は最大でも n で、それを二つ足しても 2 の 2*n 乗より小さいのでそれぞれのステップでオーバフローしてしまうことはないので上のような工夫したマスクをかけて計算できるのですが、もっと工夫するともうちょっと効率的に計算できます。詳しくは linux@horizon.com というひとの証明をご覧ください。

http://lkml.org/lkml/2006/1/31/152

Bisection searches

あるプログラムをバージョンアップすると、それまでちゃんと動いていたのに何か動作がおかしくなってしまうということはよくあると思います。

再現性のあるバグがあって、ちゃんと動作するバージョンと、そうでないバージョンがあってそのプログラムが適切にバージョン管理されていれば、ほとんどの場合バージョン間の二分探索することによって、そのバグがいつどの変更によって引き起こされるようになったか特定することができます。

Linux kernel は、 v2.6.12 ぐらいから git というリビジョン管理システムで管理されていて、 上記のようなバグの二分探索は git-bisect というツールでおこなえます。

http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

たとえば v2.6.16 ではちゃんと動いていたけど v2.6.17-rc5 にアップデートしたらなにかがうまく動かなくなった場合、v2.6.16 から v2.6.17-rc5 までの間の変更によって引き起こされたと考えられます。その間にコミットされたパッチの数は

$ git-rev-list v2.6.17-rc5 ^v2.6.16 | wc -l
5861

5861 個あるようです。中間のリビジョンをコンパイルして一回試すごとにバグを引き起こす可能性のあるパッチの数を半分にできるので、5861 が 2 の何乗か分かればだいたい何回ぐらい試せばバグを引き起こすパッチを特定できるのか分かると思います。

ここで高校の時の数学をがんばって思い出してみて 2 を底とする log(5861) を計算します。

$ echo 'l(5861)/l(2)' | bc -l
12.51693112199869637797

だいたい 13 回ぐらいコンパイルして試せば問題のパッチを特定できます。
カーネルのコンパイルなので時間はかかるかもしれませんが、13 回ぐらいなら大した数ではないと思います。たとえ v2.6.12 から v2.6.17-rc5 の間を bisect しても

$ git-rev-list v2.6.17-rc5 ^v2.6.12 | wc -l
25110
$ echo 'l(25110)/l(2)' | bc -l
14.61597440815886228263

15 回ぐらいです。

[PATCH] loop: online resize support

前回のエントリで紹介した Loopback デバイスのオンラインリサイズを可能にするパッチを Linux kernel mailing list に送りました。

http://lkml.org/lkml/2006/5/23/26

Andrew Morton からいろいろとコメントをもらって Loopback デバイスのオンラインリサイズというのが無意味なアイデアでもないということが分かり安心しました。

あとから気がついたこととして、 device-mapper ではオンラインリサイズする時に、ファイルシステムをフリーズしたりとか排他制御をしているようです。だから Loopback デバイスのオンラインリサイズをサポートするとしたらその辺もきちんとしたほうがいいのかもしれません。

Loopback デバイスのオンラインリサイズ

最近のカーネルの Ext3 ファイルシステムはオンラインリサイズに対応しています。
オンラインリサイズというのはマウントしたままでファイルシステムのサイズを大きくすることです。いったんアンマウントしてもいいのなら、昔から resize2fs というプログラムでリサイズすることができました。

ファイルシステムの方でオンラインリサイズに対応していても、そのファイルシステムが含まれているブロックデバイスをオンラインリサイズできなければあまり意味がありません。普通なら LVM とかをつかってオンラインリサイズするのですが、テスト用途とかディスクイメージを作っていて途中で容量が足りなくなってしまったときとか Loopback デバイスを利用したいときもあると思います。

ext2online コマンドのマニュアルに Loopback デバイスを使ってオンラインリサイズのテストをする以下のような例が載っているのですが (ただし Ext2 ファイルシステムのオンラインリサイズ機能はアップストリームに取り込まれていないのでこの通り実行するには Ext2 用のオンラインリサイズが有効になっているカーネルが必要です)

dd if=/dev/zero of=/tmp/file bs=1k count=64k
mke2fs -F -f 32768 /tmp/file
mkdir /tmp/test
mount -o loop,debug,check=strict /tmp/file /tmp/test
df /mnt/test
ext2online -d -v /tmp/file
df /tmp/test

あらかじめファイルシステムをイメージファイルのサイズよりわざと小さい大きさで作成して、そのあとイメージファイルの大きさまでオンラインリサイズするという、あまり意味のない例になっています。

いろいろ調べて分かったことは、Loopback デバイスのサイズはマウントされたままでは更新できないということです。(2.6.17-rc4)

ブロックデバイスの実際にアクセス可能な最大のオフセットは、ブロックデバイスに対して ioctl システムコールで BLKGETSIZE/BLKGETSIZE64 コマンドを実行して得ることのできて、つぎのコマンドで確認できます。

sfdisk -s <ブロックデバイスファイル>

それとは別に、ブロックデバイスの capacity という値もあって、つぎのコマンドで確認できるものです。

cat /sys/block/<ブロックデバイス名>/size

この二つのサイズに関係する値の関係はつぎのようになっています。
capacity はブロックデバイスのドライバがデバイスを検出したときに設定されて、誰かがはじめてそのブロックデバイスをオープンしたとき (ブロックデバイスなので大体はマウントするとき) に capacity に相当するサイズがブロックデバイスのサイズに設定されます。基本的にはブロックデバイスを誰も参照しなくなって、また誰かがはじめてオープンするまでたとえ capacity がブロックデバイスのドライバによって変更されたとしてもブロックデバイスのサイズは変わりません。つまりいったん完全にアンマウントしてなければブロックデバイスのサイズは変わりません。リマウントでも変わりません。

LVM は例外でロジカルボリュームを変更したときに、capacity の値とブロックデバイスのサイズも一緒に変えているのでアンマウントしなくてもサイズが更新されます。

はなしを Loopback デバイスに戻すと、Loopback デバイスに対して ioctl システムコールを工夫して実行すると (LOOP_SET_STATUS/LOOP_SET_STATUS64 コマンドを実行して sizelimit という値を拡張したファイルサイズより大きい値に変更する) ブロックデバイスの capacity は実際の Loopback デバイスを参照しているファイルサイズに更新することができますが、ブロックデバイスのサイズを変えるようなことはしません。だから上記で説明したように capacity がブロックデバイスのサイズに反映されるには一回完全にアンマウントしてからマウントしなければいけません。

そこで Loopback デバイスもオンラインリサイズできるようにする小さいパッチを作成しました。Loopback デバイスに対する LOOP_UPDATE_SIZE という新しい ioctl システムコールのコマンドを追加しました。これを実行すると Loopback デバイスのサイズを Loopback デバイスの参照しているファイルの現在のサイズに更新します。

1. このパッチをあてたカーネルで起動します。loop-update-size.patchをダウンロード
2. 10MB の Ext3 ファイルシステムのディスクイメージを作成します。

# dd if=/dev/zero of=image bs=1k count=10k
# mkfs.ext3 -j -F image

3. それをループバックマウントします。

# mkdir loop
# mount -o loop=/dev/loop/0,debug -t ext3 image loop

リサイズ前のファイルシステムのサイズを確認しておきます。

# df -h loop
Filesystem            Size  Used Avail Use% Mounted on
/home/mita/looback-test/image
                      9.7M  1.1M  8.2M  12% /home/mita/looback-test/loop

4. ディスクイメージを 20MB に拡張します。

# dd if=/dev/zero of=appendix bs=1k count=10k
# cat appendix >> image

ループバックデバイスのサイズは 10MB のままです。

# sfdisk -s /dev/loop/0
10240

5. ループバックデバイスに対して ioctl で LOOP_UPDATE_SIZE コマンドを実行してブロックデバイスのサイズをオンラインで 20MB に拡張します。

# gcc -o loop-update loop-update.c (loop-update.cをダウンロード)
# ./loop-update /dev/loop/0

ループバックデバイスのサイズは 20MB に更新されています。

# sfdisk -s /dev/loop/0
20480

6. ext2online コマンドで Ext3 ファイルシステムを拡張します。

# ext2online -d -v image

リサイズ後のファイルシステムのサイズを確認します。

# df -h loop
Filesystem            Size  Used Avail Use% Mounted on
/home/mita/looback-test/image
                       20M  1.1M   18M   6% /home/mita/looback-test/loop

IrDA で携帯電話とデータ通信

ThinkPad X31 には IrDA 通信機能がついているので、ちょっと試してみようと思い IrDA 対応機器を身の回りで探してみると、いま使っている携帯電話 NOKIA6108 が対応していました。

カーネルの設定とかは gnokii というノキアの携帯電話とのデータ通信用のプログラムに付属の文書 "Docs/gnokii-IrDA-Linux" が役立ちました。

gnokii は 6108 には対応していないらしく、電話帳の保存とかいろいろうまくいかなかったので、結局 scmxx という Siemens の携帯電話用のデータ通信プログラムを使いました。以降で説明するように、これはとてもうまく動作しました。

ThinkPad X31 についている IrDA チップセット用のドライバは nsc-ircc で、この文書で紹介してあるのと一緒だったのでほどんどその通り実行しただけです。

ただし、 nsc-ircc のモジュールオプションとして、 dongle_id=9 を与えるというのが何の説明もなしに書かれていて分かりにくいので、分かった範囲で補足しておきます。

nsc-ircc ドライバは初期化のときに dongle id というのを検出するようになっているのですが、検出ルーチンにバグがあるためか、違う dongle id を検出してしまうことがあるようです。具体的には、 "IBM0071" という PNP ID のチップセットだとおかしな事が起こるようです。(Ubuntu の /etc/init.d/irda-setup によると) 次のコマンドで確認できます。

# cat /sys/bus/pnp/devices/*/id | grep IBM0071

この場合は dongle_id=9 というモジュールパラメータを与えて dongle_id 検出ルーチンをスキップして、明示的に設定して回避します。(2.6.17-rc3)

# modprobe -r nsc-ircc
# modprobe nsc-ircc dongle_id=9
# irattach irda0 -s

Linux マシンの側からの準備ができたので今度は、携帯電話の側から IrDA 通信を始めます。

トップ画面から Menu --> Connectivity --> Infrared を選択すると IrDA 通信中を示すマークが点灯するので、赤外線が出る部分同士をお互いに向けるとデータ通信が可能になります。

Linux マシンにもどってデータ通信用のプログラム SCMxx  を使います。

まずはじめに携帯電話のアクセス可能なメモリの情報を調べます。

# scmxx --device=/dev/ircomm0 --mem-info

Accessing device ircomm0...done
Using "UTF-8" as system character set.
OK, a modem device is present.
Warning: phones from this vendor were not confirmed to be working with this software!
Binary files:
mem  readable  writable  description
---  --------  --------  -----------

Phonebooks:
mem  slots   writable  digits  chars  description
---  ------  --------  ------  -----  -----------
ME    1-500     yes      48      50   mobile equipment phonebook
DC    1-20      yes      48      50   last calls (mobile)
MC    1-10      yes      48      50   missed calls
RC    1-10      yes      48      50   callback numbers
SM    1-100     yes      48      14   SIM phonebook
FD    1-10      yes      48      14   SIM fix-dialing phonebook

SMS storages:
mem   slots     used    description
---  ------  ---------  -----------
ME    1-150    23/150   mobile equipment memory
SM    1-25     24/25    SIM memory

電話帳 (Phonebook) とショートメッセージ (SMS storages) のメモリの読み書きができることが分かります。一番左の列の ME とか SM とかというのが　scmxx コマンドの --mem オプションに与える識別子になります。

例えば、電話帳を全部読み出したい場合は、Phonebook の ME メモリを読み出せばいいので以下のようにします。

# scmxx --device=/dev/ircomm0 --get --pbook --mem=ME --out -

Accessing device ircomm0...done
Using "UTF-8" as system character set.
OK, a modem device is present.
Warning: phones from this vendor were not confirmed to be working with this software!
Receiving phonebook entries ME(1-500)...
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55

...

486 487 488 489 490 491 492 493 494 495 496 497 498 499 500
done

1,"13611111111",工作美田"
2,"13722222222",美田"
3,"13633333333",Jong O"
4,"13544444444","Jun"

...

499,"",""
500,"",""

携帯電話の電話帳に 名前 "test" 電話番号 "1234" を保存するには ...

# scmxx --device=/dev/ircomm0 --send --pbook --mem=ME --text=test --number=1234

Accessing device ircomm0...done
Using "UTF-8" as system character set.
OK, a modem device is present.
Warning: phones from this vendor were not confirmed to be working with this software!
Trying to find an empty slot...
Detected empty slot 23
Updating one entry in slot 23 of memory ME...done

SIM メモリにはいっているショートメッセージを全部読み出すには ...

# scmxx --device=/dev/ircomm0 --get --sms --mem=SM --slot=all --out -

Accessing device /dev/ircomm0...done
Using "UTF-8" as system character set.
OK, a modem device is present.
Warning: phones from this vendor were not confirmed to be working with this software!
Looking for SMS of specified type...
Found incoming, read SMS in slot 1.
Found incoming, read SMS in slot 2.
Found incoming, read SMS in slot 3.

...

Found incoming, read SMS in slot 24.
Found incoming, read SMS in slot 25.
Slot: 1
From: +8613*********
Date: 2006年05月09日 20時12分28秒
SMSC number: +8613800100500
PDU type: SMS-DELIVER
PDU flags: StatusRequest MoreMessagesToSend
Data coding scheme: UCS-2 (class 0)
Message length: 3

你好。

Slot: 2
From: +8613*********
Date: 2006年05月09日 20時40分53秒
SMSC number: +8613800100500
PDU type: SMS-DELIVER
PDU flags: StatusRequest MoreMessagesToSend
Data coding scheme: UCS-2 (class 0)
Message length: 20

...

電話番号 1234 に "Hello world." とショートメッセージを送るには ...

# scmxx --device=/dev/ircomm0 --send --sms --direct --number=1234 --text='Hello world.'

Accessing device ircomm0...done
Using "UTF-8" as system character set.
OK, a modem device is present.
Warning: phones from this vendor were not confirmed to be working with this software!
Creating PDU...
Waiting for data request...
Sending data...
The message was sent. Message reference: 72
The phone returned: OK