車載ネットワーク バックナンバー

車載ネットワーク バックナンバー車載ネットワーク
スポンサーリンク

はじめに

主に車載ネットワークのEhternet関連についての記事。
https://www.simulationroom999.com/blog/in-vehicle-network-backnumber/

スポンサーリンク

登場人物

博識フクロウのフクさん

指差しフクロウ

イラスト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

スポンサーリンク

BLF

  • 上司からの恒例の無茶振り。
  • BLFというVector社の独自フォーマットにEthernetの収録情報が入っているらしい。
  • ダメ元でいろいろ調べていくことに。
  • BLFの仕様書はCANoeのインストールフォルダから発掘。
  • 仕様書は全部で6個。
    • 「CAN_and_General_BLF_Format.pdf」が基本的な仕様。
    • その他は各物理層向けの追加仕様。
  • BLF仕様のライセンスについて確認。
    • 一言でまとめると「Vectorが一切責任を負わないことを条件に好きにしていいよ」。
  • BLF仕様の概要説明。
    • オブジェクトヘッダとオブジェクトの仕様がポイントとなる。
  • BLFのオブジェクトヘッダの説明。
  • CANオブジェクトの説明。
  • Ethernetオブジェクトの説明。
  • BLFのオブジェクトヘッダを追っかけた。
  • 仕様書にないオブジェクトタイプが存在。
  • 実データ部は圧縮か、暗号化されている様子。
  • BLFの中身はzlibで圧縮されたもの。
  • オブジェクトは”LOBJ”というシグネチャを先頭に始まるルールのもよう。
  • BLF解凍用の言語はPythonを採用
    • zlibとか配列の制御が楽ちん。
  • zlib解凍後のデータはまだ全貌がつかめていないので、改めて再調査予定。
  • BLFのオブジェクト抽出とzlib解凍のPythonコードを書いた。
    • オブジェクト抽出に起因するコードが支配的。
  • zlib解凍後のファイルも解析が必要。
  • BLF内のオブジェクトの頭出しは”LOBJ”という文字列であり、先頭の方はxmlによるメタ情報が埋まっていた。
    • よって、今回はテキストエディタで無理やりBLFを開いてみた。
  • メタ情報はOS,CANoe,回線,使用しているデータベースファイルなどが記載されている。
  • zlib解凍済みBLFをバイナリエディタで覗いて各フレームを抽出。
    • CANフレーム抽出。
    • Ethernetフレームを抽出。
  • mObjectTypeと仕様書上のオブジェクト構成はオブジェクトヘッダのサイズから雰囲気で特定。
  • フレーム抽出&テキスト化のプログラミング言語はPythonを使用予定。
  • zlib解凍済みBLFをCANフレーム、Ethernetフレーム単位に分解するPythonコードを書いた。
    • mObjectType:0x56 → CANフレーム。
    • mObjectType:0x78 → Ethernetフレーム。
  • BLFをフレーム単位にテキスト出力した。
    • CANフレーム解説。
    • Ethernetフレーム解説。
  • Ethernetフレームはマルチキャストになっている。
スポンサーリンク

EthernetFrame

  • 3つの通信方式を説明。
    • ユニキャスト。
    • ブロードキャスト。
    • マルチキャスト。
  • ブロードキャストとマルチキャストは似て非なるもの。
    • ブロードキャストは同一ネットワーク。
    • マルチキャストは同一グループ。
  • Ethernetフレーム説明。
  • IPヘッダ説明。
  • ブロードキャスト、マルチキャストを理解するには上記二つの理解が重要。
  • IPアドレスは、サブネットマスクでネットワーク部とホスト部に分かれる。
  • ブロードキャストアドレスは2種類存在。
    • リミテッドブロードキャストアドレス。
    • ディレクティッドブロードキャストアドレス。
  • マルチキャストはMACアドレスでグループが確定する。
  • ただし、MACアドレスはSocketLibrary等で制御できないため、IPアドレスとの紐づけルールが存在。
  • ユニキャスト、マルチキャスト、ブロードキャストのまとめ。
    • ノードで見た場合。
    • MACアドレスで見た場合。
    • IPアドレスで見た場合。
通信方式MACIP範囲備考
ユニキャスト送信先はノード個別のMACノード個別のIP単体 
ブロードキャスト送信先はFF-FF-FF-FF-FF-FF255.255.255.255全体別ネットワークを指定することも可能。192.168.0.255/24等
マルチキャスト送信先は01-00-5E-[グループIPの一部]グループIP特定の複数MACにグループIPの一部を含めることでデータリンク層のレベルで送信先を決定。
スポンサーリンク

IPフラグメント

  • BLFのEthernetFrameを分解してみた。
    • UDPだった。
    • データ長がEthernetFrameの最大長を超えていた。
      • つまり、IPフラグメント仕様が使われている。
  • IPフラグメントに着目してEthernetFrameを確認。
    • IPヘッダのフラグでIPフラグメントになるかどうかが決定する。
    • 断片化位置で全体のどこのデータかが分かるようになっている。
  • 2フレーム目を確認。
    • これもIPヘッダのフラグは継続。
    • 断片化位置の値は、その値×8が実際のデータオフセット位置となる。
      • よって、IPフラグメントは8byte境界の仕様が暗黙的に発生する。
  • IPフラグメント最後のEthernetFrameを確認。
    • IPヘッダの継続フラグが0。
    • 残りのサイズが埋まっている。
      • 断片化位置が8byte境界になっていればよいので、パケット末端は8byte境界である必要はない。
  • 真面目に結合していくとメンドクサイ。
    • 次回以降にちょっとした裏技をやる予定。
スポンサーリンク

プロトコルスタック

スポンサーリンク

lwIP

スポンサーリンク

lwIP疑似受信

スポンサーリンク

生パケット送信

スポンサーリンク

npcap

スポンサーリンク

lwIP+npcap

スポンサーリンク

100base-T1

コメント

タイトルとURLをコピーしました