答えを先に書くと・・・

• Windowsを初めとしたOSは、FCS（Frame Check Sequence）をアプリケーションに渡さない仕様だから。
• Wiresharkは最少フレームサイズが64バイトであるように解析結果を表示するが、実際は上記OSの仕様のため、4バイト少ない60バイトのデータとして受け取っている。その為、FCSエラーとして示されている 00 00 00 00 部分は実はダミー（パディング）。
• mbedの問題ではない。

対策

• 気にしない。
• WiresharkでUDPを受ける場合、パケットのデータを１回あたり22バイト以上にする。（19バイト以上でも一応エラーは出ない。）
• FCSもキャプチャーできる機材を導入する。

mbedでUDPのネットワークプログラムを作っていると、Wiresharkのエラーに出合います。
例えば、このような事例です。

[ ETHERNET FRAME CHECK SEQUENCE ]というエラーが出ています。
また、解析結果も FCS Bad となっています。

これは、OSに起因する仕様で、Windows Linux MacOS いずれの環境においても発生します。
例えば、この Frame 17 では、フレーム全体で66バイトでFCS部分が存在しませんが、通信としては成立しています。
この事から、FCSはOS側で破棄されている事が分かります。

つまり、エラーはWiresharkによる解析ミスが原因と言えます。

しかし、FCSを含めて解析したいWiresharkとしては、FCSが渡されない事の方が問題とも言えるため、本事例は仕様だと思われます。
その証拠にFCSを無視せずに、FCSがある事を前提にした解析をするオプションがあります。
（ Assume packets have FCS： デフォルトではオフであるため、FCSが無い場合を想定しています。 ）

対策は特に必要ありません。

FCSのエラーが気になる場合は、UDPデータサイズを22バイト以上にする事で、OSから渡されるフレームデータにダミー（パディング）が含まれなくなるため、エラーが出なくなります。

（実際に試してみると、19バイトでも解析エラーが出ませんでした。恐らく、渡されたフレームデータからUDPの部分を除き、データが4バイト以上余ったらFCSと見なす処理が入っている為だと推測します。）