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

IPhone Resets Mid Transfer

0

Hello,

My ability to analyze a capture is limited. So, any help is appreciated.

I have a server that is trying to send a .m4v (video) file to an IPhone. It looks to me, like the phone is resetting the connection before the transfer takes place. If that is true, the question is why is it resetting?

Here is a copy of my capture file.
capture

My Nexus 5 receives the same file without any issues. I hope that the trimmed down capture image contains enough information. I had to trim it down to fit in this message.

Thanks,

Dana

asked 21 Mar '14, 12:29

danabaillie's gravatar image

danabaillie
16114
accept rate: 0%


2 Answers:

1

The client software decided to close the socket and terminate the transfer prematurely after having read (and inspected) the first 1658 (FIN's ACK#-1) bytes of the m4v file. So you need to ask this question to the client software community (itunes, safari, etc...) to get a more appropriate answer.

answered 22 Mar '14, 05:08

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

edited 23 Mar '14, 01:55

Ok. I disabled "Allow subdissector to reassemble TCP streams" and reran the attempt to open the .m4v file in my IPhone. I realized later that I could have used my existing capture and simply disable " "Allow subdissector to reassemble TCP streams" without recreating a capture. I learn slowly.

Anyway, it now does show the "200 OK". Not seeing that was adding confusion for me.

I read your response, mrEEde. I suspect that what you said is probably all that the capture file can tell us, so I will reach out to some IOS (Apple) sites.

Here is the updated capture file, just in case there is something new or missed.

capture file

(22 Mar '14, 08:11) danabaillie
1

@mrEEde The client received 1658 bytes before closing the connection.

(22 Mar '14, 17:12) Roland

1

205 is the client, 199 the server. Client is requesting the .m4v file in packet 14.

Please disable "Allow subdissector to reassemble TCP streams" to see if you get a 200 OK for the request.

Client closes the connection in packet 20. The RST in packet 23 is because the port is already closed.

answered 21 Mar '14, 15:49

Roland's gravatar image

Roland
7642415
accept rate: 13%

Ahhh. Thanks Roland. I know for a fact that the server is sending a 200 OK, but not seeing it in the capture had me thinking that it was shut down prematurely for some reason. I do as you suggest and let you know what I get.

Maybe, it's not as bad as I thought.

Thanks again.

Dana

(21 Mar '14, 15:56) danabaillie