バックナンバーはこちら。
https://www.simulationroom999.com/blog/In-vehicle-network-backnumber/
はじめに
BLFに埋まっていたEthernetFrameをIPフラグメントの最終フレームを見てみる。
IPフラグメント最後のEthernetFrameを確認。
IPヘッダの継続フラグに着目。
断片化位置がアライメントとパケット末端のアライメントについて。
などなど。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
IPフラグメント最後のEthernetFrame
実際のところ、今回のIPフラグメントは8フレームあった。
まぁサイズがUDPパケットのサイズとして10861[byte]で
1EthernetFrameに載せられるデータサイズが1480[byte]が上限になるから、
10861÷1480=7.338513513513513
で最小でも8フレームになっちゃうもんね。
そうそう
そして、今回は3～7のフレームと飛ばして最後の8フレーム目を見る。
0x01,0x00,0x5e,0x00,0x01,0x01,
0x10,0x6f,0x3f,0x0f,0xd6,0xdd,
0x08,0x00,
0x45,
0x00,
0x02,0x09,(全長=0x209=521)
0x6a,0xdc,
0x05,0x0f,// (フラグ=000b=継続なし,断片化位置=0x50f=10360[byte])
0xff,
0x11,
0x88,0xd3,
0xc0,0xa8,0x0A,0x0B,
0xec,0x00,0x01,0x03,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,…
8byte境界のルールはどうなった？
フラグの継続ビットが0だから、これの後ろにはもうフレームは存在しないことがわかるね。
IPフレームのサイズが521[byte]で、
IPヘッダ自体が20[byte]だから、データ部は501[byte]ってことか。
あれ？
前回、IPフラグメントは8byte境界になるようなこと言ってた気がするけど、
最後のフレームは8byte境界になっていないような・・・。
8byte境界に制約は途中のフレームに対する制約だねー。
8byte境界の前提となった断片化位置は、
そのフレームの先頭を表現しているだけなんで、
最後フレームが8byte境界で終わる必要はない。
あー、なるほど。
言われてみれば確かにそうか。
パディングでも埋めるのかなとか思ったけど、
必要ないね。
実際に解析する場合は？
んー、IPフラグメントの理屈はわかったけど、
これって結構解析が面倒だよねー。
なんとかならんもんかなー。
まぁMACアドレス、IPアドレス、IPヘッダのフラグ/断片化位置をちゃんと見て結合していくしかないかなー。
えー、そこをなんとかする便利技とかないのー？
うーん、無いこともないが、
これも結構なイバラの道なんだよなー。
イバラの道しか無ぇ・・・。
まぁ選択肢として知ってはおきたいかな。
じゃー次回からその話ー。
まとめ
まとめだよ。
- IPフラグメント最後のEthernetFrameを確認。
- IPヘッダの継続フラグが0。
- 残りのサイズが埋まっている。
- 断片化位置が8byte境界になっていればよいので、パケット末端は8byte境界である必要はない。
- 真面目に結合していくとメンドクサイ。
- 次回以降にちょっとした裏技をやる予定。
バックナンバーはこちら。
コメント