This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Http response

0

I see some HTTP response that are occasionally being decoded by wireshark as TCP segments, as opposed to HTTP Response OK's. The total response spans approx 300 packets (450KBytes). Would such a large response hinder Wiresharks ability to decode/reassemble properly ?? If so, what is the limit ?

If not, what is the likely reason for such behavior ??

thanks, wk

asked 13 Mar '12, 12:52

wakelt's gravatar image

wakelt
13●10●10●13
accept rate: 0%

edited 13 Mar '12, 14:22

grahamb's gravatar image

grahamb ♦
19.8k●3●30●206

One Answer:

0

Check out if there are any TCP retransmissions, out-of-order packets, or other "oddities" in the TCP sequence that has the HTTP response. Wireshark frequently has trouble with those; see for example bug 4715.

(Of course any holes the TCP stream would also cause a problem.)

One thing you can try is to ignore (Edit->Ignore Packet) the troublesome TCP packets.

[If this answers your question, don't forget to stop by and Accept the answer.]

answered 13 Mar '12, 15:03

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k●5●72
accept rate: 27%

Thanks Jeff..I'll take a look at the capture in the morning.

Assuming it has something to do with retransmissions, is there a way to tell wireshark to ignore ALL retransmitted packets so that the HTTP response can be properly reassembled ??

I realize that if packets are out-of-order, I may be out of luck :-)

Is there a api somewhere that I could use to write a dissector for wireshark that takes into consideration these type of network events ?? Or is there an existing tool I can feed the cap file into that does the reassembly even under these circumstances ?

thanks again, wk

(13 Mar '12, 15:27) wakelt

[I converted your Answer into a Comment--please see the FAQ.]

To ignore all the retransmissions, you'd probably have to filter out all the retransmissions (tcp.analysis.retransmission) and then ignore each packet.

Out-of-order packets would be a lot more work; I think technically 'editcap' can move packets around, but that would be a pain.

I'm not aware of another tool that would do it better, but I don't generally work with TCP much, so I wouldn't know. The bugs exist to make Wireshark do it better, but there are a lot of bugs and not so many developers and time...

(13 Mar '12, 18:17) JeffMorriss ♦