<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Here is some information that might
help.<br>
<br>
Testing <a class="moz-txt-link-freetext" href="http://www.kriskinc.com/intel-pod">http://www.kriskinc.com/intel-pod</a><br>
<span id="sites-page-title" dir="ltr"><br>
Intel Packet of Death</span>
<font size="4">Testing:</font><br>
As described in my blog post <a
href="http://blog.krisk.org/2013/02/packets-of-death.html">here</a>
I experienced an issue with certain Intel ethernet controllers.
Here's how to see if your controllers are affected.<br>
<br>
For this simplified test you'll need two machines (one to replay
the packet and one to receive it) and you'll need to be on the
same ethernet segment. No routers or VLAN aware switches should
be in the mix (but dumb switches/hubs should be fine).<br>
<ol>
<li>On the replay machine install <a
href="http://tcpreplay.synfin.net/" target="_blank">tcpreplay</a>.</li>
<li>Connect the receiving machine to the network and bring the
interface up (IP address doesn't matter).</li>
<li>Replay one (or all) of the packets attached to this post
from the replay machine:</li>
</ol>
<p><i>sudo tcpreplay -v -i [transmitting interface] [pcap name]</i></p>
<p>Example:</p>
<p><i>sudo tcpreplay -v -i eth1 pod-icmp-ping.pcap</i></p>
<p>If your controllers are affected the ethernet interface will
lose link. In many circumstances the only way to get the
controller to work again is to physically power off the machine
and power it back on.</p>
<p>NOTE: These packets will be sent to the ethernet broadcast
address (to simplify testing). If you are affected by this
issue it will take down all of the ethernet interfaces on the
connected network. If that is of concern you should use
tcpreplay-edit to set a specific destination ethernet address:</p>
<p><i>sudo tcpreplay-edit --enet-dmac=00:11:22:33:44:55 -v -i eth1
pod-icmp-ping.pcap</i></p>
<p>Where "00:11:22:33:44:55" is the MAC address of the machine
you'd like to test.</p>
<p><font size="4">Fixing:</font></p>
<p><font size="4"><font size="2">As news of this <font size="2">issue
spreads further <font size="2"><font size="2"><font
size="2">some <font size="2">controllers are
affected and some aren't.<font size="2"> That's <font
size="2">m<font size="2">ore or less w<font
size="2">hat I e<font size="2">xpected. </font></font></font></font></font></font></font></font></font></font></font></font><font
size="2">Here's what I know about fixing<font size="2"> this.</font></font></p>
<p><font size="4"><font size="2"><font size="2"><font size="2">It
has been my underst<font size="2">anding that Intel
provide<font size="2">s <font size="2">at le<font
size="2">ast two EEPROM versions for this chip:
<font size="2">one with<font size="2"> BMC
enabled and one without.<font size="2"> My
controllers do not have BMC enabled, ther<font
size="2">efore my fix only applies to
non-BMC enabled controllers. This is un<font
size="2">fortunate <font size="2">because
<font size="2">the<font size="2">
BMC<font size="2"> </font>enabled
controllers seem to be much more
widely used<font size="2">. <font
size="2">Even with that<font
size="2"> o<font size="2">ther
than the very bas<font
size="2">ics (MAC
address and checksum)
I don't know the
meaning of these
values. Another reason
not to reprogram the
EEPROM on your NIC
based on what some guy
o<font size="2">n the
internet told you.</font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font></font><br>
</p>
<p><font size="2">With that being said her<font size="2">e<font
size="2"> <font size="2">is a <font size="2">diff
between a<font size="2">n affected E<font size="2">EPROM
and a good EEPROM:</font></font></font></font></font></font></font></p>
<p><font size="2"><font size="2"><font size="2"><font size="2"><font
size="2"><font size="2"><font size="2">Offset<span><font
size="2"> </font></span>Values<br>
</font></font></font></font></font></font></font></p>
<p><font size="2">-0x0010:<span><font size="2"> </font></span>ff
ff ff ff 6b 02 00 00 86 80 d3 10 ff ff 5a c0 <br>
+0x0010:<span><font size="2"> </font></span>01 01 ff ff 6b 02
d3 10 d9 15 d3 10 ff ff 58 85 <br>
<br>
-0x0030:<span><font size="2"> </font></span>c9 6c 50 31 3e 07
0b 46 84 2d 40 01 00 f0 06 07 <br>
+0x0030:<font size="2"> </font>c9 6c 50 21 3e 07 0b 46 84 2d
40 01 00 f0 06 07 <br>
<br>
-0x0060:<font size="2"> </font>ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff <br>
+0x0060:<font size="2"> </font>20 01 00 40 16 13 ff ff ff ff
ff ff ff ff ff ff </font><br>
</p>
<p>Where the "-" lines were the bad EEPROM and the "+" lines were
the good EEPROM.</p>
<p>Under Linux you can view these values with ethtool:</p>
<i># ethtool -e [interface]</i><br>
<br>
and Intel's Official statement<br>
<br>
Recently there were a few stories published, based on a blog post
by an end-user, suggesting specific network packets may cause the
Intel® 82574L Gigabit Ethernet Controller to become unresponsive
until corrected by a full platform power cycle.<br>
<br>
Intel was made aware of this issue in September 2012 by the blog’s
author. Intel worked with the author as well as the original
motherboard manufacturer to investigate and determine root cause.
Intel root caused the issue to the specific vendor’s mother board
design where an incorrect EEPROM image was programmed during
manufacturing. We communicated the findings and recommended
corrections to the motherboard manufacturer.<br>
<br>
<b>It is Intel’s belief that this is an implementation issue
isolated to a specific manufacturer, not a design problem with
the Intel 82574L Gigabit Ethernet controller.</b> Intel has not
observed this issue with any implementations which follow Intel’s
published design guidelines. Intel recommends contacting your
motherboard manufacturer if you have continued concerns or
questions whether your products are impacted. <br>
<br>
Mark<br>
<pre class="moz-signature" cols="72">
</pre>
On 10/02/2013 2:42 PM, Daniel O'Connor wrote:<br>
</div>
<blockquote
cite="mid:A003555B-D647-4694-976B-BE6BB05EE9FA@gsoft.com.au"
type="cite">
<pre wrap="">
On 09/02/2013, at 20:56, Edwin Groothuis <a class="moz-txt-link-rfc2396E" href="mailto:edwin@mavetju.org"><edwin@mavetju.org></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 7/02/13 10:37 , Heinz N wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Seems that certain packets can completely bring down certain Intel chipset network controllers.
<a class="moz-txt-link-freetext" href="http://blog.krisk.org/2013/02/packets-of-death.html">http://blog.krisk.org/2013/02/packets-of-death.html</a>
</pre>
</blockquote>
<pre wrap="">
<a class="moz-txt-link-freetext" href="http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement">http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement</a>
Intel blames it on a faulty EEPROM, but they don't say which mother board manufacturer.
</pre>
</blockquote>
<pre wrap="">
They don't provide any tools or instructions for testing the problem either.
Hopeless :-/
--
Daniel O'Connor software and network engineer
for Genesis Software - <a class="moz-txt-link-freetext" href="http://www.gsoft.com.au">http://www.gsoft.com.au</a>
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
_______________________________________________
AusNOG mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AusNOG@lists.ausnog.net">AusNOG@lists.ausnog.net</a>
<a class="moz-txt-link-freetext" href="http://lists.ausnog.net/mailman/listinfo/ausnog">http://lists.ausnog.net/mailman/listinfo/ausnog</a>
</pre>
</blockquote>
<br>
</body>
</html>