Tcpreplay

home

FAQ

一般的な質問／General Questions

Q:どうして大文字の Tcpreplay なの？／How should Tcpreplay be capitalized?

大文字の 'T' の場合は、 Tcpreplay のツール群(tcpreplay, tcpprep, tcprewrite, など)を示します。 個別のユーティリティの tcpreplay を示す場合は小文字 't' になります。 'TCPreplay' や 'TCP replay' などと記述することはありません。

Q:Tcpreplay の入手方法／Where do I get Tcpreplay?

(ダウンロードとインストール) Download and Installation にアクセスしてください。

Q:Tcpreplay のインストール方法／How do I install Tcpreplay?

コンパイルする必要があります。 (ダウンロードとインストール) Download and Installation にアクセスしてください。

Q:Windows バージョンはありますか？／Is there a Microsoft Windows port?

Windows 2000 以降なら Cygwin を使って動作します。 近い将来、Windows 上で (Cygwin を使わず)直接実行できるようになるかもしれません。 (ボランティアを募集してます。) 詳細情報は(Tcpreplay に含まれる) Win32Readme.txt ファイルを見てください。

Q:Tcpreplay のライセンスは？／How is Tcpreplay licensed?

Tcpreplay のライセンスは GPLv3。 詳細情報は(Tcpreplay に含まれる) docs/LICENSE ファイルを見てください。

Tcpreplay の実行／Running Tcpreplay

Q:tcpreplay はサーバにトラフィックを送信できますか？／Does tcpreplay support sending traffic to a server?

(ウェブサーバやメールサーバなどのように)ポートを LISTEN する、 Unix の daemon(デーモン)や Windows の service(サービス)との通信であれば、 tcpliveplay を試してみてください。 Tcpreplay に含まれる tcpliveplay 以外の他のツール・コマンドは、 TCP プロトコルで使われるようなステートを理解しません。 つまり、正常な TCP セッションを作るための SYN/ACK の同期ができません。 tcpliveplay は pcap ファイルに含まれる 1つの TCP ストリームを読み込み、 サーバとコネクションを確立し、pcap ファイルに含まれる内容をサーバに送出します。

tcpliveplay は ICMP や UDP では動作しませんが、 tcpliveplay 以外の再送信ツールでは、 MAC アドレスや IP アドレスが正しくセットされていれば動作します。 tcprewrite や tcpreplay-edit を使うと pcap ファイルを書き換えることができます。 プロトコルによっては ICMP や UDP のペイロードに Layer 3/4 の情報を含める場合があります。 (SIP はその 1つの例になります。) 従って、IP アドレスを書き換えた場合、 正しい SIP のパケットにならないことに注意してください。 このような場合は NetDude を使ってパケットのペイロードを書き換えてください。

Q:なぜ Tcpreplay は指定した速度でトラフィックを送信できないのですか？／Why doesn't Tcpreplay send traffic as fast as I told it to?

netmap ドライバを使って --netmap オプションを指定してください。

(指定した速度でトラフィックを流せないような症状は) 小さなパケットを再送出しようとする時に発生することが多いです。 例えば、平均 646 バイトのパケットを 9Gbps で再送出しようとする場合...

# tcpreplay -i eth7 -K --loop 5000 -M 9000 --unique-ip smallFlows.pcap
File Cache is enabled
Actual: 71305000 packets (46082655000 bytes) sent in 40.09 seconds.
Rated: 1124993518.4 Bps, 8999.94 Mbps, 1740734.40 pps
Flows: 6045000 flows, 147573.65 fps, 71215000 flow packets, 90000 non-flow
Statistics for network device: eth7
    Attempted packets:         71305000
    Successful packets:        71305000
    Failed packets:            0
    Truncated packets:         0
    Retried packets (ENOBUFS): 0
    Retried packets (EAGAIN):  0

... そして、平均 77バイトの(小さな)パケットを再送出しようとする場合と比較してください。

# tcpreplay -i eth7 -K --loop 50000 -M 9000 --unique-ip tiny-packets.pcap 
File Cache is enabled
Actual: 550000 packets (42600000 bytes) sent in 0.259064 seconds.
Rated: 164438131.1 Bps, 1315.50 Mbps, 2123027.51 pps
Flows: 100000 flows, 386005.00 fps, 300000 flow packets, 250000 non-flow
Statistics for network device: eth7
    Attempted packets:         550000
    Successful packets:        550000
    Failed packets:            0
    Truncated packets:         0
    Retried packets (ENOBUFS): 0
    Retried packets (EAGAIN):  0

pcap ファイル の中身が小さいパケットの(後者の 77バイト)の方が、 単位時間あたりのパケット数 (pps) も単位時間あたりのフロー数 (fps) も大きいですが、 単位時間あたりの送信 bit 数 (bps) には影響されません(速度は大きくなりません)。

tcpreplay でなるべく速くトラフィックを送信するための工夫・アイディアがあります:

Q:tcpreplay を実行しているマシンでパケットを送出できますか？／Can I send packets on the same computer running tcpreplay?

一般的にはできません。tcpreplay がパケットを送出する時は、 システムの TCP/IP スタックと (NIC の)ドライバの間に割り込みます。 その結果、tcpreplay を動作させてるシステムの TCP/IP スタックは、 パケットが見えなくなってしまいます。

この問題の解決策として、VMWare や Parallels や Xen など(の仮想化機能)があります。 tcpreplay を仮想マシン(GuestOS) 上で動作させれば、 ホストマシン(HostOS) では送出したパケットを見れます。

Q:古いバージョンの tcpreplay はパケットを書き換えできたのに(今はできません)／Older versions of tcpreplay allowed me to edit packets. What happened?

tcpreplay-edit や tcprewrite を使ってください。

Q:tcpprep でキャッシュファイルを作る必要性は？ tcprewrite だけでは動かない？／Why do I need to use tcpprep to create cache files? Can't this be done in tcprewrite?

tcpprep のほとんどのモードでは、pcap ファイル全体を確認します。 どのパケットがサーバのものでどのパケットがクライアントのものであるかを決める前に、 (pcap ファイル中の)全てのパケットを確認します。 pcap ファイル全体を見る必要がありますし、2回読み込まれることもあります。 (高速な動作を求められる) tcpreplay に、 このような tcpprep のロジックを組み込むことは事実上許されません。

2つ目の理由として、tcpreplay も tcpreplay-edit も tcprewrite も tcpprep のキャッシュファイルを利用できるので、 (tcpprep を)個別のユーティリティとして分離することは有効です。 そして、複数回にわたって pcap ファイルを書き換えたり、 実際にパケットを送出する時にも機能させることが可能になります。

Q:tcpreplay が全てのパケットを送出しない理由は？

時折、(pcap ファイルの中の)全てのパケットが送信されない bug があるのではないか、 というメールが tcpreplay-users のメーリングリストに投稿されます。 -t オプションを使った場合に、全てのパケットが送信されない症状が発生しがちです。 このような場合は、NIC は(Tcpreplay から)パケットを受け取ったのですが、 (ネットワーク上に)送信できないのです。 この問題は、ハードウェアに大きく依存しています。

ネットワークソケットが混雑しているかどうかを表示させるのは重要です。 tcpreplay は、(pcap ファイルの)次のパケットの処理に移行する前に、 (NIC の)バッファが書き込める状態になるまで待ちます。 もしパケットが欠落する現象が発生した場合、 NIC がパケットを受け取った後に問題が発生したことになります。

以前のバージョンでは以下のような症状がありました:

tcpreplay を何度も実行し、かつ、 パケットを何発送信したかを数えるために tcpdump や他のスニファーツールを使っている場合、 (tcpreplay と tcpdump で)パケットの送信数が異なる場合があります。 これは tcprepaly の問題ではありません。下記を調査してください:

  1. tcpdump や他のスニファーツールでは高速通信時に問題があることがよく知られています。 さらにその上、OS は多くの場合、どの位のパケットが欠落したかを間違って報告します。 Tcpdump はこれ(OS)が言うままに間違って報告します。言い換えるなら、 tcpdump は全てのパケットを見ている訳ではないのです。 たいていの場合、これは NIC やドライバや OS のカーネルの問題で、 問題を解決できるかできないかは不明です。NIC や NIC のドライバを変更してみてください。

  2. tcpreplay がパケットを送信するのは、カーネルの送信バッファにコピーすることになります。 この祖バッファが一杯になっている場合、カーネルは tcpreplay に対して、 バッファにコピーしないよう伝えます。 カーネルがこのエラーを表示しないようなバグを持っている場合、 tcpreplay はパケットを再送信することもなく次のパケットの処理に進んでします。 現時点で、このようなバグを持つカーネルは見つかっていませんが、現実にはありえます。 もしこのような問題を持つ OS を見つけた場合は、ぜひ私達に報告してください。

  3. Tcpreplay は、インターフェイスの MTU よりも大きなパケットは送信できません。 一般的には、 ifconfig ツールなどを使って Ethernet の MTU をデフォルトの 1500バイトよりも大きくしますが、 商用利用の環境において(MTU を大きくすること)は勧められません。 MTU の不一致の問題は非常に分かりづらいです。 そして、ネットワークのスピードは六分の一程度になってしまいます。

  4. NIC のハードウェアで checksum を計算するような場合に、 (1Mbps のような)低レートな環境下でも tcpdump のようなツールがパケットロスを発生するような報告があります。 NIC でこのような(ハードウェアで checksum を計算する)設定を無効にすることで、 パケットロスは発生しなくなります。これは tcpreplay の問題ではありません。

Q:tcpreplay の送信タイミングがデタラメなのはなぜ？

時折、パケットの送信タイミングがデタラメだと文句を言います。 たいていの場合は、正しくないタイムスタンプを含んだ pcap ファイルが原因です。 もっと具体的に言うと、キャプチャファイルの中のとあるパケットが、 それ以前のパケットのタイムスタンプよりも古い時刻を持つなどです。 NIC のハードウェアでタイムスタンプが付与された後に、 (ソフトウェア的に)複数のキューに分割されてしまう場合に発生します。 このような場合には、 パケットが到着した順序とは異なる順序で(pcap ファイルに)保存されてしまいます。

Q:tcpreplay は複数のネットワークカード(NIC)で使えますか？(Tomahawk (というアプリケーション)のように)

使えます! tcpreplay はずっと前から 2つのインターフェイスを使って高速で再送信する機能を持っています。 (Tomahawk が登場するずっと前からです) トラフィックを 2つのインタフェイスでどう分離するかについては、 tcpprep の man ページに詳細が記述されています。

Q:tcpreplay は gzip/bzip2 圧縮されたファイルを読み込めますか？

読み込めますが、直接的には読み込めません。 tcpreplay は STDIN(標準入力) からファイルを読み込めるので、 下記のような方法でオンザフライで展開できます:

gzcat myfile.pcap.gz | tcpreplay -i eth0 -

オンザフライでファイルを展開するには CPU 時間が消費されるので、 tcpreplay のパフォーマンスが下がってしまいます。

Q:tcpreplay はどのくらいの速度でパケットを送出できますか？

まず初めに、パフォーマンスが重要なのであれば、4.x にアップグレードする価値があります。 3.x シリーズから最適化されています。 次に、パフォーマンスや、 あなたがどう測定するか(packet/sec や bytes/sec)について影響する変数はたくさんあります。

パフォーマンスは、指定したオプション、再送信する pcap ファイル、 ハードウェアなどに依存します。 netmap がサポートされている NIC を使うとパフォーマンスが大きく向上しますが、 自分の首を絞めないように注意してください。 --netmap オプションを使う間は、 テストの期間中はネットワークドライバは使われなくなります(バイパスされます)。

tcpreplay を i7 processor/Intel 82599 10GbE NIC で動作させた例を出します。 --netmap オプションを使うことで、 ほぼワイヤーレートで 157K flows/sec を実現できます。

# tcpreplay --preload-pcap -i eth0 --loop 500 -t --unique-ip --netmap smallFlows.pcap 
Switching network driver for eth0 to netmap bypass mode... done!
File Cache is enabled
Actual: 7130500 packets (4608265500 bytes) sent in 3.08 seconds.
Rated: 1197981408.4 Bps, 9583.85 Mbps, 1853670.63 pps
Flows: 604500 flows, 157148.01 fps, 7121500 flow packets, 9000 non-flow
Statistics for network device: eth0
    Attempted packets: 7130500
    Successful packets: 7130500
    Failed packets: 0
    Truncated packets: 0
    Retried packets (ENOBUFS): 0
    Retried packets (EAGAIN): 0
Switching network driver for eth0 to normal mode... done!

注意 上記の例では、最初に出した例と比較して、ほぼワイヤーレートを実現しています。 この pcap ファイルの平均的なパケットサイズは 646 (4608265500 ÷ 7130500) バイトです。 10GbE の Ethernet では 17 バイトの IFG(Inter Frame Gap) とプリアンブルと SOF(Start Of Frame) と FCS(Frame Check Sequence) が付与されるため、 663 (646 + 17) バイトになります。 そして Ethernet 上では (663 ÷ 646) × 9582.85 = 9836 Mbps となります。 Finally, the manufacturer of this adapter does not claim 100% wire rate because it is front-ended by a hardware timestamp feature. You may achieve 100%.

(例えば GigabitEthernet において 1048 Mbps などのように) 最大値を超える値が表示されるかもしれません。 You may achieve 100% with your adapter and maybe even more.

The next example is the same except limited to 9500Mbps with the -M option. As of version 4.0 there is little overhead in using this option.

# tcpreplay --preload-pcap -i eth0 -l 500 -M 9500 --unique-ip --netmap smallFlows.pcap 
Switching network driver for eth0 to netmap bypass mode... done!
File Cache is enabled
Actual: 7130500 packets (4608265500 bytes) sent in 3.08 seconds.
Rated: 1187498663.2 Bps, 9499.98 Mbps, 1837450.38 pps
Flows: 604500 flows, 155772.91 fps, 7121500 flow packets, 9000 non-flow
Statistics for network device: eth0
    Attempted packets:         7130500
    Successful packets:        7130500
    Failed packets:            0
    Truncated packets:         0
    Retried packets (ENOBUFS): 0
    Retried packets (EAGAIN):  0
Switching network driver for eth0 to normal mode... done!

When using pcap files with tiny packets, full wire rate is not achieved. The limiting factor is the flows per second (fps). Notice that in the following example we achieve 1.8 million fps and our packets per second (pps) rate has jumped dramatically.

# # tcpreplay --preload-pcap -i eth0 -l50000 -t --unique-ip --netmap tiny-packets.pcap 
Switching network driver for eth0 to netmap bypass mode... done!
File Cache is enabled
Actual: 550000 packets (42600000 bytes) sent in 0.054122 seconds.
Rated: 787110601.9 Bps, 6296.88 Mbps, 10162226.08 pps
Flows: 100000 flows, 1847677.46 fps, 300000 flow packets, 250000 non-flow
Statistics for network device: eth0
    Attempted packets:         550000
    Successful packets:        550000
    Failed packets:            0
    Truncated packets:         0
    Retried packets (ENOBUFS): 0
    Retried packets (EAGAIN):  0
Switching network driver for eth0 to normal mode... done!

If anyone achieves better results or has 40GigE results, please share.

Q:どうやったらもっと速くパケットを送出できますか？

tcpreplay では、 パケットをネットワークに書き出す時間がもっとも影響を与えています。 tcpreplay はこれにほとんどの時間を取られているため、 使っている OS のカーネルが raw sockets に書き込む実装方法は、 最も重要事項になります。

Profiling tcpreplay has shown that a significant amount of time is spent writing packets to the network. Hence, your OS kernel implementation of writing to raw sockets is one of the most important aspects since that is where tcpreplay spends most of it's time.

下記は順不同で:

Q:tcpreplay は Endace DAG カードで使えますか？

デフォルトでは tcpreplay は Endace DAG カードをサポートしません。 しかし、Endace 社 は、 Endance 社の DAG カードをサポートする特別な tcpreplay をリリースしました。 Tcpreplay の開発者達は、この特別な tcpreplay はサポートできませんので注意してください。 何か質問がある場合は、Endace 社に問い合わせてください。

Q:pcap ファイル以外のキャプチャファイルを使えますか？

pcap ファイルのフォーマット以外にも、非常にたくさんのフォーマットがあります。 (Solaris snoop などのように) 別なツールで作られたキャプチャファイルを使う場合は、 Wireshark's の tshark ツールなどを使って pcap フォーマットに変換してください。

tshark -r blah.snoop -w blah.pcap

Q:Tcpreplay は Pcap-Ng/NTAR ファイルを読み込めますか？

はい、読み込めます。Tcpreplay ツール群は、pcap ファイルの読み書きに libpcap を使っています。libpcap 1.1.0 以上を使っていれば、 tcpreplay や tcprewrite などは pcap-ng ファイルを読み込めます。 古い libpcap を使っている場合は、最新の libpcap にバージョンアップすべきです。 初期の libpcap には pcap-ng ファイルに関する問題があります。

Q:tcpreplay は Wi-Fi からパケットを送出できますか？

送信できるかどうかは、OS やハードウェア依存の話題になります。 しかし、たいていの場合は送信できます。 送信するためには、通常は下記の手順になります:

Q:loopback インターフェイスから送出したパケットが見えないのはなぜ？

loopback インターフェイスを経由して UDP パケットを再送信しようとする時、 loopback インターフェイスで待ち受けているデーモンにおいて、 (tcpreplay が送信した)パケットを受信できないということに、 たくさんのユーザが驚くようです。 これは、多くの OS での loopback インターフェイスの制限事項です。 1つの要因として、Ethernet インターフェイスでパケットをキャプチャして、 IPアドレスを書き換えただけで Layer2 のヘッダを書き換えないことがあります。 loopback インターフェイスは Ethernet の Layer2 ヘッダを使わないため、 OS の IP(Internet Protocol)スタックはパケットを処理できず、 待ち受けているデーモンにパケットを届けられないのです。

Q:iptables などでトラフィックコントロールできますか？

tcpreplay を実行しているのと同じサーバでは、iptables/tc は使えません(機能しません)。 tcpreplay で送信したパケットに IPTables や Traffic Control (tc) を適用するには、 tcpreplay を iptables/tc とは別のサーバで動作させ、 tcpreplay で送信したパケットを iptables/tc のサーバを経由させる方法しかありません。 この制限事項は、Linux カーネルがフレーム(パケット)を挿入する方法と、 iptables/tc のためにフレーム(パケット)を読み出す方法の差異によるものです。 この違いで、tcpreplay が送出するトラフィックは、 iptables/tc からは参照できなくなります。

Tcpreplay のコンパイル／Compiling Tcpreplay

Q:XXX 用のバイナリファイルはありますか？

たぶんあると思います。 私達は、いかなる OS 用にもバイナリファイルをリリースしません。 Linux や *BSD や Solaris や OS X などのたくさんの OS では、 tcpreplay などのオープンソースなアプリケーションをパッケージにするチームがあり、 それぞれのパッケージフォーマットで(RPM や BSD/Mac ports や SunFreeware などで) リリースしています。

Q:お願いしたらバイナリを作ってくれますか？

いつでも依頼して良いのですが、きっとその依頼は無視されてしまいます。

Q:パケットを送出するための方法が見つかりません。libpcap をバージョンアップするか libdnet を有効化してください

Tcpreplay は、パケットを送信するために多くの API やライブラリを使えます。 BSD の BPF や、Linux の PF_PACKET や libpcap や libdnet です。 もし BPF や PF_PACKET がサポートされていないプラットフォームで使いたい場合は、 最新バージョンの libpcap や libdnet が必要になります。 libpcap を使うのであれば、最新バージョンにアップグレードすることを強く勧めます。 libpcap にはバグがあるし、頻繁にアップデートされているからです。 それに対して、libdnet は数年間アップデートが無い状態ですが、 古いバージョンの libnet ライブラリよりは新しいバージョンの方が安定しています。

ここで、libdnet が必要なケースを紹介します: Linux や *BSD 以外で tcpbridge を使いたい場合です。

注意: Tcpreplay はもう libnet はサポートしません! (libdnet はサポートされます)

Q: tcpedit_stub.def: Command not found

Making all in tcpedit
make[2]: Entering directory `/home/acferen/tcpreplay-trunk/src/tcpedit'
tcpedit_stub.def
make[2]: tcpedit_stub.def: Command not found
make[2]: *** [tcpedit_stub.h] Error 127
make[2]: Leaving directory `/home/acferen/tcpreplay-trunk/src/tcpedit'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/acferen/tcpreplay-trunk/src'
make: *** [all] Error 2

GitHub のソースコードをビルドしようとしている時のみ、 上記のエラーが発生するはずです。(普通の tarball では発生しません) この問題は GNU Autogen がインストールされていないことが原因です。 autogen をインストールするか、tarball をダウンロードしてください。

Q: tcpreplay_opts.h:72:3: error: #error option template version mismatches autoopts/options.h header

GitHub のソースコードをビルドしていて、 インストールされている Autogen/AutoOpts が libopts のバージョンと異なるためです。 結果として、OS の Autogen が生成する src/*_opts.[ch] が、 バージョンミスマッチとなってしまいます。

この問題を解決するには: ./configure --disable-local-libopts --disable-libopts-install

Q:autogen や libopts に関する話題

Tcpreplay のツール群は GNU の Autogen/libops ライブラリを使います。 これによりとても便利に開発できるようになりますが、コストもかかります。 一般に、Autogen/libopts ライブラリはあまり後方互換が良くないので、 ソースコードを書いた人とは異なる Autogen/libopts を使っていると、 tcpreplay のコンパイル時に問題となりえます。 例えば、下記のようなエラーになります:

make[3]: Entering directory
`/root/services_from_source/tcpreplay-3.0.beta11/src/tcpedit'
if gcc -DHAVE_CONFIG_H -I. -I. -I../../src    -I.. -I../common -I../..   -g
-O2 -Wall -O2 -funroll-loops -std=gnu99 -MT tcpedit.o -MD -MP -MF
".deps/tcpedit.Tpo" -c -o tcpedit.o tcpedit.c; \
then mv -f ".deps/tcpedit.Tpo" ".deps/tcpedit.Po"; else rm -f
".deps/tcpedit.Tpo"; exit 1; fi
In file included from tcpedit.c:46:
tcpedit_stub.h:18:30: autoopts/options.h: No such file or directory
In file included from tcpedit.c:46:
tcpedit_stub.h:50: error: syntax error before "const"
tcpedit_stub.h:50: warning: type defaults to `int' in declaration of
`tcpedit_tcpedit_optDesc_p'
tcpedit.c:58: error: syntax error before "const"
tcpedit.c:58: warning: type defaults to `int' in declaration of
`tcpedit_tcpedit_optDesc_p'
make[3]: *** [tcpedit.o] Error 1

良い方法があって、下記で簡単に解決できます: ./configure --enable-local-libopts

Q:Fedora Core/RedHat で発生するリンクできない問題

新しいバージョンの Fedora Core や Red Hat ES/WS では、 static library は同梱されず dynamic library だけになります。 もしソースコードから tcpreplay をコンパイルする場合は、 tcpreplay が library をリンクできるよう、configure を実行する時に --enable-dynamic-link を指定する必要があります。

一般的なエラー／Common Errors

Q: Unable to send packet: Error with pcap_inject(packet #10): send: Message too long

OS X (少なくとも 10.4.9 までの) バグです。 (tcpreplay や tcpbridge が動作する時もそうですが)送信元の MAC アドレスを偽って、 1500 バイト以上の Ethernet フレームを送信する時に発生します。 アップル社は 10.5(Leopard) でこの問題を修正しました。 現時点で、ワークアラウンド(回避方法)はありません。

Q: Can't open eth0: libnet_select_device(): Can't find interface eth0

たいていの場合は、(例えば eth0 などの)インターフェイスが UP していなかったり、 あるいは IPアドレスが設定されていない場合に発生します。

Q: Can't open eth0: UID != 0

Tcpreplay は root(管理者)権限で実行する必要があります。

Q: 100000 write attempts failed from full buffers and were repeated

tcpreplay が "100000 write attempts failed from full buffers and were repeated" のようなメッセージを出力する時は、 たいていカーネルバッファが一杯になっており、 メモリに書き込めるようになるまで処理を停止する必要があります。 -t オプションを指定して最大速度で送信している時に発生します。 この文章の「OS のチューニング」のセクションを読めば問題を解決できます。

Q:test.cache を処理できない／cache ファイルのバージョンミスマッチ

tcpprep で生成され tcpreplay で利用される cache ファイルのフォーマットは、 機能拡張のためにいくつかのバージョンがあります。 (Tcpreplay の)バージョンアップの際に、 cache ファイルのフォーマットは変更されるかもしれません。 フォーマットは滅多に変更されませんが、いつでも変更されうるものです。 この場合、以前の別のバージョンで生成された cache ファイルと互換性が無くなります。 同じバージョンの tcpreplay と tcpprep であれば、 cache ファイルを読み書きできます。 cache ファイルの各バージョンと、tcpprep/tcpreplay のバージョンの対応表は下記です:

2.3.0 以前のバージョンの tcpprep には、 big endian と little endian のシステム間で互換性が無い問題があるので注意してください。

Q:SLL loopback パケットがスキップされる

Linux でパケットをキャプチャし、インターフェイスを 'any' 指定するなどしたため、 loopback のインターフェイスでもキャプチャされました。 (これらのパケットは) tcpreplay が実際にパケットを送信するだけの十分な情報が無いので、 パケットはスキップされるのです。 宛先または送信元の MAC アドレスを (-D や -S で) 指定すれば、 この問題は解決します。

Q:8892 バイトのパケットが MTU より大きいくてスキップされる

(下記の例では 8892 バイトの) パケット長が、 送信するインターフェイスの MTU(Maximum Transmition Unit)よりも大きいです。 Tcpreplay は、このパケットは破棄せざるをえません。 代わりに、tcpreplay-edit で パケットサイズを MTU に切り詰める --mtu-trunc オプションを指定することで、 フレームのチェックサムも再計算され送信できるようになります。 ただし、パフォーマンスに影響するので注意してください。

Q:tcpreplay がパケットの一部しか送信しない／tcprewrite がパケットをトランケートする

tcpreplay ではエラーが発生していないように見えると思います。 pcap ファイルを Ethereal/Wireshark で見てみると 400バイトのパケットなのに、 tcpreplay では 100バイトしか送信していないことに気付くかもしれません。

このようなエラーはこれまでに 2-3回遭遇したことがありますが全て同じ原因で、 pcap ファイルが破損していました。 どうやら、Red Hat に同梱された古い libpcap のバグが原因のようです。

pcap ファイルの破損が疑われるような場合は、 エラーを検出するために tcpcapinfo を実行してみてください。

まず初めに、pcap ファイルのフォーマットの背景から記述します。 それぞれの pcap ファイルの先頭には、 (色々な情報がありますが)とりわけ snaplen のファイルヘッダがあります。 snaplen の情報は、パケットごとの最大データサイズです。 もしパケットがこの値よりも大きい場合には、 そのパケットはトランケートされます。 それぞれのパケットには、len と caplen を含むパケットヘッダを含んでいます。 len はもとのパケットサイズで、caplen は実際に記録されているデータサイズです。

正しいフォーマットで記録された pcap ファイルでは、 caplen > snaplen になるようなことはありえません。 残念なことにいくつかのツールやアプリケーションでは、 このような問題が発生してしまいます。 従って libpcap ライブラリがこのようなファイルを読み込んだ場合に、 実際のデータ長として snaplen の値を使用してしまいます。 Ethereal/Wireshark は pcap ファイルの読み込みに libpcap ライブラリを使わないため、 もとのパケットサイズを表示することになるのです。

この問題を解決するためには、 16 バイト(0x10)オフセットした先の 2バイトを 0xFFFF に変更します。 これにより pcap ファイルが修正され、 libpcap や tcprewrite や tcpreplay などで正しく読み込めるようになります。

破損した pcap ファイルの例:

xxd broken.pcap | head -3
0000000: d4c3 b2a1 0200 0400 0000 0000 0000 0000  ................
0000010: 6000 0000 0100 0000 1b6f 954b ca25 0e00  `........o.K.%..
0000020: 4a00 0000 4a00 0000 0000 5e00 0101 0015  J...J.....^.....

正しく修正された pcap ファイルの例:

xxd fixed.pcap | head -3
0000000: d4c3 b2a1 0200 0400 0000 0000 0000 0000  ................
0000010: ffff 0000 0100 0000 1b6f 954b ca25 0e00  .........o.K.%..
0000020: 4a00 0000 4a00 0000 0000 5e00 0101 0015  J...J.....^.....

Q:tcpreplay が順番通りにパケットを送信しない

これは tcpreplay の問題ではありません。 受信したネットワークカードやドライバの問題です。 この問題が発生した 1つの例として、 Broadcom の 10GbE の NIC で "multi_mode" を有効にする場合が挙げられます。 bnx2x のドライバで "multi_mode=0" を設定すれば問題が解決します。 Linux カーネルの v2.6.24 で、このデフォルト値が ON になったようです。

以前は、NIC がハードウェアで時刻情報を付与したような時に、 この問題が発生していました。

Tcpreplay のユースケース／Use Cases for Tcpreplay

Q:ユースケース(外部サイト)

Q:他のドキュメント

Open Source on GitHub
Maintained by
Sponsored by AppNeta

https://github.com/appneta/tcpreplay
Fred Klassen and AppNeta
http://appneta.com