問題タブ [raw-ethernet]

最近は、組み込みシステムでの raw イーサネットのサポートに取り組んでいます。主に教育目的とノウハウのため。Google で見つかったいくつかのデータを使用して、ARP サポートを実装し、UDP/TCP トランスポート層のサポートを分離することができました。残念ながら、両方 (UDP/TCP) を同時にサポートするには問題があります。基本的に、着信フレーム プロトコルを認識できないため、UDP または TCP ハンドラに送信するかどうかを判断できません。不正なデータを取得するリスクなしに両方に送信することはできません。その情報を示すビットフィールドがあると思っていましたが、見つかりません。

この情報を数日間探していますが、おそらく何かを誤解しているため、情報源が見つかりません.

件名を説明したり、どこを見ればいいのかを説明したりして、経験豊富な IT 担当者に助けを求めることはできますか? 私は行き止まりにいるような気がします。

前もって感謝します。

IEEE 802.3 でイーサネット フレーム フォーマットを読み取る場合、EtherType は次のように説明されていました。

1. 0 ～ 1500 (10 進数) は、パケット データのペイロード長です。
2. 1536(0x600) 以上は、値がフレームのタイプを決定していることを意味します (例: 0x800 は IPV4 を表します)。

1501 から 1535 の間の値はどうですか? これらの値が除外されたのはなぜですか?

注: Wiki リンクでは、定義されていないと言及されています。しかし、標準化されたドキュメントでは説明として見つかりません。

FCS はイーサネット パケット フレーム構造の最後の部分であることがわかっているため、FCS 部分をチェックすることで、データ転送でエラーが発生したかどうかを確認できます。ETHERNET II または DIX パケットの FCS チェックについて質問があります。これらのフレームのフレーム構造にはパケット長がありません。正しい FCS がデータの途中に存在するパケットに直面した場合はどうすればよいですか。たとえば、パケットはバイト 128 で 512 バイトの長さを持っています バイト 128 まで正しい FCS が表示されますが、実際にはいくつかのバイトが残っています。最悪のケースは正しい長さの最後にあります。パケット長に加えて、FCS エラーが表示されます。フレーム構造に記載されていません。どうすればよいですか? ジャンボ フレーム (802.3) イーサネット II および DIX でこの問題が発生します。