3 ms·

I have mixed feelings about the write up. I think it gets clear pretty early on that the issue is in the NIC hardware at which point it is time to stop wasting

by meshko 14y ago

I have mixed feelings about the write up. I think it gets clear pretty early on that the issue is in the NIC hardware at which point it is time to stop wasting your time investigating problem you can't fix and start contacting the vendor.

jerdfelt 14y ago
In my experience dealing with a similar bug (see my other post in the thread), the vendors will immediately assume it's not their problem. They spent a long time "showing" us that a different version of the Linux kernel didn't exhibit the problem so it must be a Linux kernel bug. Turned out the different version just sent data differently so it didn't trigger the same bug with the same data. Other data would have triggered it. I wouldn't be surprised if the majority of "bugs" they receive reports on turn out to not be bugs in their hardware. There's probably parallels with the reports of compiler bugs, most end up not being bugs in the compiler. The unfortunate truth is that responsibility of proving it's the vendors bug falls on the customer. I had to write a proof-of-concept "exploit" to show the problem was with their hardware, effectively troubleshooting most of the problem for them.
- homosaur 14y ago
  THIS. It's always someone else's testing procedures, someone's else's hardware... The thing is though, most of the time it is. Tech support at the lower levels especially are used to dealing with people who have bad configurations are are using the products incorrectly. The annoyance comes in when you as a customer narrow a problem down but can't get anyone on the phone who can help you at that level.
EvanAnderson 14y ago
The write-up gave me the feeling that the OP did just that. My experience has been that manufacturers will blow you off unless you can provide a reproducible test case. Certainly, his company doesn't sound like it has the volume necessary to threaten Intel w/ moving to a different NIC manufacturer unless the problem is resolved. With that in mind, I think the amount of work he did was just the right amount.
vacri 14y ago
"Closed: Works for me"

by meshko 14y ago

jerdfelt 14y ago

In my experience dealing with a similar bug (see my other post in the thread), the vendors will immediately assume it's not their problem. They spent a long time "showing" us that a different version of the Linux kernel didn't exhibit the problem so it must be a Linux kernel bug. Turned out the different version just sent data differently so it didn't trigger the same bug with the same data. Other data would have triggered it. I wouldn't be surprised if the majority of "bugs" they receive reports on turn out to not be bugs in their hardware. There's probably parallels with the reports of compiler bugs, most end up not being bugs in the compiler. The unfortunate truth is that responsibility of proving it's the vendors bug falls on the customer. I had to write a proof-of-concept "exploit" to show the problem was with their hardware, effectively troubleshooting most of the problem for them.

homosaur 14y ago
THIS. It's always someone else's testing procedures, someone's else's hardware... The thing is though, most of the time it is. Tech support at the lower levels especially are used to dealing with people who have bad configurations are are using the products incorrectly. The annoyance comes in when you as a customer narrow a problem down but can't get anyone on the phone who can help you at that level.

EvanAnderson 14y ago

The write-up gave me the feeling that the OP did just that. My experience has been that manufacturers will blow you off unless you can provide a reproducible test case. Certainly, his company doesn't sound like it has the volume necessary to threaten Intel w/ moving to a different NIC manufacturer unless the problem is resolved. With that in mind, I think the amount of work he did was just the right amount.

vacri 14y ago

"Closed: Works for me"