Intel needs to update alot of eeproms in netcards

[Tooms]

Seems Intel has a issue in the eeprom in many of the netcards

An interesting blog post by Kristian Kielhofer describes how a specific SPI packet can "kill" an Intel Gigabit ethernet card [1]. If a card is exposed to this traffic, the system has to be physically power cycled. A reboot will not recover the system.

http://isc.sans.edu/diary/Intel+Network+Card+%2882574L%29+Packet+of+Death/15109

[mikeselectricstuff]

I'm a bit puzzled as to how the eeprom can be involved - it usually just stores the MAC address.
Maybe there are some debug modes or something that were accidentally left enabled.

[amyk]

There's lots of other configuration info in there for the other features, such as "manageability" which is marketing-speak for being able to remotely control a machine while it is off by sending special packets through the ethernet controller. Those could cause many issues if not configured properly.

[madires]

I'm a bit puzzled as to how the eeprom can be involved - it usually just stores the MAC address.
Maybe there are some debug modes or something that were accidentally left enabled.

There are a lot of NICs with additional features to offload the CPU (mostly for servers). And don't forget WOL (Wake On LAN).

[madires]

Brief summary:
- Intel 82574L effected
- any packet with 0x32 at offset 0x47f crashs the NIC (for example: ping -p 32 -s 1110 x.x.x.x)
- might be related to ASPM (Active State Power Management)

[rr100]

Even the dumbest network card still needs to do "stuff", starting with recognizing its own MAC (of course you can outsource this to a driver in the OS and run it on the main CPU, some kind of "winmodem network card" but it would be extremely wasteful). Of course they do many other things even for low-end motherboards like checksum offload, WOL, etc.
Better cards have some really nifty features like layer 3 firewalls or lights-out management.

[Wuerstchenhund]

Seems Intel has a issue in the eeprom in many of the netcards

Nope, they don't:
http://www.h-online.com/security/news/item/Intel-Packet-of-Death-not-Intel-s-problem-1801537.html

In short: it's a single manufacturer who uses intel NICs on its products and who screwed up when flashing their EEPROMs.

[NiHaoMike]

If they had a robust CRC or other image integrity check, that problem would be caught during testing rather than continue on to cause a real nightmare.

[updatelee]

really doesnt surprise me, Ive done some work on various dvb cards in linux and the eeprom often stores the usb/pci vendor/subvendor id's. You can read or write the eeprom, I accidentally overwrote the vendor/subvendor id in the eeprom and sure enough it stuck, Linux would no longer load the driver because I had wrote 0000 for vendor/subvendor, a simple rewrite and I was good to go.  So if you can brick a dvb card over I2C Im not surprised you can brick an ethernet card over SPI.

UDL

[rr100]

Pre-2000 I bought one of the expensive-ish Creative sound cards and linux managed to brick 3 of them (as I was replacing them). The owner (which I knew very well) of the small shop that sold them to me wasn't happy at all...