Kielhofner's response.<p><a href="http://blog.krisk.org/2013/02/packets-of-death-update.html" rel="nofollow">http://blog.krisk.org/2013/02/packets-of-death-update.html</a><p>I used to use "Lanner" gear for voip and these had embedded intel ethernets. I don't have any more of them to test, but I swear I've seen it on them as well. We suspected power supply problems because the link lights would just go dark every once in a blue moon and need a power cycle to set right, but then we were never be able to reproduce it.
Cross-posted at h-online.com:<p>I have a plurality of systems with <i>Intel</i> motherboards which demonstrate the same kind of problems. The motherboards in question have two Intel ethernet controllers, one of which is an 82574L.<p>The systems connect to two different networks. When the systems attach to one of the networks (but not the other) using the 82574L interface (but not the other), that interface dies after some unpredictable amount of time.<p>I have tried posting comments to the Intel engineer's blog post (and PM-ing the engineer directly), but they do not appear. In fact, there seem to be no comments at Intel's site, despite the post having nearly 6000 views (at my time of writing).<p>Something is not right here.
Company from Taipei flashes some Intel equipment, then it appears to function correctly, but can be bricked remotely with a specially crafted incoming packet.<p>Company has US branch that's a government contractor:
<a href="http://government-contractor.bizdirlib.com/ceo/Synertron_Technology_Inc" rel="nofollow">http://government-contractor.bizdirlib.com/ceo/Synertron_Tec...</a><p>Charming.
Firmware images usually have checksums. Was this an Intel blob suffering from bitrot, or does Intel have some more or less error prone way to build your own FW images for NICs?