I discovered a nigerian internet forum in english and I'm having the time of my life. I think I need to sign up

i wish i could be happy

@Mitsu@outerheaven.club preggers

<p><span class="h-card" translate="no"><a href="https://mastodon.social/@film_girl" class="u-url mention">@<span>film_girl</span></a></span> i was desperate for a gmail invite so i bought a couple on eBay.</p>

<p>The frame captured on the FPGA entering the transmit FIFO from the management/QSPI bus clock domain (i.e. data sent by the microcontroller to the FPGA) looks valid. </p><p>But looking closely we can see we sent 0x06fc0a02 with 2 valid bytes on the bus at the end of the frame. Those extra two invalid bytes should be ignored by the MAC but apparently weren&#39;t? Should be easy enough to mask off, but that doesn&#39;t explain where the extra 06fc at the end of the frame came from.</p>

<p>Ok this is definitely not right. Not sure what&#39;s going on exactly but these frames have a bad FCS.</p><p>Looking at the decode I see 0x0a 02 06 fc which is 10.2.6.252, the router interface on my lab sandbox network. All of the early bytes of the packet look right for an ARP reply.</p><p>But then at the end we have 0x0a 02 then a long string of zeroes then 0x06fc. I think somehow the last two bytes of the packet are ending up after the padding added to bring the ARP frame up to 64 bits, or something?</p><p>Not sure what to make of this, but it makes no sense.</p>

<p>Working on the 10GbE issue now. It&#39;s not playing nice, the firmware is seeing packets but replies from the firmware aren&#39;t going anywhere. Wireshark isn&#39;t seeing anything which probably means the problem is lower level than that (corrupted frames with bad CRC).</p><p>Time to fire up my trusty layer 1 packet sniffer.</p>

<p><span class="h-card" translate="no"><a href="https://mas.to/@MikeBeas" class="u-url mention">@<span>MikeBeas</span></a></span> exactly! Also the share url has been changed to a legit google blog url which is also hilarious.</p>