6月 242014
 

今回は IPv4 のお話ではなく IPv6 のお話です。でもって Path MTU Discovery のお話です。

僕は IPv6 は Hurricane Electric の IPv6 Tunnel Broker を利用しています。以前からここの IPv6 トンネルを利用させてもらっているのですが、とあるタイミングで IPv6 の http や ftp が通らなくなりました。あらま。 ping や ssh は通るので、仕事柄の経験上「あぁ。 Path MTU Discovery にハマったな。」というのはすぐに解りました。

『ハマった』というのは『送受信の二点間において MTU の最小値を決定することができなかった。』と、いうことかな。
どうして『決定できなかった』のかと言えば『Path MTU を探査できなかったから。』と、いうことになると思います。
Path MTU が Discovery できないとパケットのフラグメントが発生しないので MTU サイズ以降のパケットは捨てられてしまうために通信が行えなくなります。

 
しかし、Hurricane Electric の IPv6 トンネルは今まで利用できていたのにどうしてある日突然 Path MTU Discovery ができなくなってパケットサイズの大きい通信が止まるのだぁ? などと不思議に思うのであります。

まず、どうして Path MTU Discovery に失敗するのか?

1). 自分が設定したファイアーウォールで ICMPv6 の Type2 (Packet Too Big)を止めてしまった
2). ISP がある日突然 ICMPv6 の Type2 に ACL をかけた
3). Hurricane Electric で仕様が変わった

が考えられると思います。 1). については自分が設定したファイアーウォールを flush して確認できると思います。
2). の場合、僕は ISP を二つ契約している(自宅でマルチホームっ!!;-)ので両方の ISP で Hurricane Electric のサービスにトンネルを掘って確認してみましたが、どちらも http が止まります。
すると、残りは 3). が原因か、もしかして 2). の二つの ISP の両方が ICMPv6 Type2 に ACL を設定しているか。ですね。

まぁ、どっちにしても通信はできません。orz

 
次に、本当に IPv6 Path MTU Discovery ができていないのかの確認方法です。

1). IPv4 は ping・ssh・http の通信ができることを確認
2). IPv6 で ping・ssh・http の通信ができることを確認
3). ping6 -s 1434 au.kddi.com もしくは ping -s 1280 au.kddi.com

1). の確認において IPv4 で上記プロトコルが全て利用できるようであれば、問題は IPv6 のみに特定できます。
2). では Path MTU Discovery にハマると http の通信のみできなくなります。まぁ、ftp ででかいデータを持ってくるときとか、パケットサイズが 1,500 バイトに近くなる通信では止まってしまいます。
3). は、じゃぁ実際に何バイトのバケットサイズであれば通るのだ?という確認のために ping でパケットサイズを指定します。 1,434 もしくは 1,280 バイトで ping してみて、通る、通らないでサイズを変更して色々確認してみるのが良いかと思われます。

さてさて。これらで確認することにより IPv6 Path MTU Discovery な地雷を踏んだか確認できますが、次にその対応について考えてみたいと思います。

 
まずはネットワーク構成図などを。

Tunnel_NetWork_01

真ん中の黄色いのがトンネルルータで Hurricane Electric に対して gif0 でトンネルを掘っております。 em0 のインターフェースは一個目の IPv6 セグメントです。
また、トンネルルータでは dtcps を起動していて gif10 と gif10 で更に二つのセグメントとトンネルを掘っております。

このネットワークでの IPv6 Path MTU Discovery の状態は・・。

1). 同一セグメント内では通信ができる
2). セグメント 1,2,3 の間ではで通信ができる
3). セグメント 1,2,3 から gif0 を抜けて Hurricane Electric の先にある IPv6 サイトと通信ができない

と、いうことが解りました。 どうやら MTU もしくは MSS の調整は re0 か gif0 で行う必要がありそうです。

 
が、その前に、クライアント PC 側で何か対応する手立ては無いか調べてみました。

1). クライアント PC の MTU を 1434 にする
2). IPv6 より IPv4 を先に利用するようにする

1). の場合は UNIX 系 OS だと比較的容易にできます。以下は FreeBSD で MTU を変更する場合のコマンドです。

# ifconfig re0 mtu 1434

 
IPv6 Path MTU Discovery でハマった時には MTU を1434 にしてあげると通信が復活します。セグメント内にいる全ての UNIX 系 OS で上記コマンドを叩く必要があります。

2). のほうは WindowsOS で有効な手段です。 DOS のプロンプトをアドミン権限で起動し、以下のコマンドを打ちます。

c:\ netsh interface ipv6 show prefixpolicies
c:\
c:\ netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 50 0
c:\ netsh interface ipv6 set prefixpolicy ::1/128 40 1
c:\ netsh interface ipv6 set prefixpolicy ::/0 30 2
c:\ netsh interface ipv6 set prefixpolicy 2002::/16 20 3
c:\ netsh interface ipv6 set prefixpolicy ::/96 10 4

 

一行目のコマンドはステータスの確認です。これを見ると IPv6 のほうが先に利用されるように設定されているので IPv4 を先に利用するようにその後のコマンドでプライオリティを変更してあけます。

もとに戻すときにはこちらのコマンドで。

c:\ netsh interface ipv6 set prefixpolicy ::1/128 50 0
c:\ netsh interface ipv6 set prefixpolicy ::/0 40 1
c:\ netsh interface ipv6 set prefixpolicy ::ffff:0:0/96 35 4
c:\ netsh interface ipv6 set prefixpolicy 2002::/16 30 2
c:\ netsh interface ipv6 set prefixpolicy ::/96 1 3

 

これで WindowsOS もなんとか IPv6 Path MTU Discovery を回避できたのではないかと思われます。ちょっと弱い問題解決ですが・・。

しかし、IPv6 に対応しているスマートフォン(iOS や Windows Phone OS など)は IPv6 サイトが見られないんですよねぇ・・。

さてさて。こんなことばっかりしていても根本的な問題解決にならないので次に根本的な解決をしてみたいと思います。

 
IPv6 Path MTU Discovery ができないときの原因としては ICMPv6 の Type2 (Packet Too Big) パケットのやりとりができず、通信するための最小 MTU サイズが特定できないために発生します。それならばパケットを送信する側でパケットの最小サイズを明示的に指定して送信すれば良い(それはつまりは TCP SYN パケットの MSS オプション値を書き換えてあげる。と、いうことです)わけなんですけども FreeBSD にその機能があるのか?

今回利用しているトンネルルータは FreeBSD 9.1-RELEASE です。こいつには pf(4) があるのでそれを利用することにします。と、いうか、現状では pf(4) でしか制御できないようです。
他にもports に net/tcpmssd があるようなのですが、今回は pf(4) を利用することにします。

ちなみにトンネルルータのファイアーウォールは ipfw で設定しているのですが MSS のサイズは pf で設定することにします。
今回は ipfw の設定は省きます。以下は /etc/pf.conf の設定です。

scrub in  on re0  from any to any max-mss 1280
scrub out on re0  from any to any max-mss 1280
scrub in  on gif0 from any to any max-mss 1280
scrub out on gif0 from any to any max-mss 1280
pass all

 
FreeBSD の MSS サイズを固定に設定するためには max-mss を利用します。サイズは 1280 にします。上記構成図では re0 から抜けるパケットのみが 1,280 バイトになります。通常 IPv4 パケットは別の BB ルータから抜けていく(構成図には書かれていない)のでまぁ、問題は無いでしょ。

re0 と gif0 の両方の MSS サイズを小さくしている設定をしていますが、試した結果 gif0 のみの MSS を1280 に設定するだけで十分でした。

設定が完了したら以下のコマンドを打ちます。

# kldload pf
# kldload pflog
# kldstat
        :
33    2 0xffffffff8104b000 2a4a5    pf.ko
34    1 0xffffffff81076000 9c9      pflog.ko
#
# /etc/rc.d/pf onestart
# pfctl -sr
        :
# pfctl -sa
        :
#

 
カーネルモジュールをロードし、無事にロードできたか確認します。次に /etc/rc.d/pf を onestart で実行します。無事に実行できたかは pfctl の二行で確認(オプション -sr と -sa)しましょう。出力結果は省略します;-)。
無事に動作することができたら /etc/rc.conf などに pf_enable=”YES” などと書きましょう。

 
最後に確認方法ですが、簡単です;-)。セグメント 1,2,3 の各クライアント PC から IPv6 サイトが無事に見えるかどうか。だけです;-)。

au.kddi.com とか running-dog.net とか icmpv6.org などが無事に見えると pf で設定した max-mss 1280 が有効になっている。と、いうことですね。

 
とまぁ、ある日突然 IPv6 Path MTU Discovery が通信できない問題が降ってきたわけですけども、その対応策などをツラツラと書いてみました。皆さん、是非とも IPv6 Path MTU Discovery にハマらないようにしたいと思うわけですけども、もしハマったら pf で回避してみてください。

ふぅ。それにしても復活だぁ・・。

6月 192014
 

GNOME 方面の人にはまるで興味が無いとは思うのですが、 KDE というか Qt を利用している人にとっては、ご存知な方もいるのではないかなぁ?

世の中には超軽量ブラウザというのが存在しています。 rekonq も konqueror に比べると軽量かなぁ。arora も軽量ですね。 rekonq よりも軽量なのが QtWeb というブラウザです。 arora と同じくらい軽量かなぁ。

以下が QtWeb のサイトですね。

http://qtweb.net/

ここを見ると Windows・OS X・Linux と世界の三大ウィンドを制覇しているんですけどもね;-)。で、それぞれバイナリがあるのですが、ソースコードもあるので、それを FreeBSD に持ってきてコンパイルすると FreeBSD 上でも動作するんですけども。

キャプチャはこんな感じです。

Qtweb_1

で、せっかくなので今回は QtWeb の ports を作ってみました。 arora が ports になっているのに QtWeb が ports になってないのは悲しいことですし;-)。
以下の URL にあるのでもしも「僕も私もちょっと FreeBSD 上で QtWeb を使ってみようかなぁ。」などと思った人は試してみてください。

http://icmpv6.org/Prog/FreeBSD_ports/ports-qtweb-20140619.tgz

あ。コミットするつもりはありません。あくまでノラ ports ということで;-)。

QtWeb の ports の仕様やインストール方法などをちょっと書いてみます。

o. QtWeb をコンパイルするには Qt 4.8.6 のソースコードが必要
FreeBSD の ports 的には qt4-* で色々インストールされているのですが、 QtWeb は Qt ライブラリを static link するので FreeBSD の ports 的な Qt ライブラリは必要としません。
GNOME や xfce4 な人も Qt や KDE のコンポーネントをインストールすることなく Qt コテコテなブラウザを楽しむことがてできます。

しかし、裏を返すと Qt ライブラリ部分もコンパイルするのでコンパイル時間が随分と長いです。orz

僕が作成した ports では /usr/ports/distfiles/KDE/ に Qt 4.8.6 のソースがあればそれを利用し、なければとある日本のサイトからダウンロードしてきます。詳細は files/patch-qt-src.sh を見てください。

o. ports がインストールするもの
QtWeb のサイトからバイナリをダウンロードすると、本当に QtWeb 本体のみしかパッケージングされてないのですが、僕の作った ports では QtWeb バイナリの他に icon として QtWeb.png と QtWeb.desktop をインストールするようにしています。インストール直後から KDE のインターネットメニューに表示されるようにしました。

o. QtWeb の起動
ports からインストールすると /usr/local/bin/QtWeb ができるのでそれを実行するのですが、実行後にできるディレクトリが美しくないです。以下の三つのディレクトリができます。

・$HOME/.QtWeb Internet Browser/
・QtWebCache/
・QtWebSettings/

一番上の .QtWeb Internet Browser/ は $HOME にできるので良いのですが、 QtWebCache/ と QtWebSettings/ はどこにできるかわかりません。実行したときにいるカレントディレクトリにできたりとか、ヘタするとあちこちに QtWebCache/ と QtWebSettings/ ができてしまうような感じです。orz
なお、メニューから QtWeb の設定を変更するとその内容は QtWebSettings/ に保存されます。

が、しかし、それにしてもこの二つのファイルはどこにできるのか解らない・・。orz
ソースコードを書き換えてやろうかと思ったほどですが・・。
なのでしょうがない。起動用にスクリプトを一個書きました。

#!/bin/sh

cd $HOME/.QtWeb\ Internet\ Browser
QtWeb > /dev/null 2>&1
#/usr/local/bin/QtWeb > /dev/null 2>&1
#cd  $HOME

 
$HOME/.QtWeb Internet Browser/ 配下に QtWebCache/ と QtWebSettings/ が作成されるようにするためのスクリプトです。
不便やのぉ・・。って感じなのですが、ソースコード的には browserapplication.cpp の数カ所を直せばちゃんとコントロールできるんじゃね? って感じはします。

 
こんな感じの QtWeb というブラウザなのですが、もしよければ皆さんもコンパイルして使ってみてください;-)。

 
あ。最後にですが、 Qt-Webkit は x-sjis と x-euc-jp には対応してないので文字化けします。 rekonq も konqueror も Qt-WebKit を利用しているのでやはり x-* な文字コードは表示できません。最近は少なくなってきましたが、今では僕が知っている有名ドコロは VECTOR が x-sjis を利用しているので表示できません。

この件については以前 KDE 方面で(その昔は) Nokia の Qt のコードを書いている人に聞いたことがあるのですが、非対応だそうです。するっていと同じ KHTML から派生の Apple-WebKit は独自に x-* な文字コードに対応した。と、いうことなのでしょうなぁ。

 
PC に色々ブラウザが入っていると楽しいですよ;-)。 是非、試してみてください。;-)

6月 122014
 

ウェブサイトを斜め読みしていたら「安くて良い音がするヘッドホンが Amazon で売っていて人気になっている。」とのことだったので僕も購入して試してみました。

僕が看過された記事はこちらになります。

http://av.watch.impress.co.jp/docs/review/minireview/20140602_650832.html

なるほど。良い感じなのね。ちなみに今回購入したイヤフォンは iPhone5 で利用する予定です。

現状、 iPhone5 で音楽を聞く場合には iPhone5 に付属の EarPods を利用しているのですが、それについて以前のエントリである「iPhone5 利用してみました。」と「EarPods にスポンジ付けてみました。」に書いています。今回購入したのが、この Apple 謹製の EarPods イヤフォンと比較してどう違うのか、僕の耳と僕の感性でレポートしてたみいと思います。

とわ言いつつ、そんなに音にうるさいということは全然、全くないのですけどねf(^^;;。

 
さて。 Amazon で購入したのは送料込み 3,980yen でした(すごいグッドなタイミング;-)。下にリンクつけておきます;-)。 Amazon からはダンボールな箱ではなく、袋に入っていて届きました。中から出してみましたがこんな感じ。

IMG_7170_BEB_868B_1

付属品としては説明書と、巾着袋。あと、耳あてのゴムの替えパーツがドドドと大量に、色々な形のモノが入っていました。 Audio-Technica のイヤフォンを購入した場合は大・中・小が入っていますが、今回の Blue Ever Blue 868B にはその他にもゴロゴロと色々なのが入っていました。

IMG_7171_BEB_868B_2

さて。実際に音を聞いた感じですが、比較対象として iPhone5 に付属の Apple EarPods とになります。上にある二つの前回のエントリでは EarPods はすげー。ってことに、僕の中ではなっているのですが、今回はどうなったでしょう? ちょっと明らかな違いを箇条書きにしてみますね。

・音の広がり方は Blue Ever Blue 868B のほうが断然良い
・重低音ドドドは Apple EarPods が勝ち

こんな感じでしょうか。上に掲載した URL を見てみると HDSS 技術が素晴らしい。と、書かれていますが、僕にはその技術がどういうモノかよく判りませんf(^^;;。

 
話はガラリと変わるのですが、 docomo の『d ミュージック』から購入した楽曲は AAC 320kbps で iTMS の 楽曲の 256kbps より音が良い。と言われますが、僕にはその違いが判りません。ただ、d ミュージックで購入した楽曲は iTMS で購入した楽曲より音が大きいような気がします。音が大きいと色々な音が拾えるようになるので、だから「良い音の楽曲」に聞こえるのかなぁ。などと個人的に思ってしまうんですけども。

 
さてさて。今回確認のために利用(試聴)した曲目も書いておきましょう。

AKB48 の「Everyday、カチューシャ」はイントロ部分の右側の聞こえない音が聞こえてきます。これは前回書きました;-)。「ポニーテールとシュシュ」は音の広がりが体感できます。メンバのハモッている声までバッチリ聞こえます。
Loudness の「Crazy Night」はイントロ部分はちょっと重低音(フロアバスの音)が抜けるかなぁ。あと、最近は angela の「シドニア」をよく聞いているのですが、この曲は Apple EarPods で聞いたときの音のほうが好きです。

あ。楽曲を作る人は、聴く人が持っている環境(プレーヤーやスピーカー・ヘッドホンなど)に音色を合わせて音作りをする。と、いう話を聞いたことがあるので、もしかしたら新たしめの楽曲は Apple EarPods に合わせてチューニングした音作りになっているモノも多分あるのでしょうなぁ。

それにしても、僕は基本的には重低音好きな人ということになりそうですねf(^^;;。あ。 Blue Ever Blue 868B は重低音が弱い。なんてことは決してないです。7,8 年前のイヤフォンに比べると全然良い感じの音です。そして、それにしても音の広がりについては圧巻です。

 
と、いうことで比較はここまで。

あと、物理的な構造に対しての好き嫌いもあると思うのですが、

・簡単にポロっと耳から抜け落ちてしまう Apple EarPods
・しっかりとしたアルミ筐体で耳にピッタリとフィットする Blue Ever Blue 868B
・ケーブルというかコードの作りはこんがらない素材を利用している Apple EarPods が勝ち
・Blue Ever Blue 868B は耳に入れたりするときにクシャっと音がするのは素材は解らないがコーン紙が圧力で音を立てているのかな?

これらのの四点を音の観点にプラスしてみても Blue Ever Blue 868B を常用したくなります。ただ、最後の一点はちょっと心配ですが、僕の持っている個体の問題なのかな?

そして、あと、一点。

・リモコン機能どうするの?

って話がありますが、僕の場合、 Audio-Technica の AT338iS を持っているのでこれを再登場させることにしました。 iPhone5 → AT338iS → Blue Ever Blue 868B と接続することになるのですが、間に AT338iS が入っても回路的な音の劣化は、僕の耳では感じられませんでした。

 
と、いうことで、 Apple EarPods も定価で購入すると 2,200yen 、 Blue Ever Blue 868B も 3,980yen と非常に安価で良い音が手に入ります(耳に入るのかな?;-)。

 
と、いうことで今回はここまでにしておきます。比較や試聴の対象として皆さんの手元にあるモノを例に取り上げてみました。この文章を書いた人(それはつまりは僕のことですが)は AKB48 好き。なんてことは多分・絶対に無いのではないかと思われます;-)。