<p>i can&#39;t get mad at wireshark because it&#39;s been such an invaluably useful and mostly very reliable tool for years, but... seriously? you&#39;re gonna ignore my &quot;always check FCS&quot; because of the file format? this is completely undocumented? sigh.</p>

<p>today&#39;s &quot;I can&#39;t believe I wasted half a hour on this&quot; computer issue: whether Wireshark validates the Ethernet checksum in packets depends on the capture format you&#39;re using</p><p>.snoop: nope, and ignores all settings including &quot;always check FCS&quot;<br />.pcap: yep</p><p>saving a .snoop file as a .pcap file makes it immediately check all FCS</p>

<p><span class="h-card" translate="no"><a href="https://infosec.exchange/@sycophantic" class="u-url mention">@<span>sycophantic</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> Interesting all of my MACs to date has just treated the 802.1q tag the same as an ethertype for the most part (only caring about the tag once i start making forwarding decisions) and my padding insertion logic pads the entire frame to 64.</p><p>I haven&#39;t got to the point of adding outbound 802.1q tags on trunk ports yet but when I do, I&#39;ll probably need to patch my MAC code that does padding insertion to change the target frame length based on whether a tag is present</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> I do emphasize the similarity between the Wasm stack and LLVM variables here! you can&#39;t create new LLVM %n variables at runtime in the same way</p><p>the Wasm stack is conceptual, it is not an actual physical stack you can use for normal stack type things. it&#39;s basically a compression mechanism (oversimplifying)</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> well that&#39;s good to know because the next thing i was about to do was use a counter in a local to make the stack depth dynamic lol</p>

<p><span class="h-card" translate="no"><a href="https://ioc.exchange/@azonenberg" class="u-url mention">@<span>azonenberg</span></a></span> <span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> 68 octets if a vlan tag is present. <a href="https://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://www.</span><span class="ellipsis">cisco.com/c/en/us/support/docs</span><span class="invisible">/lan-switching/8021q/17056-741-4.html</span></a></p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> My read on this is that the FCS is included within the 64 byte minimum frame size.</p><p>802.3-2012 4.2.3.3</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> yes, 64 octets including src/dest MAC, 802.1q tag if present, ethertype/length, frame body, and FCS.</p><p>Preamble/SFD and interframe gap do not count towards the 64</p>

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@mcc" class="u-url mention">@<span>mcc</span></a></span> alignment: i think it works like this:</p><p>i32.load align=2</p>