Vendor Communication Frustrations

It's common for me to find firmware bugs on vendor hardware that interacts poorly with software written in house.  My assumption is that vendors sell their software as a "value add", only test their hardware with their software, and have limited care for third party software.  Once in awhile the vendor fixes hardware issues in their software, so the issue is technically in the third party software, but it's not the third party's fault.

When I report a bug in the firmware, it's common for a vendor to respond with something akin to, "It works for our software, it must be your software."  It's a normal, yet frustrating, response.  In addition, to get the problem resolved often means getting through layers of support before reaching an engineer that understands the situation.

Over time, I've come up with a few mechanisms to handle this type of issue with vendors more quickly.  Here are some of them:

A) Add packet dumps or equivalently "advanced" debug information in the ticket.

I'll add information to the bug that is reasonably complex or difficult to understand.  The common example is something similar to a TCP packet dump.  I add something in the ticket with arrows (e.g. "See here --->") and something like "this 0x8 should be an 0x5".

Due to the complexity of the information, the ticket is typically passed up the food chain more quickly.  In addition, it sometimes does not matter what software was running to generate the TCP packet dump.  I can just say it was their software, they would never know.

Ironically, I sometimes have nicer/better debugging information (or even the flat out solution) I could put in the ticket.  However, I often elect to put the more confusing information in the ticket b/c it ultimately resolves the problem more quickly.

B) Be very specific in your requests

It's better to ask for very clear specific information.  A normal request might go like this: "I noticed an OEM piece of information on your motherboard.  Can you please describe what this means?"

While this is a perfectly reasonable request, it leads to the wrong answers.  A common answer might be, "Use our software X, it can show you all the information", which is of course not a useful response.  Or you might get "That information means FOO, you need to do BAR for your system", which might be true, but isn't what we're really looking for.

It's better to be very specific with your request, for example  "I noticed the following OEM piece of information: 0x20 0x18 0xA2.  What is the mapping of OEM hex to English.  0x20 = ???, 0x18 = ???, 0xA2 = ???."

C) Site standards/specifications that can't be challenged

I'll site standards/specifications, making it clear that if they wish to counter my claim, they will have to know what they are talking about and prove it to me.

For example, I might write, "Please see the following packet dump.  Clearly the X field violates section 1.2.A of the specification, second paragraph, third sentence."

This type of statement is so specific and advanced, it will typically skip lower support levels.