仙石浩明の日記

プログラミングと開発環境

2017年8月11日

ZenFone3 で撮影した写真ファイル内の、位置情報が壊れている Exif データを修復するコードを書いてみた

昨年発表された ASUS のハイエンド スマホ ZenFone 3 Deluxe ZS570KL の購入時の OS は Android 6.0 Marshmallow だが、 この OS (UL-Z016-WW-4.12.40.1698) の標準のカメラ アプリには、 撮影した写真の位置情報が他のアプリで参照できないというバグがあった。

つまり、 カメラの設定で 「場所サービス」 を 「オン」 にすると、 撮影した場所 (GPS などの位置情報) を写真ファイルに付加する (Exif データ) が、 この位置情報に問題があって、 他のアプリで写真を見ても位置情報が表示されない。 例えば撮影した写真を Google フォトへアップロードしても、 撮影場所が表示されない

browsed with Gallery Application

この写真を Google フォトからダウンロードしてみれば、 Exif データ内に位置情報が保持されていることが分かるし、 アプリによってはこの位置情報を参照できるものもある。

例えば OS 標準の 「ギャラリー」 アプリで見ると、 位置情報が正しく保持されているように見える。 例えば、 御成町の交差点で撮影したこの写真を 「ギャラリー」 で見ると (右図 ⇒ ZenFone のスクリーンショット)、 場所が 「鎌倉市, 御成町」 と正しく表示される。

位置情報を正しく表示できるアプリがある以上、 バグではなく仕様 (Exif のバージョンの違い?) の可能性もある。 このとき私は、 この写真の位置情報を参照できないアプリは、 アプリ側にも問題があるのだろうと思ってしまった。 おそらく開発元でも同様の理由で、 このバグが見逃されてしまったのだろう。

そしてもし仕様なら、 Google フォトで撮影場所が表示されない問題も、 そのうち (Google 側で) 解決されるのだろうと思って放置してしまった。 ところが先日バンクーバーに行ったことで、 これは仕様などではなく、 紛れもないバグだったことを確信した。

browsed with Gallery Application

つまり、 日本や ZenFone 製造元である台湾など、 「東経」 な地域では正しい場所が表示されるが、 バンクーバーなど 「西経」 な地域だと全くかけ離れた場所が表示されてしまうということ。

例えば、 バンクーバーで撮った写真を 「ギャラリー」 で見ると (右図 ⇒ ZenFone のスクリーンショット)、 場所が 「内モンゴル, フルンボイル, オロチョン自治旗, 中華人民共和国」 などと広大な草原の真っ只中な場所が表示されてしまう (データが無いためか地図が真っ白, そもそも 「自治旗」 なんて行政単位は初めて見た)。 「49.288132,123.130722」 という位置座標を、 「49.288132,-123.130722」 に直してみる (経度をマイナスにしてみる) と、 正しい座標になることから、 「西経」 で撮影しても 「東経」 で記録してしまうバグであることが分かった。

もちろん、 このバグは現行の Android 7.0 Nougat では修正されているが、 Android 7.0 へ更新する前に撮影した写真ファイルの位置情報は (当然のことながら) 壊れたままなので不便このうえない。

そこで Android 6.0 の時に撮影した写真ファイルの位置情報を、 修正してみることにした。 まずは Exif データに保持された位置情報の何が問題なのか調べてみる。

Exif データの構造」 という検索語でググってみると、 いくつか解説ページが見つかる。 ありがたいことに 「Exif データにアクセスするコード」 まで見つかった (libexif project のような本格的なライブラリだと読むのが大変)。 長い解説文よりも動く簡潔なコードの方が話が早い。

コードを読みつつ、 まずは動かしてみて、 ZenFone 3 で撮影した写真ファイルの何がマズイのか調べてみる。

senri:~ $ gcc -o exif sample_main.c exif.c
senri:~ $ ./exif P_20170701_100640_vHDR_Auto.jpg
[P_20170701_100640_vHDR_Auto.jpg] createIfdTableArray: result=5

{0TH IFD}
 - DateTime: [2017:07:01 10:06:40]
 - GPSInfoIFDPointer: 22232 
 - Model: [ASUS_Z016D]

	…… 中略 ……

{GPS IFD}
 - GPSLongitude: 123/1 7/1 505923/10000 
 - GPSLatitudeRef: [N]
 - GPSProcessingMethod: [ASCII]
 - GPSAltitudeRef: 200/100 
 - GPSLatitude: 49/1 17/1 172751/10000 
 - GPSLongitudeRef: [se]

	…… 後略 ……

Longitude は経度、 Latitude は緯度。 GPSLongitude や GPSLatitudeRef のことをタグと呼び、 タグの値を保持するのが Exif データの役割。

Exif では緯度・経度の値を、 3つの分数で表現する。 例えば 「GPSLongitude: 123/1 7/1 505923/10000」 というのは、 タグ GPSLongitude の値が 「123/1 度 7/1 分 505923/10000 秒」、 すなわち撮影場所が 「経度 123 度 7 分 50.5923 秒」 であることを意味する。

そして GPSLatitudeRef: [N] は、 タグ GPSLatitudeRef の値が 「N」 つまり北緯 (North) であることを表わす。 では、 GPSLongitudeRef: [se] はどういう意味なんだろうか? 普通に考えればここは [se] ではなく 西経 (West) の [W] ではなかろうか?

[se] に何か特別な意味でもあるのかと思ってググってみたが、 何も見つからず。 単なるバグ? どうやったらこんなバグを作り込めるのだろう?

ちなみに GPSLongitudeRef: [se] は Exif データ内では次のような 12バイトのデータ (「タグフィールド」 と呼ぶ) になる:

00 03    00 02    00 00 00 03    73 65 00 00

最初の 2バイト 「00 03」 が、タグ GPSLongitudeRef を表わし (タグそれぞれに ID が割当てられている。GPSLongitudeRef は 3, GPSLongitude は 4 といった具合)、

次の 2バイト 「00 02」 が、タグの値のタイプが ASCII 文字列であることを表わす。

次の 4バイト 「00 00 00 03」 が、タグの値の長さ、 ここでは ASCII 文字列の長さが 3文字 (終端文字 00 を含む) であることを表わし、

最後の 4バイト 「73 65 00 00」 が、 タグの値である ASCII 文字列 「se」と終端文字 00。 最後の 00 は単なる穴埋め。

タグの値が 4バイトに収まらないときは、 実際のデータ格納場所を指し示すポインタ (ファイル内のオフセット) が、 この最後の 4バイトに格納される。

御成町の交差点で撮影した写真の位置情報も同様に調べてみた。

{GPS IFD}
 - GPSLongitude: 139/1 32/1 576664/10000 
 - GPSLatitudeRef: [N]
 - GPSProcessingMethod: [ASCII]
 - GPSAltitudeRef: 200/100 
 - GPSLatitude: 35/1 19/1 27825/10000 
 - GPSLongitudeRef: [se]

やっぱりタグ GPSLongitudeRef の値が [se] になっている。 どうりで 「西経」 でも 「東経」 と同じになってしまうわけだ。

ちなみにタグ GPSAltitudeRef は海抜 (altitude) が海水面より上 (0) か下 (1) かを表わす。 0 か 1 以外の値はダメ。 この Exif データでは RATIONAL タイプ (32ビット符号無し整数 2個で分数を表わす) になっている (正しくは BYTE タイプ)。 タグ GPSAltitude と混同しているのか? 高度 2m というのも意味不明だけど。 まあ、 タグ GPSAltitudeRef を参照するアプリが手元にないので、 とりあえず放置。

というわけで原因が分かった。 位置情報の [se] を [W] (西経の場合。東経ならば [E]) へ書き換えればうまくいきそう。 つまり、前述の 12バイトのタグフィールドの場合なら、 次のように書き換えればよい。

00 03    00 02    00 00 00 03    73 65 00 00
00 03    00 02    00 00 00 02    57 00 00 00

つまり、 データの長さ (終端文字を含む ASCII 文字列の長さ) を 3 から 2 へ書き換え、 ASCII 文字列を 「se」 から 「W」 (西経の場合) へ書き換える。 要は、 書き換えるべきタグフィールドが写真ファイル内のどこにあるかさえ分かれば、 それを読み込んで書き換えてファイルへ書き戻すだけ。 というわけで、 サクっと書いてみた。 わずか 150行足らず。

書き換えるべきタグフィールドがどこにあるか調べるのは、 「Exif データにアクセスするコード」 を流用させて頂いたので、 あっと言う間に書けた (このブログを書く方が遥かに時間がかかっている)。

ありがとうございます > DSAS 開発者の部屋のみなさま, とくに tanabe さま

東経か西経かという情報は写真ファイルには無いので、 西経の場合は -W オプションを指定する (デフォルトは東経)。 例えばバンクーバーで撮った写真を一つのディレクトリにまとめておいて、

senri:~/Vancouver $ fix_GPSInfo -W *

といった感じで一括修復できる。 修復の必要がないファイル (他のカメラで撮影した写真ファイルや、 位置情報を含んでいない写真ファイル、 および動画など写真以外のファイル等) は影響を受けない。 手元の写真ファイルはこれで全て修復できるのだけど、 Google フォトにアップロード済みの写真はどうしよう? いちど全部消してアップロードし直せばいいのだろうけど、 あまりに枚数が多すぎるなぁ...

Filed under: Android,プログラミングと開発環境 — hiroaki_sengoku @ 22:09
2011年2月24日

決してBusyにならない SIP 留守番電話機を Perl で作ってみた 〜 用件が録音されるとメールに添付して送信

IP 電話でいろいろ遊ぼうとすると定番は Asterisk だが、 いかんせん牛刀すぎる。 個人的に VoIP を使う場合 PBX の必要はなく、 留守番電話や転送ができれば充分。 というわけでまずは留守番電話の機能をさくっと Perl で書いてみた (わずか 93行)。

sip_user: hiroaki_sengoku
sip_passwd: xxxxxxxx
sip_domain: ekiga.net
answer_rings: 30
answer_sound: /home/tam_ekiga/answer.raw
voicemail_time: 60
voicemail_dir: /home/tam_ekiga/LOCAL/voicemail

設定ファイル answer_machine.conf を ↑ のような感じで書いておいて、 留守番電話スクリプト answer_machine を実行する:

answer_machine --conf /home/tam_ekiga/answer_machine.conf

sip:hiroaki_sengoku@ekiga.net に着信があると、 応答メッセージを流した後、 相手の音声を録音し、 /home/tam_ekiga/LOCAL/voicemail ディレクトリに 8kHz サンプリングの 8bit μ-law 形式で保存する。 あとはこのディレクトリを監視するプログラムを走らせて、 新着録音をメールで送信するようにしておけばよい。

次に IPKall を利用 (申込には米国の IP アドレスからアクセスする必要あり) して電話番号をもらう。 米国ワシントン州リンデンの番号 +1-360-526-6699 が割当てられた。 上記 SIP 留守番電話が待受けている sip:hiroaki_sengoku@ekiga.net を、 この電話番号の転送先として IPKall に登録すれば、 Google Voice もどき (^^;) の出来上がり。 この番号に電話すると、 上記スクリプトが応答し (上記設定ファイルに answer_rings: 30 と書いてある通り、 30秒間呼び出しを続けないと応答しない)、 何かメッセージを吹き込めば mp3 形式の音声データが添付されたメールが私宛に届く。

この仕掛けを作った晩の翌日未明 3:16 に、 さっそく着信があり録音データが添付されたメールが届いた。 発信者の電話番号は +1-877-347-3760 だった (+1-877- は米国のフリーダイヤル)。 メールで送られて来た録音データがコレ。 英語が苦手な私にはちょっとつらい (^^;) が、 再生速度を遅めにして一生懸命聞き取ってみる:

Hello, this is a message for Korety Martin. If you are not Korety Martin, please hang up and call 877-347-3760 to remove this phone number from our records. If you continue to listen to this message, you are acknowledging that you are Korety Martin. This message contains personal and private information. There will now be a three second pause.

This is EOCCA, A Collection Agency. This is an attempt to collect a debt. Any information obtained will be used for that purpose. Please contact us about this important business matter at 877-347-3760. When calling please reference account number 9.

真面目にディクテーションするのが馬鹿馬鹿しくなるような、 絵に描いたような詐欺電話 (*_*)。 「Collection Agency」 は債権回収会社のこと。 「EOCCA, A Collection Agency」 で検索してみると、 いっぱい出てくる。 借金の心当たりがある人 (のうち 1% くらい?) は、 つい騙されて折り返し電話をかけてしまうのか。 日本とかだと人海戦術で電話をかけまくるらしいが、 自動で電話をかけまくるのが米国流なのか? 電話版スパムメールといった感じ?

なお、 最後がしり切れとんぼのような感じがするが、 これは録音時間を 60秒間に制限しているため (上記設定ファイルの voicemail_time: 60)。

- o -

以下は、 Perl プログラミングに興味があるかた向け:

もっと読む...
Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 19:52
2011年2月14日

Google Voice で電話する 「V字発信」 Perl スクリプトを書いてみた 〜 日本へは 2円/分、米国内は年内無料

2009年に米国内でサービス開始した Google Voice は、 2010年6月から以前のような 「招待制」 ではなくなり、 米国内からであれば設定するだけですぐ利用できるようになった。 近いうちに米国外へも展開すると思われるが、 日本は後回しになりそうな気がする (Android 版 Skype が使えるようになったのも世界中で一番最後だったし)。 米国内限定といっても、 米国内に IP アドレスと電話番号があれば利用できるようなので試しに使ってみた。

米国内 IP アドレスは Linode VPS (Virtual Private Server, 仮想専有サーバ) を契約しているので既に持っている。 この VPS 上で PPTP (Point to Point Tunneling Protocol) デーモンを立ち上げておけば、 Windows 標準機能の 「仮想プライベート ネットワーク」 (VPN) で接続して、 米国内からのアクセスを装うことができる。 WWW アクセスだけなら proxy server を立ち上げておくだけで充分かと思ったが、 proxy 経由のアクセスかどうか Google サーバ側で見ているらしく、 proxy 経由では Google Voice は利用できない。

なお、 いったん Google Voice の設定を済ませて Google Number を確保してしまえば、 米国内国外を問わず任意のマシンから Google Voice を利用可能。 つまり Google Number を確保するときのみ、 米国内の IP アドレスからアクセスする必要がある、 ということ。

米国内の電話番号は、 無料で電話番号を割当ててくれるサービスがあるのでそれを利用する。 私は IPKall を利用した。 こちらも米国内の IP アドレスからアクセスする必要があるが、 Google Voice とは異なり米国内の proxy server を経由するだけで登録できる。 SIP フォン (VoIP 電話) のアドレスと、 メールアドレスを登録すると、 ワシントン州の電話番号を一つ割当て、 それをメールで教えてくれる。 割当てられた電話番号に着呼すると、 登録した SIPフォンへ転送してくれる仕掛け。 ただ、 米国は電話代が安すぎるためかイタ電が多いのがちょっと困りもの。 いたずら電話に困っている人がよほど多いのか、 WhoCallsMe.com, Who Called Us, PhoneOwner.info, white pages, Location Lookup など、 かかってきた電話番号を調べるサービスがいくつもある。

維持費用無しで米国の電話番号を持てるのは大変ありがたいが、 30日間サービスを利用していないと登録が無効になってしまう (IPKall の場合)。

IPKall Signup
**ABSOLUTELY FREE**
Washington state phone number to your IP phone.
...(中略)...
Accounts that are inactive for 30 days will be terminated for non-use.
IPKall Signup から引用

「inactive」 というのが、 (1)通話実績がないことを意味するのか、 (2)着呼だけでも 「active」 と見做されるのか、 あるいは (3)登録情報を更新するだけでもよいのかは不明。

仮に (1) だとすると、 毎月日本から国際電話をかけて通話実績を作らなければならず、 とても面倒だしお金もかかる。 そこで Google Voice を使って通話実績を作ることを考えた。 自動で発呼できれば手間もかからず番号を維持できる。 しかも 2011年中 Google Voice は米国内宛の通話が無料らしいので発呼の実験し放題。

JavaPython などから Google Voice をアクセスする 非公式な Google Voice API が発表されているが、 公式ではないので Google が仕様変更すると使えなくなる恐れあり。 「非公式 API」 のコードを見てみると、 内容的にはとても単純であるように見える。 この程度なら自分で一から書いた方が Google の仕様変更への追随も即座にできるし、 Java や Python よりは Perl で書きたかったというのもあって、 さくっと書いてみた。 わずか 58行、 しかも後述するように follow_meta_redirect のバグ対策で 21行ほど要してるので、 実質だとわずか 27行。

もっと読む...
Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 09:27
2010年9月21日

地デジ MPEG-2 TS の PCR/PTS/DTS ラップアラウンド (PCR Wrap-around) 問題を回避して ffmpeg で PS 変換できるようにしてみた

(地上)デジタルTV 放送を Linux サーバで予約録画しまくるようになった今日このごろ、 たまに失敗するのが気になっていた。 失敗といっても、 録画した MPEG-2 TS (Transport Stream) ファイルを VLC で再生する分には問題がないが、 ffmpeg を使って MPEG-2 PS (Program Stream) フォーマットへ変換しようとすると途中で映像が止まってしまう (TS 読み込みに失敗しているので他のフォーマットへの変換もおそらく無理)。

おそらく TS のデータに何らかの誤りがあって ffmpeg が映像データを読むのをそこで止めてしまうためだろうと思っていた。 そりゃ放送なんだからノイズが混じることもあるだろうと思い込んでいたのだが、 よほど電波状況が悪くない限りエラー補正が効くだろうから、 ノイズが原因というのはありそうもない話。

なぜ PS へ変換したいかといえば、 TS のままだとファイルサイズが大きすぎる (2時間の映画番組とかだと 12GB を超える) ので、 PS へ変換し (CM カットなどの編集を行なうときは PS の方が便利)、 さらに MPEG-4 などへ変換してサイズを小さくしたいから (もちろん保存する必要がない番組は見たらすぐ消す)。 ところが PS への変換に失敗した番組は TS のまま保存せざるを得ず、 そういうファイルが増えてきて、 2TB のハードディスクもだんだん手狭になってきた。

そこで、 何が原因で TS の読み込みに失敗しているのか、 まずは調べてみようと思ったのだが、 いかんせんファイルがデカすぎる。 12GB もあるとファイルの内容をダンプするのもままならない。 そこで変換が失敗する近辺のデータだけ抜き出して詳しく調べてみようと考えた。 MPEG-2 TS の仕様を調べてみると、 PCR (Program Clock Reference) なるタイムスタンプが 100msec 以下の間隔で MPEG-2 TS には埋め込まれているらしい。 問題の TS ファイルは、 2時間の番組中、 先頭から 1時間35分41秒ほど経過したあたりで読み込みに失敗するので、 PCR の値を手がかりにその近辺のデータを抜き出そうと考えた次第。

まずは PCR の値を表示する perl スクリプト tsdump.pl を作ってみた (後述する tsrenum.pl に -v オプションを与えることによって同じ出力が得られる)。

% ./tsdump.pl -v < 133000_GR23.ts
0008c4a PCR 24:55:00.570 8073051319+138
001a12d PTS 24:55:01.111 8073100071
001a132 DTS 24:55:01.011 8073091062
001d841 PTS 24:55:00.748 8073067367
0022556 PCR 24:55:00.628 8073056524+157
00226d5 PTS 24:55:01.045 8073094065
0026a65 PTS 24:55:00.769 8073069287
0029dcd PTS 24:55:01.078 8073097068
00300f1 PTS 24:55:00.791 8073071207
0033225 PTS 24:55:01.212 8073109080
003322a DTS 24:55:01.111 8073100071
0038f69 PTS 24:55:00.812 8073073127
003bcea PCR 24:55:00.685 8073061729+175
...

「133000_GR23.ts」 が問題の TS ファイル (23チャンネルなので TV東京 ^^;)。 次の 「0008c4a PCR 24:55:00.570 8073051319+138」 という行は、 ファイル先頭から 0008c4a バイト目に PCR があって、 そのタイムスタンプが 「24:55:00.570」 であることを示す。

行末尾の 「8073051319+138」 は生の PCR の値。 つまり、 PCR は 33bit の 「PCR base」 と 9bit の 「PCR extension」 から構成されるが、 それぞれ 8073051319 と 138 であることを示す。 PCR base は 90kHz の解像度、 PCR extension は 27MHz の解像度。 とりあえずここでは後者は無視して、 前者 8073051319 を 90000 (= 90kHz) で割ると 89700.570 秒で、 時分秒に直すと 24:55:00.570 になる。

PCR の他に、 PTS (Presentation Time Stamp) と DTS (Decode Time Stamp) というタイムスタンプも MPEG-2 TS には埋め込まれている。 これらは PCR と違って 90kHz の解像度の 33bit のデータのみ。 MPEG-2 TS では、 PCR の時刻を基準にして、 復号する時刻 (DTS) と再生する時刻 (PTS) を定めている (音声と映像の同期のためにも使われる)。 前述したプログラムの出力において、 2カラム目に PTS, DTS と出力している行は、 それぞれ PTS, DTS の値であることを示す。

で、 PCR の値を表示させてみていきなり気付いてしまったのだが、 この問題の TS ファイルは PCR の値が 33bit の上限値ギリギリ。 33bit の上限は 0x1FFFFFFFF = 8589934591 だから、 PCR は 26:30:43.717 (26時間30分43秒余) までしかカウントできない。 このファイルは冒頭のタイムスタンプが 24:55:00.570 だから、 冒頭から 01:35:43.147 ほど経過したあたりで PCR の値が桁あふれ (オーバーフロー) を起こして 00:00:00.000 へ戻ってしまう (ラップアラウンド)。

これは冒頭から 1時間35分41秒ほど経過したあたりで ffmpeg が止まってしまう症状にピッタリ符合する (2秒ほど差があるのは MPEG-2 復号に要する時間?) ので、 もう原因は PCR のラップアラウンド (PCR Wrap-around) で間違いないと推測。

「VLC で再生する分には問題がない」 と書いたが、 この問題の TS ファイルを VLC で再生して 1時間35分41秒あたり (VLC の場合 TS 再生時は時刻表示を行なわないのでシーンで探さざるを得ず大変) をよく見てみると、 再生が一瞬 (1秒ほど?) 止まっていた。 26時間半に一度、 必ず起こるラップアラウンドなのに、 VLC でも完全な対策は (まだ) 行なわれていないようだ。

原因調査の準備のために作ったスクリプトが、 いきなり原因究明の役に立つとは (^^;) と思いつつ、 tsdump.pl にタイムスタンプの値を付け替える (すなわち 24:55:00.570 から始まるタイムスタンプを 00:00:00.000 始まりにリナンバーする) 処理を付け加えたスクリプト tsrenum.pl を書いてみた (後述する pcr_write, ts_write 関数を追加しただけ)。

% ./tsrenum.pl < 133000_GR23.ts > 133000_GR23_fixed.ts

tsrenum.pl を使ってタイムスタンプを付け替えた 133000_GR23_fixed.ts は、 ffmpeg を使って PS 変換ができるようになった。 原因調査の準備のために作ったスクリプトが、 ほとんどそのまま問題解決の役にも立ってしまった (^^;)^2。

tsrenum.pl は、 標準入力から読み込んだ MPEG-2 TS において最初に現れた PCR/PTS/DTS タイムスタンプを基準 (下記スクリプト中の $pcrOrg) にして、 タイムスタンプを付け替えて標準出力へ書き出す:

#!/usr/bin/perl
use strict;
use warnings;
use POSIX;
use Getopt::Std;
our ($opt_v);
getopts('v') || &help;
my $PacketSize = 188;
my $offset = 0;
my $pcrOrg;
for (;;) {
    my $buf;
    my $len = read(STDIN, $buf, $PacketSize);
    last unless $len > 0;
    my @buf = unpack("C*", $buf);
    die if $buf[0] != 0x47;	# sync byte
    my $ind = (($buf[1] & 0xE0) >> 5);
    my $adp = (($buf[3] & 0x30) >> 4);
    my $pos = 4;
    if ($adp & 0x2) {	# Adaptation field exist
	$pos++;
	my $af = $buf[$pos++];
	if ($af & 0x10) {
	    my ($pcr33, $pcr9) = &pcr(\@buf, $pos);
	    printf(STDERR "%07x PCR %s %d+%d\n",
		   $offset+$pos, &stime($pcr33), $pcr33, $pcr9) if $opt_v;
	    &pcr_write(\@buf, $pos, $pcr33);
	    $pos += 6;
	}
	if ($af & 0x08) {
	    $pos += 6;
	}
	if ($af & 0x04) {
	    $pos++;
	}
    }
    if ($ind & 0x02) {
	if ($buf[$pos] == 0x00 && $buf[$pos+1] == 0x00
	    && $buf[$pos+2] == 0x01 && ($buf[$pos+6] & 0xC0) == 0x80) {
	    my $flag = $buf[$pos+7];
	    $pos += 9;
	    if ($flag & 0x80) { # PTS
		my $ts = &ts(\@buf, $pos);
		printf(STDERR "%07x PTS %s %d\n",
		       $offset+$pos, &stime($ts), $ts) if $opt_v;
		&ts_write(\@buf, $pos, $ts);
		$pos += 5;
		if ($flag & 0x40) { # DTS
		    my $ts = &ts(\@buf, $pos);
		    printf(STDERR "%07x DTS %s %d\n",
			   $offset+$pos, &stime($ts), $ts) if $opt_v;
		    &ts_write(\@buf, $pos, $ts);
		    $pos += 5;
		}
	    }
	}
    }
    syswrite(STDOUT, pack("C*", @buf), $len);
    $offset += $len;
}

sub stime {
    my ($ts) = @_;
    my $sec = floor($ts / 90000);	# 90kHz
    $ts -= $sec * 90000;
    my $min = floor($sec / 60);
    $sec -= $min * 60;
    my $hour = floor($min / 60);
    $min -= $hour * 60;
    return sprintf("%02d:%02d:%02d.%03d", $hour, $min, $sec, $ts/90);
}

sub help {
    print STDERR <<EOF;
Usage: tsrenum.pl <opt>
opt:   -v            ; verbose
EOF
    exit 1;
}

MPEG-2 TS を標準入力から 1パケットずつ @buf に読み込んで、 PCR を見つけたら
pcr(\@buf, $pos) 関数を呼び出して PCR base の値 $pcr33 を取得し、
pcr_write(\@buf, $pos, $pcr33) 関数で PCR base の値を変更して標準出力へ書き出す。 PTS, DTS についても同様に、 ts(\@buf, $pos) 関数を呼び出して値を取得し、 ts_write(\@buf, $pos, $ts) 関数で変更する。

ISO/IEC 13818-1 の 2.4.3.4節 Adaptation field (20ページ) の Table 2-6 - Transport Stream adaptation field を見ると、 adaptation field の 2バイト目から 33bit が PCR base の値、 続いて 6bit の予約ビット、 その次の 9bit が PCR extension の値であることが分かる。 したがって pcr(\@buf, $pos) 関数は以下のように書ける:

sub pcr {
    my ($br, $pos) = @_;
    my $pcr33 = (($br->[$pos] << 25) | ($br->[$pos+1] << 17)
		 | ($br->[$pos+2] << 9) | ($br->[$pos+3] << 1)
		 | (($br->[$pos+4] & 0x80) != 0));
    my $pcr9 = ((($br->[$pos+4] & 0x01) << 8) | $br->[$pos+5]);
    return ($pcr33, $pcr9);
}

pcr_write(\@buf, $pos, $pcr33) 関数は PCR base の値 $pcr33 から $pcrOrg を減算してから pcr(\@buf, $pos) 関数の逆を行なうだけ:

sub pcr_write {
    my ($br, $pos, $pcr33) = @_;
    $pcrOrg = $pcr33 unless defined $pcrOrg;
    $pcr33 -= $pcrOrg;
    $br->[$pos] =   (($pcr33 >> 25) & 0xFF);
    $br->[$pos+1] = (($pcr33 >> 17) & 0xFF);
    $br->[$pos+2] = (($pcr33 >>  9) & 0xFF);
    $br->[$pos+3] = (($pcr33 >>  1) & 0xFF);
    if ($pcr33 & 1) {
	$br->[$pos+4] |= 0x80;
    } else {
	$br->[$pos+4] &= 0x7F;
    }
}

ISO/IEC 13818-1 の 2.4.3.7節 Semantic definition of fields in PES packet (31ページ) の Table 2-17 - PES packet を見ると、 PES (Packetized Elementary Stream) の 9バイト目から marker bit を挟みつつ 33bit の PTS と DTS が格納されていることが分かる。

したがって ts(\@buf, $pos) 関数と ts_write(\@buf, $pos, $ts) 関数は以下のように書ける:

sub ts {
    my ($br, $pos) = @_;
    return ((($br->[$pos] & 0x0E) << 29)
	    | ($br->[$pos+1] << 22) | (($br->[$pos+2] & 0xFE) << 14)
	    | ($br->[$pos+3] << 7)  | (($br->[$pos+4] & 0xFE) >> 1));
}

sub ts_write {
    my ($br, $pos, $ts) = @_;
    $pcrOrg = $ts unless defined $pcrOrg;
    $ts -= $pcrOrg;
    $br->[$pos] =   ((($ts >> 29) & 0x0E) | ($br->[$pos] & 0xF1));
    $br->[$pos+1] =  (($ts >> 22) & 0xFF);
    $br->[$pos+2] = ((($ts >> 14) & 0xFE) | ($br->[$pos+2] & 0x01));
    $br->[$pos+3] =  (($ts >>  7) & 0xFF);
    $br->[$pos+4] = ((($ts <<  1) & 0xFE) | ($br->[$pos+4] & 0x01));
}

すべて解決した後で気付いたのだが (^^;)、 ラップアラウンドする TS ファイルを読み込んだときは ffmpeg が的確なエラーメッセージを出力していた:

...
frame= 1328 fps= 21 q=2.0 size=   31898kB time=44.00 bitrate=5938.8kbits/s dup=24 drop=0    
frame= 1341 fps= 21 q=2.0 size=   32002kB time=44.45 bitrate=5898.1kbits/s dup=24 drop=0    
[mpegts @ 0x6253c0]Invalid timestamps stream=0, pts=4078, dts=8589929661, size=53459
*** drop!
*** 1 dup!
*** drop!
*** drop!
*** drop!
*** drop!
*** drop!
adding -2147483648 audio samples of silence
adding -2147483648 audio samples of silence
*** drop!
...

「Invalid timestamps ... pts=4078, dts=8589929661」 すなわち PTS が 00:00:00.045 なのに、 DTS が 26:30:43.663 なので無効なタイムスタンプである、 というエラー出力。 タイムスタンプがラップアラウンドしたときは、 「Invalid timestamps」 とは言えないと思うのだが...

念のため ffmpeg の最新版を 「git clone git://git.ffmpeg.org/ffmpeg/」 で取得してコンパイルしてみたのだが、 「FFmpeg version git-735bbae」 でも同様に 「Invalid timestamps」 エラーが出力された。

Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 08:13
2010年7月26日

Nexus One で Android 2.2 froyo のマルチタッチを試してみる

Android は 2.1-update1 以降でマルチタッチ (Multi-touch) をサポートしている。 ところがマルチタッチといっても、 ピンチイン/ピンチアウトなどのジェスチャをサポートしているだけのアプリが大半で、 複数のタッチを独立に扱えるアプリはいまだほとんどなく、 iPhone と比べるとその差が際立っている。

どうして Android にはマルチタッチを活用したアプリケーションが無いのだろう? と思ったので、 マルチタッチを試すテストアプリ MultiTouch.java (apk) を書いてみた:

MultiTouch

タッチした位置にタッチの強さに応じた大きさの円を表示するだけの単純なアプリ。 指を移動すれば円も追随する。 Android ではタッチID が順に割り振られるので、 ID が 0 のタッチを赤色の円で、 ID が 1 のタッチを緑色の円で描いている。

プログラム上は ID が 2 のタッチを青色の円で描くことになっているが、 残念ながら現行の Android で同時に扱えるタッチは 2箇所のみ (追記: Samsung Galaxy S は 5箇所のマルチタッチが可能らしい) なので、 3箇所にタッチしても三つ目の円が描かれることはない。 だから例えば iPhone のアプリにあるような鍵盤楽器アプリを作ろうと思っても、 三つ以上の音を同時に鳴らすことはできない。

とはいえ、 2箇所のタッチを独立に扱えれば、 いろいろ応用が効くだろうにと思いつつ、 このテストアプリをいじっていると...

もっと読む...
Filed under: Android,プログラミングと開発環境 — hiroaki_sengoku @ 08:57
2010年7月17日

Nexus One の近接センサ/環境光センサは、どこにあるのか?調べてみた

Nexus One など最近のスマートフォンには、 加速度 (Accelerometer)、 環境光 (照度, Ambient Light)、 磁場 (磁界, Magnetic Field)、 方位 (電子コンパス, Orientation)、 近接 (Proximity) など、 様々なセンサがついている。 いろいろ応用できそうで夢がふくらむが、 携帯電話本来の使い方 (つまり通話すること) において、 使い勝手に直接影響する重要なセンサが近接センサ。

Nexus One や iPhone など全面タッチパネルの携帯電話だと、 (受話器として使うために) 耳に近づけたときタッチパネルが反応しては困る。 そこで近接センサを使って顔が接近してくることを感知し、 タッチパネルを無効にする (ついでにディスプレイをオフにして消費電力を抑える)。

私は Proximity なんて聞くと、 Proximity Warning System (接近警報システム) を思い浮かべてしまうくらいで、 携帯電話用の近接センサがどういうしくみか全く知らなかった。 今年1月の Nexus One の発表の時に近接センサのことを初めて知り、 その時はタッチパネル全体への接近を感知する (静電容量の変化を検知して?) のかと想像したが、 後述するように Nexus One の近接センサはタッチパネルの左上にしかなく、 タッチパネルの下方への接近は感知できないことが分かった。

Nexus One のどこに近接センサが搭載されているか、 センサの感応範囲がどれくらいなのか、 私には見当もつかなかったし、 google で検索してもその手の情報は見つからなかったので、 近接センサが感知した値を表示するだけの簡単なプログラムを書いてみた。

実は、 私にとって初めての android アプリ (^^;)。 しかも、 ここ数年 Java から遠ざかっていたので、 久々に書く Java プログラムだったりする。

お膳立ては Android SDK が全てやってくれるので、 わずか 74行のプログラム。 まず SensorManager#getSensorList メソッドで、 PROXIMITY タイプのセンサを取得し (sensor)、

	sensorManager = (SensorManager)getSystemService(SENSOR_SERVICE);
	List<Sensor> sensors
	    = sensorManager.getSensorList(Sensor.TYPE_PROXIMITY);
	Sensor sensor = sensors.get(0);

この sensor の値が変化したときなどにセンサの値を受け取るリスナ (SensorEventListener) を、 SensorManager#registerListener メソッドで登録するだけ。

public class Proximity implements SensorEventListener {
	...
	sensorManager.registerListener(this, sensor,
				       SensorManager.SENSOR_DELAY_NORMAL);
	...
    @Override
    public void onSensorChanged(SensorEvent event) {
	view.update(event.values);
    }

    @Override
    public void onAccuracyChanged(Sensor sensor, int accuracy) {
    }
}

近接センサの値が変化するとリスナの onSensorChanged メソッドが呼び出されるので、 新しいセンサ値を描画する (view.update):

	void update(float[] values) {
	    Canvas canvas = getHolder().lockCanvas();
	    if (canvas == null) return;
	    canvas.drawColor(Color.WHITE);
	    Paint paint = new Paint();
	    paint.setColor(Color.BLACK);
	    paint.setTextSize(40);
	    float height = paint.getTextSize();
	    for (int i = 0; i < values.length; i++) {
		canvas.drawText(" "+values[i], 0, height * (i + 1), paint);
	    }
	    getHolder().unlockCanvasAndPost(canvas);
	}

Nexus One のタッチパネル左上隅近く (黒枠部分) にセンサがあるらしく、 パネルまで 2cm ほどの距離に物体を近づけると反応する (センサの値が 9.0 から 0.0 へ変化する)。 また、 パネルと並行に物体を動かす場合、 センサの真上から 1cm ほど外れると反応しなくなる。

Proximity Sensor  ←  鈴を近づけたことにより、
近接センサが反応して、
値が 0.0 になっている

赤外線型の近接センサ (赤外線を照射し、近接する物体からの反射光を測定するセンサ) なので、 凸面の物体など赤外線があさっての方向へ反射してしまって受光素子に正しく届かない場合や、 あるいは黒色の物体などあまり反射しない場合などでは、 より近づけないと反応しない。

例えば、 黒く細い丸棒などだと 1cm 以下に近づけないと反応しない。 逆に白い紙 (凹面〜平面) など、 効果的に赤外線を反射し、かつ受光素子に反射光が効率的に届くケースだと、 2cm より遠くても (8cm くらいでも) 反応する。

ちなみに、 Nexus One に搭載されている近接センサは、 Capella MicrosystemsCM3602 という、 環境光センサ付短距離近接センサ (Short Distance Proximity Sensor with Ambient Light Sensor) であるようだ。 名前の通り環境光も測定できる。 おそらく近接センサの受光素子をそのまま使って照度を測定しているのだろう。

前述したプログラムにおいて、 「Sensor.TYPE_PROXIMITY」 を 「Sensor.TYPE_LIGHT」 に置き換えれば、 環境光センサの値を読み取ることができる。

もっと読む...
Filed under: Android,プログラミングと開発環境 — hiroaki_sengoku @ 08:55
2010年7月8日

Google カレンダーの過去の予定を自動的に削除する方法

ここ 2ヶ月ほど、 Willcom の HYBRID W-ZERO3 から Nexus One への移行を徐々に進めてきた。 Windows Mobile (HYBRID W-ZERO3) は PC とのデータ同期が基本なので、 PC にスケジュールや電話帳など丸ごと入れておけば済むが、 Android (Nexus One) の場合は 「クラウド」 との同期が基本なので一筋縄にはいかない。 つまり 「クラウド」 に全てのスケジュールを置いていいのか? という問題。 私の場合、 「スケジュール」 といいつつ会議の議事メモから個人的な日記まで、 プライベートな情報を全て集積しているので問題がより深刻になる。

ちなみに私は、 1999年に WorkPad 30J を使い始めて以来、 プライベートなデータを PDA / スマートフォンに集積してきた。 今まで使ってきた PDA / スマートフォンをまとめてみる:

購入月機種OS
1999-04 WorkPad 30J PalmOS 3.1J
2000-03 TRGpro PalmOS 3.5
2000-08 Palm m100 PalmOS 3.5.1
2002-09 Zaurus MI-E1 ZaurusOS
2002-12 Linux Zaurus SL-C700 Linux 2.4 Embedix
2003-06 Linux Zaurus SL-C750 Linux 2.4 Embedix
2006-07 W-ZERO3[es] Windows Mobile 5.0
2007-07 Advanced W-ZERO3[es] Windows Mobile 6 Classic
2008-12 HTC P3600 Windows Mobile 5.0
2010-01 HYBRID W-ZERO3 Windows Mobile 6.5 Professional
2010-04 Nexus One Android 2.2 froyo
2010-06 iPhone 4 iOS 4
2010-11 IS01 Android 1.6 donut
2010-12 Galaxy S Android 2.2 froyo
2010-12 IDEOS U8150-B Android 2.2 froyo
2011-03 Nexus S Android 2.3 gingerbread
2011-05 nook color Android 3.0 honeycomb
2011-12 Galaxy Nexus Android 4.0 ice cream sandwich
2012-12 Galaxy S3 Android 4.0 ice cream sandwich
2013-07 Galaxy Mega 5.8 Android 4.2 jelly bean
2013-11 Nexus 5 Android 4.4 kitkat
2014-03 iPhone 5s iOS 7.0
2016-01 Nexus 5X Android 6.0 marshmallow
2016-12 ZenFone 3 ZS570KL Android 6.0.1 marshmallow

WorkPad 30J から HYBRID W-ZERO3 に至るまで、 全て PC とのデータ同期が基本だったし、 それぞれデータ移行ツールが用意されていたので移行は容易だった。 ところが Nexus One で同じような同期を行なうには、 データを PC ではなく Google Calendar へ置かなければならない。

もちろん、 Google Calendar は共有設定さえ行なわなければ他人に読まれることはないだろうし、 「don't be evil」 と言ってるくらいだから、 Google が勝手にユーザのデータを活用する可能性も無い (と信じたい)。

だからといって、 個人的なデータや会社の超機密事項 (議事メモにはそういった情報も含まれる) も洗いざらい Google に預けてしまう、 なんてことは小心な私にはとてもできない。 よく知られているように Google Calendar は 「限定公開 URL」 が漏れるだけで一巻の終わりであるわけで、 漏れることを前提でリスク評価すべき。

というわけで、 議事メモや日記を Google Calendar に置くことはハナからあきらめて、 Google Calendar には直近の予定だけを置くことにした。 万一漏れても、向こう一週間くらいの予定だけであれば、 致命的というほどでもない。

ところが驚いたことに Google Calendar には過去の予定を一括削除する機能がない。 手作業でいちいち消していかない限り、 データは残り続けるようだ。 当たり障りのない 「予定」 でも積み重なればいろいろ見えてくることがあるわけで、 長年にわたって溜った予定データは脅威となりうる。

どうしてこんな超基本機能が無いのだろうと思いつつ google で検索してみると、 見つかるのは 「どうやったら過去のデータを (一括) 消去できるのか?」 という質問のページばかり。 過去データを削除したい、 というニーズは確実にありそうなのに、 なぜ Google は実装しようとしないのか? そういえば gmail も過去のメールを溜め続けるのが基本だし、 Google Calendar に自動的に削除する機能がないのは意図的なのかもしれない。

無い機能は作ってしまえと、 Google Calendar API のドキュメントを眺めてみる。 API を叩くためのクライアントライブラリが用意されているようだ。 が、.NET とか Java とか Python とか PHP とか、 あまり気の進まない (^^;) 言語ばかりが並んでいる。 Perl は無いのかっと思って CPAN を検索したら、 Net::Google::Calendar があっさり見つかった。

マニュアル片手にテストプログラムを書いてみる:

use Net::Google::Calendar;
use DateTime;
my $cal = Net::Google::Calendar->new;
$cal->login('sengoku@gmail.com', 'xxxxxxxx');
for my $event ($cal->get_events('start-max' => DateTime->now
				- DateTime::Duration->new(days => 7))) {
    $cal->delete_entry($event);
}

たったこれだけ。 最初に login($user, $pass) して、 get_events(%opts) で「予定」データを取り出して、 delete_entry($event) で削除。 get_events の引数で、 開始時刻が一週間以上過去の予定のみ取り出すよう指定している。

ちょっと書き足して、 ユーザID やパスワードを設定ファイルで設定できるようにしたスクリプト gcal_remove を作ってみた。

% gcal_remove -c /path/to/config.yaml -d 7

などと実行すると、 7日間以上前の予定を削除する。

設定ファイル config.yaml は以下のような感じ:

google_user: sengoku@gmail.com
google_passwd: xxxxxxxx
Filed under: Android,プログラミングと開発環境 — hiroaki_sengoku @ 09:44
2010年5月26日

サイボウズ オフィス8 のカレンダーを iCalendar 形式に変換するスクリプトを書いてみた

私の職場ではグループウェアとしてサイボウズを利用している。 自分のスケジュールを iCalendar 形式で取得してみたくなった (Nexus One を買うとそういう気分になる ^^;) ので、 google で検索してみたところ次の二つのスクリプトが見つかった:

あいにく職場のサイボウズはオフィス8 なので、 オフィス8 に未対応の前者は使えない。 後者はオフィス8 用だが、 「暫定版」 と書いてある通りいろいろバグがある。 さくっと修正してみて一応それっぽく動かすことはできたのだが、 使い続けていくとなると一から書き直したほうがいいような気がしてきた (わたし的にはこの手のものを PHP スクリプトでは書きたくない) ので、 perl で書き直してみた

この perl スクリプト cybozu8_ical を、

% cybozu8_ical --conf /path/to/config.yaml

などと実行すると、 オフィス8 の 「月予定」 (月間スケジュール) ページをアクセスして、 iCalendar 形式に変換する。 向こう一週間以内の予定については 「予定の詳細」 ページもアクセスして、 「メモ」 および 「設備」 も取得する。 「月予定」 の全ての予定について 「予定の詳細」をアクセスすると、 オフィス8 サーバに負荷をかけすぎる懸念があったので、 このような仕様にしてみた。

設定ファイル config.yaml は以下のような感じ:

cybozu_url: http://intra.klab.org/cgi-bin/klcb/ag.cgi
calname: cybozu
userid: 73
password: xxxxxxxx
time_zone: Asia/Tokyo
input_encoding: shiftjis
output_file: /home/sengoku/tmp/cybozu.ics

「cybozu_url」 はオフィス8 の URL を指定する (もちろん intra.klab.org は KLab 社内LAN からしかアクセスできない)。 「userid」 と 「password」 はスケジュールを取得したいユーザの ID とパスワード。 「output_file」 に指定したファイルへ iCalendar 形式のスケジュールを出力する。 「output_file」 を省略すると標準出力へ書き出す。

なお 「--conf /path/to/config.yaml」 オプションを省略すると、 cybozu8_ical と同じディレクトリにある config.yaml が読み込まれる。

cybozu8_ical で生成した iCalendar 形式のファイルは、 とりあえず Google カレンダー および Thunderbird + Lightning で読み込めることは確認したが、 なにぶんまだ RFC 2445 を真面目に読んでいないので、 不具合などあったらご指摘頂けると有難い。

私はオフィス8 の API を知らないので、 「月予定」 「予定の詳細」 のページを取得してきて scrape しているだけ。 「繰り返し予定」 は個々の予定として扱っている。 iCalendar の UID (各予定固有のID) が同じままだと 2個目以降の予定が無視されてしまうので、 UID の末尾に通し番号をつけて互いに区別できるようにしている。

サイボウズのスケジュールは 「場所」 を登録できない。 その代わり 「施設」 として会議室を登録する。 ところが私の職場の場合 「施設」 には会議室だけでなく 「ビデオ会議システム」 などもあったりするので、 「施設」 に登録されているデータをそのまま iCalendar の LOCATION として使うわけにもいかない。 そこで 「施設」 に会議室の名称が登録されている場合のみ、 その会議室名を LOCATION として出力するようにしている。

iCalendar の LOCATION として出力すべき会議室名の一覧を、 cybozu8_ical スクリプトの始めの方で、

my @facility = (
	'20F 大会議室1', '20F 大会議室2', '20F 大会議室3',
	'20F 中会議室1', '20F 中会議室2',
	'20F 小会議室1', '20F 小会議室2',
	'20F 和室', '22F 社長室前MTGスペ-ス'
);

などと定義している。 ここに列挙されていない会議室等は 「施設」 に登録されていても単に無視される。

Filed under: Android,プログラミングと開発環境 — hiroaki_sengoku @ 16:01
2010年3月8日

tinydns のゾーンを MyDNS へ反映させるスクリプトを書いてみた

MyDNS というのは MySQL (あるいは PostgreSQL) のレコードを、 そのままゾーンレコードとして扱えるネームサーバ。 私は MyDNS を使って実験的にダイナミックDNSサービスを (もちろん無償で) 提供している。 実験と言いつつ、 サービス開始以来 2年以上安定的に継続できているし、 先月から海外レンタルサーバを使って地域分散したので、 仮に私の自宅の回線が切れてもネームサーバが見えなくなることはない。

gcd.jp のマスタネームサーバである ns.gcd.jp と、 スレーヴネームサーバである ns2.gcd.jp (海外サーバ fremont.gcd.org の別名。 名前の通りカルフォルニア州フリーモントにある) とは、 MySQL のレプリケーションによってゾーンデータを同期させている。 したがってマスタ側での変更が即座にスレーヴ側に伝わる。

ちなみに、 ネームサーバ間の同期でよく利用されるゾーン転送 (AXFR) は、 ゾーンデータを丸ごと転送するので (ゾーンが大きくなってくると) 同期頻度を高くすることが難しく、 ダイナミックDNSサービスにはあまり向いていない。 MySQL のレプリケーションでネームサーバ間の同期が行なえてしまう MyDNS は、 ダイナミックDNSサービス向きと言える。

ところが gcd.org では (ダイナミックではない) 普通のネームサーバ ns1.gcd.org も運用していて、 これは tinydns を利用している。 せっかく海外にサーバ fremont.gcd.org を借りたのだから、 tinydns で管理しているゾーンも fremont.gcd.org で引けるようにしたいが、 fremont に複数 IP アドレスを付与するのはお金がかかる (月額 $1 追加) ので、 fremont で MyDNS と tinydns の両方を走らせるわけにもいかない。

私が借りてるレンタルサーバ (正確に言うと VPS) Linode は、 もともと DNS サービス (マスタ/スレーヴどちらでも、ドメインいくつでも) を無料で利用できるので、 DNS のためだけに 1IP 追加する気にはちょっとなれない。

もちろん、 tinydns を止めてしまって全てのゾーンを MyDNS へ移行してしまうという解決策も無くはないのだが、 MyDNS に全面的に依存してしまうのは恐い気もする。 できれば tinydns 側はいじらずに、 tinydns のゾーンデータを MyDNS 側へ反映させる仕掛けを作りたい。

というわけで、 tinydns のゾーンデータを読み込み、 MyDNS のゾーンデータの形式で MySQL へレコードを書込む perl スクリプト tinydns2mydns を書いてみた (CVSリポジトリ)。

なお MyDNS には、 mydnsimport という外部からゾーンデータを取り込むツールが付属していて、 tinydns のゾーンデータもインポートできるのだが、 以下の欠陥があってゾーン転送目的には使えない:

  1. ゾーンの全レコードをいったん削除した上でインポートを行なう実装になっている。
  2. SRV レコードをインポートできない。
もっと読む...
Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 09:25
2010年3月1日

x86_64 Linux などの 64bit 環境で MD5 を使うときの注意点

MD5 (Message Digest Algorithm 5) は、 RFC 1321 でアルゴリズムが紹介されていて、 Appendix (付録) として C によるリファレンス実装が付属しているが、 その global.h に

/* UINT4 defines a four byte word */
typedef unsigned long int UINT4;

と書いてある。 すなわち 32bit 整数として UINT4 型を定義している。 x86_64 Linux を始め多くの 64bit Unix は LP64 すなわち long int (とポインタ) が 64bit な整数データモデルを採用している。 したがって UINT4 型の定義が 「unsigned long int」 のままで、 この MD5 リファレンス実装を使ってしまうと、 32bit であるべき UINT4 型が 64bit になってしまい、 間違ったハッシュ値を算出してしまう。

16bit CPU が主流だった大昔なら 「int が 16bit なデータモデルを採用している環境」 が多かったのかもしれないが、 RFC 1321 が出た 1992年ごろは既に 32bit CPU が主流だったわけで、 UINT4 型を 「int」 と定義しておいてくれてもよかったのにと思う。 そうすれば、 「long が 64bit なデータモデルを採用している環境」 が多くなる昨今でも (int は 32bit のままなので) 問題を起こさずに済んだだろうに。

試しにテストプログラムを書いてみる:

#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include "global.h"
#include "md5.h"
#define DIGEST_LEN 16
#define BUFFER_LEN 256

int main(int argc, char *argv[]) {
    MD5_CTX context;
    unsigned char digest[DIGEST_LEN];
    unsigned char buf[BUFFER_LEN];
    int i;
    MD5Init(&context);
    while ((i=read(0, buf, BUFFER_LEN)) > 0) MD5Update(&context, buf, i);
    MD5Final(digest, &context);
    for (i=0; i < DIGEST_LEN; i++) printf("%02x", digest[i]);
    printf("\n");
    return 0;
}

32bit 環境 (i686 Linux) では正しく動く:

senri:/home/sengoku/src/md5 % uname -m
i686
senri:/home/sengoku/src/md5 % ls
global.h  main.c  md5.h  md5c.c
senri:/home/sengoku/src/md5 % cc -Wall main.c md5c.c
senri:/home/sengoku/src/md5 % file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), not stripped
senri:/home/sengoku/src/md5 % echo "Hello, world" | ./a.out
a7966bf58e23583c9a5a4059383ff850
senri:/home/sengoku/src/md5 % echo "Hello, world" | openssl md5
a7966bf58e23583c9a5a4059383ff850

ところが、 64bit 環境 (x86_64 Linux) だと:

senri:/home/sengoku/src/md5 % uname -m
x86_64
senri:/home/sengoku/src/md5 % cc -Wall main.c md5c.c
senri:/home/sengoku/src/md5 % file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), not stripped
senri:/home/sengoku/src/md5 % echo "Hello, world" | ./a.out
fd578222c6a471623ea1e3eb2b6e6f6b

などと、 誤った MD5 の値が出力されてしまう。

MD5 の値を求めること自体が目的であれば、 誤ったハッシュ値が出力されればすぐ気付くのでいいのだが、 値そのものが目的であることは (当然ながら) あまりなくて、 普通はアプリケーションの中で MD5 を利用するので、 32bit 環境で使っていたアプリケーションを 64bit 環境でコンパイルし直して使おうとするとハマる。

もっと読む...
Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 09:34
2010年2月10日

CTO日記も livedoorブログから WordPress へ引越しました (URL は変更なし)

「仙石浩明の日記」 に続いて、 「仙石浩明CTO の日記」 も先週末に livedoorブログから自宅サーバへ引っ越した (つまりネームサーバの設定を変更して切替。有料プランの解約はこれから)。 もともと両ブログは相互にリンクを張って密接に連係していたので、 引越を機会に両者を統合した。

統合といっても両ブログは微妙(?)に読者層が異なると思われるし、 何よりページの体裁が大きく変わってしまっては読者の方々を戸惑わせてしまうので、 CTO日記を 「仙石浩明の日記」 の一カテゴリという位置付けにして、 かつページの体裁は WordPress のテーマを切り替えることによって、 どちらのブログもあまり大きな変化がないようにしている。

「仙石浩明CTO の日記」 http://sengoku.blog.klab.org/ をアクセスすると、 次のような PHP スクリプトを走らせた上で、 WordPress を呼び出す (末尾の require 文):

<?php
$new = NULL;
if ($_SERVER['REQUEST_URI'] == "/") {
    $new = "/blog/category/cto/";
} elseif ($_SERVER['REQUEST_URI'] == "/feed/") {
    $new = "/blog/category/cto/feed/";
} elseif (preg_match('@^/\d+/\d+/\d+/@',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $new = $_SERVER['REQUEST_URI'];
...(中略)...
}
if ($new) {
    ...(中略)...
    $ORIG_SERVER_NAME = $_SERVER['SERVER_NAME'];
    $host = "www.gcd.org";
    $_SERVER['SERVER_NAME'] = $host;
    $_SERVER['REQUEST_URI'] = $new;
    $_SERVER['SCRIPT_NAME'] = $new;
    $_SERVER['PHP_SELF'] = $new;
    $abspath = "/usr/local/www/wordpress/";
    $themepath = "${abspath}wp-content/themes/sengoku_cto/";
    define('WP_USE_THEMES', true);
    define('TEMPLATEPATH', $themepath);
    define('STYLESHEETPATH', $themepath);
    require("${abspath}wp-blog-header.php");
...(中略)...
}
?>

つまり http://sengoku.blog.klab.org/ へのアクセスは、 パス名に 「/category/cto/」 を追加することによって、 CTO日記カテゴリへのアクセスに変換する。

ページの体裁については、 「wp-content/themes/sengoku_cto/」 ディレクトリが、 CTO日記のテーマフォルダで、 二つの PHP 定数 TEMPLATEPATH と STYLESHEETPATH をこのディレクトリへ設定することによって、 テーマの切り替えを行なっている。

テーマフォルダの中にあるテーマ関数ファイル 「functions.php」 は、 WordPress の初期化中に読み込まれるので、 ここに PHP スクリプトを書いておくことによって WordPress の挙動を変更することができる。 例えばブログのタイトルを 「仙石浩明CTO の日記」 に変更するには、 以下のスクリプトを functions.php に追加しておけばよい:

function option_blogname_cto() {
    return '仙石浩明CTO の日記';
}
add_filter('pre_option_blogname', 'option_blogname_cto');

つまり、 pre_option_blogname フックに、 option_blogname_cto フィルタを登録する。

WordPress では、 ブログのタイトルなど各種オプションの設定値 (DB に格納している) を、 get_option($setting) 関数を呼び出すことで参照している。 例えばタイトルは get_option('blogname') を呼び出すことで得られ、 URL は get_option('home') で得られる。

get_option($setting) 関数は wp-includes/functions.php で定義されていて、 以下のようにフィルタフック pre_option_* が定義されている:

function get_option( $setting, $default = false ) {
    global $wpdb;

    // Allow plugins to short-circuit options.
    $pre = apply_filters('pre_option_' . $setting, false);
    if ( false !== $pre )
	return $pre;
    ...(中略)...
}

つまり、 「pre_option_設定名」 というフックに登録されたフィルタが値を返すなら、 get_option はオプションの設定値ではなくフィルタが返した値を返すようになる。 前述の例なら、 「pre_option_blogname」 フックに登録された 「option_blogname_cto」 フィルタが 「仙石浩明CTO の日記」 という値を返すので、 get_option('blogname') も 「仙石浩明CTO の日記」 という値を返すようになり、 結果としてブログのタイトルを変更できる、というわけ。

ただし、 前述したように CTO日記は 「仙石浩明の日記」 の一カテゴリという位置付けなので、 ブログのタイトルを変更しただけだと、 ブログ 「仙石浩明CTO の日記」 の 「仙石浩明CTO の日記」 カテゴリということで、 ページのタイトル等が 「仙石浩明CTO の日記 » 仙石浩明CTO の日記」 という冗長なものになってしまう。 そこで、 以下のようなスクリプトを 「functions.php」 に追加して、 タイトルとカテゴリ名が同じときはカテゴリ名が表示されないようにする:

function single_cat_title_cto($category_name) {
    $name = get_option('blogname');
    if ($category_name == $name) return "";
    return $category_name;
}
add_filter('single_cat_title', 'single_cat_title_cto');

single_cat_title フックは、 wp-includes/general-template.php で定義されていて、 ページのタイトルなどに表示されるカテゴリ名を変更することができる。

以上で、 「仙石浩明の日記」 の一カテゴリを 「仙石浩明CTO の日記」 の体裁で見せることができるようになる。 しかし、 元が 「仙石浩明の日記」 であるだけに、 リンク先が全て 「仙石浩明の日記」 のページになってしまう。 例えば、 「仙石浩明CTO の日記」 のトップページの一番下に、 「古い投稿 »」 というリンクがあるが、 このリンク先が http://www.gcd.org/blog/page/2/ になってしまい、 たどると 「仙石浩明の日記」 のトップページの 2ページ目へ遷移してしまう。

また、 本文中 (あるいはサイドバー) に現れるリンクも、 DB のデータは 「仙石浩明の日記」 のパーマリンクを用いているので、 たとえそれが 「仙石浩明CTO の日記」 カテゴリに含まれていても、 そのリンクをたどると 「仙石浩明の日記」 の記事として表示されてしまう。

そこで、 遷移先も 「仙石浩明CTO の日記」 として表示したいリンクを、 フィルタで書き換えることにした。 つまり DB のデータは 「仙石浩明の日記」 へのリンクのままで、 ブラウザに送信する前に都度書き換える。

対象となるリンクは、 記事本文中だけでなく、 前述したページナビ 「古い投稿」 「新しい投稿」 や、 サイドバー (「人気記事」 や 「最近の投稿」) にも現れる。 ページ丸ごと (つまり HTTP レスポンス丸ごと) HTML を書き換えられるフックがあるとよかったのだが、 残念ながらそういうフックは定義されていないようだ。 以下のフックそれぞれについてリンクを書き換えればよさげ:

フィルタフック フィルタが変更できる対象, 第2引数, ...
the_content 記事本文 HTML
the_category 記事の末尾に表示されるカテゴリーリストの HTML,
$separator, $parents
get_pagenum_link ページ末尾に表示されるページナビ 「古い投稿」 「新しい投稿」 の URL
post_link 記事の URL (パーマリンク), $post, $leavename
widget_text サイドバーに表示されるテキストウィジェットの HTML, $instance
wp_list_categories サイドバーに表示されるカテゴリーのリストの HTML
category_feed_link カテゴリーの RSSフィードの URL, $feed

書き換え対象のリンクを決めるために、 まず CTO日記カテゴリに属す記事の ID を取得する:

function setup_cto_id() {
    global $wpdb;
    global $is_cto_id;
    $result = $wpdb->get_results("SELECT object_id FROM wp_term_relationships WHERE term_taxonomy_id=17", ARRAY_N);
    foreach ($result as $row) {
	$is_cto_id[$row[0]] = 1;
    }
}

あるカテゴリに属す記事ID のデータを取得する関数など、 WordPress に含まれているんじゃないかと探してみたのだが、 見つからなかったので DB に問合わせて取得するようにしてみた。 毎回 DB アクセスが発生してしまうが、 キャッシュとかはアクセス数が増えてから考える (^^;)。 「term_taxonomy_id=17」 が CTO日記のカテゴリ (決め打ち ^^;)。 CTO日記カテゴリに属す記事は、 配列 $is_cto_id[記事ID] に 1 を代入しておく。

次に URL を書き換えるスクリプト:

function replace_URL_cto($matches) {
    global $is_cto_id;
    global $ORIG_SERVER_NAME;
    if (!is_array($is_cto_id)) {
	setup_cto_id();
    }
    if (is_null($matches[2])) {
	if ($matches[1] == "category/cto/") return "http://$ORIG_SERVER_NAME/";
	return "http://$ORIG_SERVER_NAME/$matches[1]";
    } elseif ($is_cto_id[$matches[2]]) {
	return "http://$ORIG_SERVER_NAME/$matches[1]";
    }
    return $matches[0];
}

function convert_URLs_cto($text) {
    $textarr = preg_split("/(<.*>)/U", $text, -1, PREG_SPLIT_DELIM_CAPTURE);
    $stop = count($textarr);
    for ($i = 0; $i < $stop; $i++) {
	$content = $textarr[$i];
	if (strlen($content) > 0) {
	    $content = preg_replace_callback(
		    '@http://www.gcd.org/blog/(\d+/\d+/(\d+)|category/cto/)@',
		    'replace_URL_cto', $content);
	}
	$output .= $content;
    }
    return $output;
}

顔文字を画像に変換して表示するフィルタ wptexturize (wp-includes/formatting.php で定義されている) を参考にさせてもらった。 preg_replace_callback() を使って書き換え対象リンクを探し、 replace_URL_cto で記事ID がCTO日記カテゴリに属す ($is_cto_id[$matches[2]] が TRUE) 場合のみ書き換える。

最後に、 この書き換えフィルタ replace_URL_cto を前述したフィルタフックに追加:

add_filter('the_content', 'convert_URLs_cto');
add_filter('the_category', 'convert_URLs_cto');
add_filter('get_pagenum_link', 'convert_URLs_cto');
add_filter('post_link', 'convert_URLs_cto');
add_filter('widget_text', 'convert_URLs_cto');
add_filter('wp_list_categories', 'convert_URLs_cto', 12000);
add_filter('category_feed_link', 'convert_URLs_cto');

wp_list_categories にフィルタを追加すると Category Order プラグインと衝突するので、 優先順位を下げて Category Order プラグインの後で実行されるようにしている。

また、 the_category, post_link, widget_text, category_feed_link 各フックは、 2つ以上の引数を持つが、 第1引数 (書き換え対象の HTML あるいは URL) のみ使用するので引数の数 (add_filter の第3引数) を省略している。

Filed under: システム構築・運用,プログラミングと開発環境 — hiroaki_sengoku @ 07:46
2009年12月4日

apache httpd が 「(22)Invalid argument: alloc_listener: failed to get a socket for (null)」 エラーを出して立ち上がらない理由

私は普段持ち歩いているノートPC (レッツノート CF-R7) で coLinux を常用している。 Windows マシンで Linux を使いたい場合、 QEMU や VMware などの PC エミュレータ (完全仮想化) を用いる方法もあるが、 coLinux などの準仮想化の方がパフォーマンス的に有利なので、 日常的に使用する (私の場合、Windows マシンを使っていながらほとんどの作業は Linux の中で完結させている) なら coLinux の方が便利だと思う。

もちろん、 準仮想化であるから標準的なカーネルをそのまま走らせることはできず、 パッチをあてる必要がある。 残念ながら最新カーネル用のパッチはまだ作られていないようで、 現時点では Linux kernel 2.6.26.8 用のパッチが最新。

私は自分で管理している Linux マシン (自宅と職場合わせて 10台以上ある) は、 この coLinux なマシンも含めてハードディスク (正確に言えば Linux のパーティション) の内容を同一にしている。 すなわち、 マスタマシン (senri.gcd.org) の内容を定期/不定期的に rsync を使って各マシンへ同期させている。 マスタマシンのカーネルは Linux 2.6.31.6 なので、 マスタでビルドしたソフトウェアの中には、 Linux 2.6.26.8 ベースである coLinux 環境で動かないものも当然でてくる。

先日 apache httpd 2.2.14 を (マスタマシンで) ビルドしたら、 coLinux 環境で動かなかった:

# uname -a
Linux ikeda.gcd.org 2.6.26.8-co-0.8.0 #1 PREEMPT Sat Nov 14 19:23:55 JST 2009 i686 GNU/Linux
# /usr/apache2/bin/httpd -t
[Sun Nov 29 17:13:41 2009] [crit] (22)Invalid argument: alloc_listener: failed to get a socket for (null)
Syntax error on line 32 of /usr/apache2/conf/httpd.conf:
Listen setup failed

「Syntax error on line 32」 ということだが httpd.conf の 32行目は、

Listen 80

となっているので、 少なくとも 「Syntax error」 ではないことは明らか。 「Listen 80」 の代りに 「Listen localhost:80」 などと書けば、 「failed to get a socket for (null)」 というエラーメッセージが 「failed to get a socket for localhost」 に変わる。

このエラーメッセージを手がかりに apache httpd 2.2.14 のソースを探すと、 エラーを出しているのは server/listen.c の以下の部分:

もっと読む...
Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 07:24
2009年10月8日

__sync_bool_compare_and_swap_4 とは何か? ~ glibc をビルドする場合は、 gcc の –with-arch=i686 configure オプションを使ってはいけない

glibc-2.10.1 をビルドしようとしたら、 「__sync_bool_compare_and_swap_4 が定義されていない」 というエラーが出た:

senri:/usr/local/src/glibc-2.10.1.i386 % ../glibc-2.10.1/configure
	...
senri:/usr/local/src/glibc-2.10.1.i386 % make
	...
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `__libc_fork':
/usr/local/src/glibc-2.10.1/posix/../nptl/sysdeps/unix/sysv/linux/i386/../fork.c:79: undefined reference to `__sync_bool_compare_and_swap_4'
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `__nscd_drop_map_ref':
/usr/local/src/glibc-2.10.1/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4'
	...
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `*__GI___libc_freeres':
/usr/local/src/glibc-2.10.1/malloc/set-freeres.c:39: undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
make[1]: *** [/usr/local/src/glibc-2.10.1.i386/libc.so] Error 1
make[1]: Leaving directory `/usr/local/src/glibc-2.10.1'
make: *** [all] Error 2

__sync_bool_compare_and_swap_4 は gcc の組み込み関数なので、 関数が未定義であることを示す 「undefined reference to ...」 というエラーメッセージは、 誤解を招く不親切なメッセージだと思う。

__sync_bool_compare_and_swap_4(mem, oldval, newval) は、 mem が指し示すメモリの値 (4バイト分) が oldval であれば newval に変更する、 という操作をアトミックに行なう組み込み関数。 アトミック (不可分) 操作とは、 操作の途中が存在してはいけない操作のことで、 この例なら比較 (メモリの値が oldval か?) と代入 (newval に変更) が必ず 「いっぺん」 に行なわれ、 「比較だけ行なったけどまだ代入は行なわれていない」 という状態が存在しないことを意味する。

アトミックに行なうためには、 当然ながら CPU でその操作をサポートしている必要がある (複数個の命令の列で実現しようとすると、 命令列の半ばを実行中の状態が必ず存在してしまう) わけだが、 残念ながら Intel 386 プロセッサでは、 この compare_and_swap (CMPXCHG 命令) をサポートしておらず、 サポートするのは Intel 486 以降の CPU である。 テストプログラムを書いて試してみる:

#include <stdio.h>

int main() {
    int mem[1], oldval, newval;
    oldval=0;
    newval=1;
    mem[0] = 0;
    __sync_bool_compare_and_swap(mem, oldval, newval);
    printf("mem[0]=%d\n", mem[0]);
    return 0;
}

見ての通り、 mem[0] の値を oldval の値 (0) と比較し、 一致していたら newval の値 (1) を代入し、 mem[0] の値を表示するだけのプログラムである。

関数名が 「__sync_bool_compare_and_swap」 であって、 後ろに 「_4」 がついていないことに注意。 gcc が引数の型 (この例では int) を見て、 その型のビット長を後ろにつけてくれる (この例では int 型は 4 バイトなので 「_4」 をつけてくれる)。

gcc では 「-march=タイプ」 オプションを指定することによって CPU タイプを指定できる。 -march オプションを指定しなかったり (この場合は全 CPU でサポートされる組み込み関数のみ利用できる)、 あるいは -march=i386 を指定したりすると、 コンパイル時にエラーになる:

% gcc -Wall test.c
/tmp/cc4eNX6L.o: In function `main':
test.c:(.text+0x3b): undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
% gcc -Wall -march=i386 test.c
/tmp/cc6chtFj.o: In function `main':
test.c:(.text+0x36): undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
% gcc -Wall -march=i486 test.c
% ./a.out
mem[0]=1

いまさら i486 というのもアレなので、 今なら i686 を指定するのがよさげ。 私の手元にはいまだ PentiumIII マシンがあるものの、 PentiumIII より古いマシンはない (昨年 ML115 と SC440 を買ったとき PentiumII マシンを引退させた) ので、 pentium3 を指定すれば SSE (Streaming SIMD Extensions) が利用できるようになるが、 glibc をビルドするときに必要かというと、 たぶん必要ない。

というわけでエラーの原因は分かったが、 では glibc をビルドするときは、 どうすればいいだろうか?

とりあえず google で検索してみたら、 gcc の configure オプションに 「--with-arch=i686」 を指定して gcc をビルドする必要がある、 と書いてあるページが見つかった。

--with-arch オプションは、 -march のデフォルトを設定するための configure オプションである。 つまり 「--with-arch=i686」 を指定して gcc を再インストールすると、 gcc に -march オプションをつけなくてもデフォルトが i686 になる。 なるほど確かにそうすれば、 glibc 側で何も変更せずに __sync_bool_compare_and_swap_4 関数が使えるようになりそうである。

いまどき i686 以前の CPU 用のコードが必要になりそうなケースは滅多にないだろうから、 -march オプションのデフォルトを i686 にするのも悪い選択ではないように思えた。 gcc をビルドし直すのは面倒だなーと思いつつも、 ついでに gcc のバージョンを上げておこうと gcc-4.3.4 をダウンロードしてきて 「--with-arch=i686」 付でビルドしてみた。

ところが!

もっと読む...
Filed under: システム構築・運用,プログラミングと開発環境 — hiroaki_sengoku @ 09:39
2008年12月9日

freeRADIUS 2.1.3 のバグ: ログを stdout/stderr へ出力できない

無線LAN の脆弱性について警告が飛び交う昨今、 WPA2 (Wi-Fi Protected Access) といえど、 パーソナル (PSK, Pre-Shared Key) モードだとパスワード破りの可能性が 無いわけでも無いので、 エンタープライズ (EAP, Extensible Authentication Protocol) モードに乗り換えてみた。

EAP (社員支援プログラムではなくて、 拡張認証プロトコル) の認証方式には EAP-MD5, EAP-FAST, EAP-SKE, EAP-SRP, MS-CHAP, EAP-GTC, EAP-GTC, Cisco LEAP, EAP-TLS, EAP-TTLS, PEAP, EAP-MAKE, EAP-SIM などがあるが、 対応機器/ソフトウェアが多そうな EAP-TLS を使ってみることにした。 EAP-TLS とは、 TLS (Transport Layer Security) すなわち SSL (Secure Sockets Layer) のサーバ認証とクライアント認証を行なって、 RADIUS サーバと無線LAN 端末が相互に認証を行なう仕掛けである。

RADIUS サーバとしては、 free RADIUS 2.1.3 を使用した。 自前の認証局 でサーバ証明書とクライアント証明書を発行し、 それぞれ RADIUS サーバと無線LAN 端末 (Windows マシン) へインストールする (自分で発行する証明書だが、 認証する側が自分の管理下なので、 いわゆる「オレオレ証明書」ではない)。

まず radiusd をデバッグ モードで走らせてみる:

# radiusd -X
FreeRADIUS Version 2.1.3, for host i686-pc-linux-gnu, built on Dec  6 2008 at 17:50:58
Copyright (C) 1999-2008 The FreeRADIUS server project and contributors. 
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE. 
You may redistribute copies of FreeRADIUS under the terms of the 
GNU General Public License v2. 
Starting - reading configuration files ...
including configuration file /usr/local/etc/raddb/radiusd.conf
including configuration file /usr/local/etc/raddb/clients.conf
including configuration file /usr/local/etc/raddb/eap.conf
group = radius
user = radius
including dictionary file /usr/local/etc/raddb/dictionary
	...(中略)...
Listening on authentication address * port 1812
Ready to process requests.

とりあえず動いているようだ。 Windows マシンからアクセスポイントへ接続してみると、 アクセスポイントを介して Windows マシンと RADIUS サーバ間で、 TLS サーバ/クライアント認証が行なわれ、 無事 WPA2 エンタープライズ モードで接続が完了した。

では、radiusd を daemontools 配下で動かそうと、 次のような /service/radius/run スクリプトを書いて動かしてみる:

#!/bin/sh
export PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
exec 2>&1
exec radiusd -fxxx

-x を指定して詳細なデバッグ情報を出力させるようにする。 daemontools 配下で動かす場合、 multilog プログラムがログをどんどんローテートしてくれるので、 通常運用でもデバッグ情報を出力させておける。 ログを標準出力 (stdout) へ出力させるため、 設定ファイル radiusd.conf において、 次のように指定しておく。

log {
	destination = stdout
}

これでログが /service/radius/log/main/current に書き出されるはず、 と思ったら何も出力されない... 何故に...?

radiusd(8) によれば、-X オプションは 「-sfxx -l stdout」 と等価らしい。 -s オプションは、 RADIUS サーバを単一スレッド/プロセスで走らせるための指定。 個人で使う分には単一スレッドでも構わないといえば構わないので、 ログを stdout に出力する目的で -X オプションを使ってしまっても構わないのだが、 せっかくだからともうちょっと追ってみることにした。

まず上記 run スクリプトにおいて 「-l stdout」 を指定してみる。 すると、/service/radius ディレクトリに stdout というファイルができて、 そこにログが出力された。 ダメだこりゃ。 -l オプションはマニュアルには記載されていないので、 -l に続く 「stdout」 をファイル名と見なすのも一つの「仕様」と言えなくもないが...

ソース radiusd.c を見てみると、 確かに -l オプションの処理では続く引数をファイル名としてしか扱っていない。 では設定ファイル radiusd.conf に指定した場合はどうかと、 mainconfig.c を見てみる。 「log { ... }」 の中で 「destination = stdout」 を指定すると、 mainconfig.radlog_dest に RADLOG_STDOUT が代入されるようだ。 ところが、mainconfig.radlog_fd を設定するコードがない。 これでは stdout にログが出力されるはずがない。

「-l stdout」 の件は百万歩譲って「仕様」でも構わないが、 mainconfig.radlog_dest に RADLOG_STDOUT を代入しておきながら mainconfig.radlog_fd に代入し忘れるのは、 仕様うんぬん以前にソースとして首尾一貫していないので、 明らかにバグである。

そこで以下のようなパッチをあてて、 mainconfig.radlog_dest が RADLOG_STDOUT あるいは RADLOG_STDERR のときは、 mainconfig.radlog_dest に STDOUT_FILENO あるいは STDERR_FILENO を それぞれ代入するようにしてみた。

--- src/main/mainconfig.c~	2008-12-06 01:37:56.000000000 +0900
+++ src/main/mainconfig.c	2008-12-06 16:16:27.455277946 +0900
@@ -738,6 +738,10 @@
 				cf_section_free(&cs);
 				return -1;
 			}
+		} else if (mainconfig.radlog_dest == RADLOG_STDOUT) {
+			mainconfig.radlog_fd = STDOUT_FILENO;
+		} else if (mainconfig.radlog_dest == RADLOG_STDERR) {
+			mainconfig.radlog_fd = STDERR_FILENO;
 		}
 	}
 

これで無事、 ログが stdout に出力され、 /service/radius/log/main/current に書き出されるようになった。

Filed under: プログラミングと開発環境 — hiroaki_sengoku @ 08:02
2008年7月3日

Western Digital RMA チームから届いた文字化けメールを解読してみた

故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた」で書いたように、 RMA 手続きを行なった上で Western Digital へ故障したハードディスク ドライブ (以下 HDD と略記) を送ったら、 激しく文字化けしたメールが送られてきた。

あとは HDD が送られてくるのを のんびり待つだけと思っていたら、 わずか一日後 6/26 18:44 に Western Digital からメールが来た。 しかし文字化けがひどくて読めない。 最初は何語で書いてあるかすら判然としなかったのだが、 どうやら Shift JIS で書かれた文面を quoted-printable エンコードする際に なにか問題があったようだ。 例えば 0x82 が「,」に、0x95 が「.」に置き換わってしまっている。 置換が規則的でないので、 暗号解読よろしく一文字一文字置き換え規則を推測していくしかない。

文面を再現するのに時間がかかりそうだなぁ~と思っている間に、 交換品の HDD が届いてしまったので、 「暗号」解読するモチベーションを失ってしまっていたのだが、

Posted by 通りすがり 2008年07月02日 00:36
結局、メールにはなんて書いてあったのでしょうか?

というコメントを頂いてしまったので、 暗号解読してみることにした。

以下、Western Digital からの文字化けメールを全文引用 (一部伏字) する:

From: "Western Digital RMA" <noreply@wdc.com>
To: <sengoku@gcd.org>
Date: Thu, 26 Jun 2008 02:44:25 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-OriginalArrivalTime: 26 Jun 2008 09:44:25.0728 (UTC) FILETIME=[3861F800:01C8D771]

HIROAKI SENGOKU -l,=D6=81A

^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
,=CCfXfe=81[f^fX,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B  RMA
,=C9S=D6,=B7,=E9,=A8-=E2,=A2=8D?,=ED,=B9,=CD,=B1,=CCf=81=81[f<,=C9.=D4=90=
M,=B5,=C4,=AD,=BE,=B3,=A2=81B
=8F=EE.=F1,=AA=90=B3,=B5,=A2=8F=EA=8D?=81A,=B1,=CC"dZqf=81=81[f<,=C9,=CD.=
=D4=90M,=B5,=C8,=A2,=C5,=AD,=BE,=B3,=A2=81B


RMA "=D4=8D?=81F 8083XXXX

--------------------------------------------------------------

O=F0S=B7fhf?fCfu,=F0 5=81`7 ?c<=C6"=FA'?,=C9"=AD'-,=B5,=DC,=B7=81B

^=C8?=BA,=CCfhf?fCfu,=F0 Western Digital =
,=CDZ=F3-=CC,=B5,=DC,=B5,=BD=81F

     fVfSfAf<"=D4=8D?     =90=BB.i"=D4=8D?             =
Z=F3-=CC"=FA=81iGMT=81j
     ------------     ---------------      -------------
     WCASJxxxxxxx     WD10EACS-00ZJB0      6/25/2008

--------------------------------------------------------------

^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
"=AD'-=8F=F3<=B5,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B

-A'-<=C6Z=D2,=CCfVfXfef?,=CC=8DX=90V,=C91?c<=C6"=FA,=AA,=A9,=A9,=E8=81A,=BB=
,=CCO=E3"=AD'-'=C7=90=D5"=D4=8D?,=AA-LO=F8,=C9,=C8,=E8,=DC,=B7,=CC,=C5=81=
A,=B2-=B9=8F=B3,=AD,=BE,=B3,=A2=81B

O=F0S=B7fhf?fCfu,=CC'-.t=90=E6=81F

     HIROAKI SENGOKU
     XXXXXXXXXXXXXXXXXXXXXXXXX TAKATSU
     KAWASAKI, Japan 213-XXXX
     JAPAN

"z'-<=C6Z=D2=81F     Fedex
"z'-'=C7=90=D5"=D4=8D?=81F XXXXXXXXXXXX

     fVfSfAf<"=D4=8D?     =90=BB.i"=D4=8D?             =
"=AD'-"=FA=81iGMT=81j
     ------------     ---------------      -------------
     WCASJXXXXXXX     WD10EACS-32ZJB0      6/26/2008

--------------------------------------------------------------

S=D6~AfSf"fN=81F
RMAZ=E8=8F?ZwZ=A6=8F=EE.=F1,=CC?{--/^=F3=8D=FC
  - =

http://websupport.wdc.com/rd.asp?t=3D102&l=3Djp&p=3Dm&r=3D8083XXXX&f=3De

"=AD'-,=C6=8D=AB.=EF,=CC=8F=EE.=F1
  - http://websupport.wdc.com/rd.asp?t=3D103&l=3Djp&p=3Drp

RMAfXfe=81[f^fX,=CC?{--
  - =

http://websupport.wdc.com/rd.asp?t=3D104&l=3Djp&p=3Dv&r=3D8083XXXX&z=3D21=

3-XXXX

Western Digital fTf|=81[fgfz=81[f?fy=81[fW
  - http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh

^=C8=8F=E3=81A
WD RMA f`=81[f?

http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh

ヘッダに「quoted-printable」と書いてあるとおり、 quoted-printable エンコーディングを行なったのだろうが、 のっけから「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」となっていて、 一体何語なんだ?と思わせる始まり方である。

ちなみに quoted-printable というのは 8bit データを、 「印字可能 (printable)」つまり 7bit の英数字・記号だけで表現するための方法 (エンコーディング) で、 印字可能でない 8bit データは 16進数で表わして前に「=」をつける (「=」自身は「=3D」で表現する)。 例えば「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」は、 16進数で書くと 「5E C8 3F BA 2C C9 2E 5C 5A A6 2C B3 2C EA 2C BD」 という 8bit データ列を意味する。

腕に覚えのあるかたは、解答を見ずに解読を試みてはいかがだろうか?

もっと読む...
Older Posts »