Whole-known-network
<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://hachyderm.io/@unlambda" class="u-url mention">@<span>unlambda</span></a></span> I'm debugging this in simulation (Amaranth makes it real easy to save stuff to a snoop file)</p>
<p><span class="h-card" translate="no"><a href="https://mastodon.social/@whitequark" class="u-url mention">@<span>whitequark</span></a></span> <span class="h-card" translate="no"><a href="https://hachyderm.io/@unlambda" class="u-url mention">@<span>unlambda</span></a></span> Wow.</p><p>Honestly I didn't even know it was possible to get FCSes in Wireshark because NICs normally drop frames with bad FCS so they don't show up in the capture.</p><p>Any time I've needed to troubleshoot FCS stuff I've slapped scope probes down on the *MII bus or the SFP diff pair or used my SFP/RJ45 mid-span tap fixtures then decoded in ngscopeclient</p>
<p><span class="h-card" translate="no"><a href="https://hachyderm.io/@unlambda" class="u-url mention">@<span>unlambda</span></a></span> yep!!</p>
<p><a href="https://gitlab.com/wireshark/wireshark/-/issues/20566" target="_blank" rel="nofollow noopener" translate="no"><span class="invisible">https://</span><span class="ellipsis">gitlab.com/wireshark/wireshark</span><span class="invisible">/-/issues/20566</span></a></p>
<p>i can't get mad at wireshark because it's been such an invaluably useful and mostly very reliable tool for years, but... seriously? you're gonna ignore my "always check FCS" because of the file format? this is completely undocumented? sigh.</p>
<p>today's "I can't believe I wasted half a hour on this" computer issue: whether Wireshark validates the Ethernet checksum in packets depends on the capture format you're using</p><p>.snoop: nope, and ignores all settings including "always check FCS"<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't got to the point of adding outbound 802.1q tags on trunk ports yet but when I do, I'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'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'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'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>
