Date: Sat, 09 Feb 2013 10:25:52 -0800 From: matt <sendtomatt@gmail.com> To: Johnny Eriksson <bygg@cafax.se> Cc: FreeBSD Net <freebsd-net@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Intel 82574 issue reported on Slashdot Message-ID: <511694B0.4060805@gmail.com> In-Reply-To: <CMM.0.91.0.1360397743.bygg@mail.cafax.se> References: <CMM.0.91.0.1360397743.bygg@mail.cafax.se>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02/09/13 09:15, Johnny Eriksson wrote: >> In all honesty.. The blog post (and your email) are basically >> information free, they don't name names and provide no script >> or downloadable code that will allow end users to check if they >> are affected. > A link with a little bit more information: > > http://blog.krisk.org/2013/02/packets-of-death.html > >> Daniel O'Connor software and network engineer > --Johnny > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > Did anyone check to see if the Intel announcement had a 2 at 0x47f? :) I do have a machine with these controllers that had a bridge "hang" in a very odd fashion a while back, but it didn't repeat. It wasn't a SuperMicro board, which is what some posters were saying were affected. I would imagine a large ping packet (as used to test MTU) should inoculate any affected interface if issued at boot, I don't think our padding lines up with the problem. Once an interface sees a packet with anything else at 0x47f, it's no longer affected, so there's a narrow window of vulnerability in affected NICs. Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?511694B0.4060805>