Onderwerp: Issue met Intel 82574L Ethernet controller

http://blog.krisk.org/2013/02/packets-of-death.html

Comments?

Oorspronkelijk geplaatst door cyrano

Comments?

teveel tekst, geen samenvatting?

Oorspronkelijk geplaatst door pierce

teveel tekst, geen samenvatting?

Joking?

TL;DR

From: http://www.kriskinc.com/intel-pod

Example:

sudo tcpreplay -v -i eth1 pod-icmp-ping.pcap

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.

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:

sudo tcpreplay-edit --enet-dmac=00:11:22:33:44:55 -v -i eth1 pod-icmp-ping.pcap

Where "00:11:22:33:44:55" is the MAC address of the machine you'd like to test.

kort genoeg?

Oorspronkelijk geplaatst door cyrano

Comments?

Het klinkt vrij serieus, het ligt er een beetje aan op welke EEPROM versies dit probleem nu echt van toepassing is om te zeggen dat het een enorm probleem is of niet. Heb hier en daar die controller ook, maar voor zover ik me kan herinneren nergens in productie machines op publiekelijk bereikbare NICs.

Wat raar is is dat er niet eens een OS hoeft te draaien (aldus de claim) om de poort helemaal af te sluiten tot een eerstvolgende reboot.
Bij een desktop machine van mij met deze adapter erin heb ik in het verleden wel dit soort van problemen gezien, maar was er niet in geslaagd om het betrouwbaar te reproduceren.

Wat verder ook vrij storend is is dat intel erkent dat er een probleem is, maar dat ze geen patch wensen te releasen.
Hopelijk zal de blog post op krisk.org ze er iig toe bewegen om een nieuwe firmware te releasen.

Oorspronkelijk geplaatst door pierce

teveel tekst, geen samenvatting?

The executive summary is available for a mere 1500 $ ;-)

Oorspronkelijk geplaatst door wila

Het klinkt vrij serieus, het ligt er een beetje aan op welke EEPROM versies dit probleem nu echt van toepassing is om te zeggen dat het een enorm probleem is of niet. Heb hier en daar die controller ook, maar voor zover ik me kan herinneren nergens in productie machines op publiekelijk bereikbare NICs.

Wat raar is is dat er niet eens een OS hoeft te draaien (aldus de claim) om de poort helemaal af te sluiten tot een eerstvolgende reboot.

Helemaal raar is dat niet.
Een NIC heeft een stukje intelligentie, of, laten we zeggen, frame matching logica .
Er is natuurlijk het matchen van headers (unicast, broadcast, een programmeerbaar aantal multicast groepen).
En, met Wake on Lan zit er ook logica om in de content van het frame specifieke bytes te matchen en dan iets te doen.

Kortom, er zit genoeg in de NIC dat een 'sleep on lan' functie/(bug) bij een bepaalde set bytes in een frame best kan voorkomen, zonder achterliggende intelligentie (cq bugs) van een OS nodig te hebben.

Oorspronkelijk geplaatst door visser

Helemaal raar is dat niet.
Een NIC heeft een stukje intelligentie, of, laten we zeggen, frame matching logica.

Da's zelfs een understatement, zat toevallig een aantal weken geleden de beschikbare documentatie van de nic te "lezen".. wel niet echt lezen want dat is dus echt teveel tekst om te lezen zonder specifieke redenen.
Maar voor de liefhebber:
http://www.intel.com/content/www/us/...datasheet.html
Het zijn maar 490 pagina's. (met gelukkig een behoorlijk goede inhoudsopgave)

Follow-up van C't:

http://www.heise.de/security/meldung...m-1799964.html

Het zou alleen voorkomen bij bordjes van Lex Computech.