もう4日間ずっとプログラムを書いてる。802.11MAC解析プログラム。
内輪向けの話なんで。
スクラッチから書き直し。言語はやはり漢仕様のC。実は2年前から書き直したかった。が、その頃はプログラムをそこまで書けるレベルではなかったので諦めた。最近はCがやっとわかるようになってきたし、時間を作って、書き直すことにした。
パケットキャプチャした結果の解析は、テキスト処理で解析する手法が簡単に行える。例えばEtherealやtcpdumpにプロトコルを一度解釈させてテキスト出力し、そのテキストをphpやperl等で処理する。しかしながらEtherealなどで簡易にテキスト出力できないパラメータを取り出したかったり、キャプチャした生データから1ステップでグラフ生成まで持って行きたい場合には、やはり、libpcapによるバイナリを直接編集する手法が必要となる。
今回もlibpcapを使っているので、tcpdumpもしくはetherealでキャプチャしたデータそのまま投げられる。libpcapのrubyラッパがあって最初に検討したのだが、MACとDCCPに対応しないし、対応させようとするとrubyラッパも書かんといけないので面倒。そんな事情があって、やはりC。
既存のプログラムでは、「ある時間区間のうち、(リトライビット0フレーム+リトライビット1フレーム)/リトライビット0フレーム」を再送レートとして計算していた。そのため、(送信成功1で送信失敗10)だと11/12=11になるが、時間区間が(送信失敗10で送信成功1で送信失敗10)になると21/1=21となり、あたかも1シーケンスナンバーで20回再送したような結果となってしまう問題があった。これは時間区間がある程度大きければ問題ないが、小さくした場合に問題が発生しやすい。
そこでMAC再送は時間平均ではなく、フレームの1シーケンスコントロールあたりで解析を行うようにした。ミクロな時間でのリトライアウトがはっきりし、TCPの高速再転送の原因の1つが明確になった。
またTCPだけでなく、RTP/UDPやDCCPにも対応できるように書いている。共通の指標で評価できるようにするため。
遅延やRSSI(受信電力強度)も数値化できるように書いている。リアルタイム伝送では遅延も評価したいから。RSSIはおまけ。
よく分からないが解析時間が1000分の1位になった。1秒以内に終わるようになった。
な、なんだってーーー!!
あー、ちょっとその、libpcapによるバイナリ編集を講座して欲しいな。
DCCP送信レートを計算するためのパラメータをどうにかして出力したかったんだ。手計算はもうこりごり。
受信電力強度なんて数値化できるんだ。