Network engineer Kristian Kielhofner (Kristian Kielhofner), having bought new servers to handle VoIP-traffic,
faced an unpleasant problem . Servers periodically crashed for no apparent reason. But the strangest thing is that the Ethernet controller was sometimes turned off on the servers. It turned off in the literal sense: the system worked normally for a while, but after processing a certain amount of traffic, the interface produced a hardware error and disconnected the connection, and restoring work was possible only after a cold reboot.
Christian did a little research and
found a number of reports that other users also have problems with the Intel 82574L controllers, saying that they have bugs in the EEPROM, ASPM, etc. Christian and his colleagues spent several months searching for the reasons why in their case the controllers gave an error. In the end, they managed to get to the bottom of it.
The engineer began to investigate using Wireshark the contents of the packets that passed through the network card just before the interface was turned off - and found some regularity. The last packet was always the
100 Trying response via the SIP protocol, it was always of a certain length and always arrived after an
INVITE request from a specific manufacturer of IP phones.
Christian says that on Friday evening he raised specialists from the company that sold him the phones of this brand. He provided them with evidence and demanded an answer. They all gathered together to check the bug, made a test configuration on different servers and different phone models - and were able to reproduce it! True, the bug did not appear on all models of servers and phones. After a long analysis, in the end, still managed to identify a specific packet, because of which the Ethernet interface was falling. This turned out to be an INVITE, not 100 Trying.
')
To check, they took the
tcpreplay program, isolated INVITE from the phone - and sent this packet to a network card. The trick worked.
Everyone can test the “death packet” on their Intel network card by installing a virtual machine and sending a packet from there using tcpreplay, or you can do it from another computer over a local network. The “death pack” works under any OS, regardless of the firewall settings, unless the firewall blocks at the OSI 2/3 level.
Package ContentsBy the way, Christian brought the analysis to a logical conclusion and found out which specific bytes turn any packet into a “death packet” for an Intel Ethernet card.
The interface is disabled if the value 2 or 3 is found at 0x47f.
Byte 0x47f = 32 HEX (2 ASCII)
Byte 0x47f = 33 HEX (3 ASCII)

If there is 4, then everything is OK.

Any package is suitable: HTTP POST, ICMP echo-request, and so on. for example, on the web server, you can configure response 200 so that it will “kill” network interfaces on client machines.
Christian Kilhofner says he’s been involved in networking for 15 years and has never seen anything like it. He has already contacted Intel engineers, and they confirmed that this is indeed a bug in the EEPROM firmware on the 82574L controllers.
UPD 09.02. Intel
put forward a version that the problem is limited to one of the motherboard manufacturers who recorded the wrong EEPROM image during the manufacturing process. The name of the manufacturer is not reported.