3 ms·
My servers all have the affected cards (two per machine - yikes!) but so far I can't reproduce the bug (yay). There are subtle differences between the offsets
by corford 14y ago
My servers all have the affected cards (two per machine - yikes!) but so far I can't reproduce the bug (yay).
There are subtle differences between the offsets I get when I run "ethtool -e interface" versus those in the article that indicate an affected card (but they're quite close).
Mine are:
0x0010: ff ff ff ff 6b 02 69 83 43 10 d3 10 ff ff 58 a5
0x0030: c9 6c 50 31 3e 07 0b 46 84 2d 40 01 00 f0 06 07
0x0060: 00 01 00 40 48 13 13 40 ff ff ff ff ff ff ff ff
Output of "ethtool -i interface" (in case anyone wants to compare notes):
driver: e1000e
version: 1.5.1-k
firmware-version: 1.8-0
I tested both packet replays by broadcasting to all attached devices on a simple Gbit switch and no links dropped.
- mrb 14y agoYou need to shut down, boot up the server, and do a test right away. The very first packet of 1152 bytes or more that it receives after a cold boot determines if the NIC is going to be affected or "inoculated" (until next cold boot).
- corford 14y agoThanks mrb, I missed that a cold power up was needed. I'm going to try again now but it's a bit tricky as the affected machines are in a different country and I don't have access to full remote power cycling (I can only reset the machines). Hopefully, the data centre staff will be accommodating (after all, if my machines are affected, likely hundreds of their other clients are too as I'm using dedicated servers provided by them). EDIT: it's difficult to tell definitively doing it remotely but I still can't re-produce the bug after a cold boot.