随分とご無沙汰振りです。

つーか、12月初更新ですね(汗)

えー、第五回SCUGJ勉強会にご参加いただきました皆様、ありがとうございました。

思いっきりドン引きされていた感が無きにしも非ずですが、それなりにNVGREの理解を深めていただけたなら幸いです。

Packet Captureのお供として超有名で超役に立つWiresharkですが、某社向け資料を作っていてふと気が付いた事があるんですよ。

自分の中では暗黙知状態で、それを前提として話してたりしてたのですが、

常識じゃないじゃん!

という事に気が付き、超焦っているわけで、ちょっとした落とし穴の解説(多分、説明するまでもないのですけどもね)。

単純な話なんですが、L2のFrame Sizeっていくつでしょうか?

はい、ここで判った方あなたは正しくWiresharkを使われている方ですね。

まずこちら。

FCS_01

ありがちなPacket Chapture結果ですね。

で、Frame長を見てみると、1514byteですね。

TCPペイロード1460byte、TCPヘッダー20byte、IPヘッダー20byte、L2ヘッダー(Tagがないので)14byteで1514byte、表示されているFrame長どおりですよね……、って、ちょっと待ってください。

EthernetのFrame長って、1518byteじゃなかったっけ?

そうそう、802.1qのTagが4byteだから、1514byte+4byteで1518byteなのよね……ではなくて、Tagなしで1518byteじゃなかったっけ?? というお話なのです。

そうなんです。L2のTagなしのFrame長は1518byte、Tagありで1522byteなのですよね。

でもWiresharkのCapture結果はTagなしで1514byte……、4byteはどこに消えてしまったのでしょうか?

はい、解答。

FCS(Frame Check Sequence)という奴でして、こいつがL2 Frameの一番最後につきます。

これの役割はエラーチェックでして、宛先MACアドレス、送信元MACアドレス、タイプ、データの4つの領域の情報が正しいかをCRC (Cyclic redundancy check) 法を使ってエラー検出をする、という感じです。

正直、Packetが壊れなければ全く意識することが無いものなんですが、こいつが4byteの正体。

で、WiresharkでPacket Captureした際、このFCSがCaptureできない理由なのですが、

いわゆるところの「仕様」。

上のCapture結果を見ていただくと、TCPペイロードの1460byteでPacketは終了しています。4byteのFCSがCaptureできていない事が判ります。

これの詳細な理由がWiresharkのFAQに書かれているのですが、

Captureできないが普通。MacOS XでCaptureすればFCSもCaptureできるかもよ?

という事です。

Packet Errorでも起きない限りあまり意識することが無いFCSなんで、その存在を忘れる事もしばしば。WiresharkでもCaptureできないしね。

ゆえに説明する時も「4byte足りないけど、FCSがCaptureできないせいだから気にしないでね。説明は数字がずれるからFCSを除いた値で説明するので、実際には4byte足して考えてNe」と前ふりを随分入れていたのですが、ここんとこ
ずーーーーーっと忘れてましたorz

と、いう訳で、WiresharkでCaptureしながらPacket Sizeを説明する際は、FCSをオミットした見た目の数字で説明しますので、ご了承いただければ。

その前に、まずFCS4byteの説明を忘れるな、つー事ですね。

MacOS X買った方がええのですかねぇ……。