Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Seeing multiple responses but only one request

Hello,

If there is a better place to ask this question, I apologize. I'm experiencing a very concerning problem that I'm hoping someone more knowledgeable in web protocols may be able to help with. Unfortunately, I cannot share complete .pcapng files because they contain sensitive information. I tried to sanitize them with TraceWrangler, but I think because I needed to decrypt the 802.11 packets with an SSID and password to even view them in Wireshark, TraceWrangler is unable to modify them. Anyway, I digress...

The general scenario is that we have devices in the field that call an endpoint periodically, and by periodically I mean every time they want to connect to any of our services. Recently, we began seeing a spike in failures/retries coming from our devices using this service, and upon further investigation, we've narrowed down the problem to a non-compliant http request. The request the device was making contained a trailing CRLF in its headers. Removing that stops the unexpected behavior from ever occurring.

So, problem solved, right? Well, this specific application hasn't changed in years, and because this is new behavior, management wants a more detailed explanation of the problem, specifically the intermittent nature of it. I do not understand enough to give that to them, this is where I am looking for some help.

Here is what I can provide of the Wireshark capture: https://ibb.co/Jdh1mt5

On the left side, you can see that the response contains the expected 200 and payload, but another 400 response is appended directly to the end of the response.

Fortunately, the device will instantly retry in this scenario, and continue to do so until it receives a response it understands.

On the right, which begins before the last stream ends, the device retries again and the service returns a 200 without the appended 400.

I've exported both of these requests and diff checked them, I see almost nothing different between them worth noting. The one thing I did find is that in the request that results in the double response, Wireshark shows it is Http Request 1/2. However, the 2nd part of the request doesn't appear in Wireshark. https://ibb.co/8BgfQSB

The request which gets a response without the trailing 400 is shown as [Http Request 1/1] in Wireshark. The size of these requests is identical, so it doesn't appear at first glance that anything at all is different between them.

I'm wondering now if there's anything useful to be gleamed out of the TCP traffic during these streams. My understanding of TCP behavior is surface-level at best. I've done some reading very recently, but maybe someone here may be able to expediate my understanding of the information I need to know. Is it possible there is any answer to this intermittent behavior within these TCP exchanges?

Thank you in advance.

Seeing multiple responses but only one request

Hello,

If there is a better place to ask this question, I apologize. I'm experiencing a very concerning problem that I'm hoping someone more knowledgeable in web protocols may be able to help with. Unfortunately, I cannot share complete .pcapng files because they contain sensitive information. I tried to sanitize them with TraceWrangler, but I think because I needed to decrypt the 802.11 packets with an SSID and password to even view them in Wireshark, TraceWrangler is unable to modify them. Anyway, I digress...

The general scenario is that we have devices in the field that call an endpoint periodically, and by periodically I mean every time they want to connect to any of our services. Recently, we began seeing a spike in failures/retries coming from our devices using this service, and upon further investigation, we've narrowed down the problem to a non-compliant http request. The request the device was making contained a trailing CRLF in its headers. Removing that stops the unexpected behavior from ever occurring.

So, problem solved, right? Well, this specific application hasn't changed in years, and because this is new behavior, management wants a more detailed explanation of the problem, specifically the intermittent nature of it. I do not understand enough to give that to them, this is where I am looking for some help.

Here is what I can provide of the Wireshark capture: https://ibb.co/Jdh1mt5

On the left side, you can see that the response contains the expected 200 and payload, but another 400 response is appended directly to the end of the response.

Fortunately, the device will instantly retry in this scenario, and continue to do so until it receives a response it understands.

On the right, which begins before the last stream ends, the device retries again and the service returns a 200 without the appended 400.

I've exported both of these requests and diff checked them, I see almost nothing different between them worth noting. The one thing I did find is that in the request that results in the double response, Wireshark shows it is Http Request 1/2. However, the 2nd part of the request doesn't appear in Wireshark. https://ibb.co/8BgfQSB

The request which gets a response without the trailing 400 is shown as [Http Request 1/1] in Wireshark. The size of these requests is identical, so it doesn't appear at first glance that anything at all is different between them.

I'm wondering now if there's anything useful to be gleamed gleaned out of the TCP traffic during these streams. My understanding of TCP behavior is surface-level at best. I've done some reading very recently, but maybe someone here may be able to expediate my understanding of the information I need to know. Is it possible there is any answer to this intermittent behavior within these TCP exchanges?

Thank you in advance.

Seeing multiple responses but only one request

Hello,

If there is a better place to ask this question, I apologize. I'm experiencing a very concerning problem that I'm hoping someone more knowledgeable in web protocols may be able to help with. Unfortunately, I cannot share complete .pcapng files because they contain sensitive information. I tried to sanitize them with TraceWrangler, but I think because I needed to decrypt the 802.11 packets with an SSID and password to even view them in Wireshark, TraceWrangler is unable to modify them. Anyway, I digress...

The general scenario is that we have devices in the field that call an endpoint periodically, and by periodically I mean every time they want to connect to any of our services. Recently, we began seeing a spike in failures/retries coming from our devices using this service, and upon further investigation, we've narrowed down the problem to a non-compliant http request. The request the device was making contained a trailing CRLF in its headers. Removing that stops the unexpected behavior from ever occurring.

So, problem solved, right? Well, this specific application hasn't changed in years, and because this is new behavior, management wants a more detailed explanation of the problem, specifically the intermittent nature of it. I do not understand enough to give that to them, this is where I am looking for some help.

Here is what I can provide of the Wireshark capture: https://ibb.co/Jdh1mt5capture:

On the left side, you can see that the response contains the expected 200 and payload, but another 400 response is appended directly to the end of the response.

Fortunately, the device will instantly retry in this scenario, and continue to do so until it receives a response it understands.

On the right, which begins before the last stream ends, the device retries again and the service returns a 200 without the appended 400.

I've exported both of these requests and diff checked them, I see almost nothing different between them worth noting. The one thing I did find is that in the request that results in the double response, Wireshark shows it is Http Request 1/2. However, the 2nd part of the request doesn't appear in Wireshark. https://ibb.co/8BgfQSBWireshark:

The request which gets a response without the trailing 400 is shown as [Http Request 1/1] in Wireshark. The size of these requests is identical, so it doesn't appear at first glance that anything at all is different between them.

I'm wondering now if there's anything useful to be gleaned out of the TCP traffic during these streams. My understanding of TCP behavior is surface-level at best. I've done some reading very recently, but maybe someone here may be able to expediate my understanding of the information I need to know. Is it possible there is any answer to this intermittent behavior within these TCP exchanges?

Thank you in advance.