I have a problem emerge recently with one specific service that I use - I currently can not "sync" the application from my MacBook on my home network as it seems to time out. When I connect my MacBook to another internet connection connection (e.g. my travel USB dongle with internet connection) it sync's up fine straight away. So it seems to indicate a problem with my network (or ISP network). However I don't seem to have problems with any other web site - well there are some web sites that seem to require hitting links a second time etc, but I think (?) this could be consider normal. Anyway the screen capture from an example when I run the application up and it tried to sync is below. The display filter was set to show only lines from these two IP addresses.
Does this tell us anything? Things I wonder about are:
============================================================== EDIT - ADDED A CAPTURE FROM MY ROUTER BOX I'm replacing the previous router captures with ones with increase capture size - here they are below. Any ideas about the "Illegal Segments" that are being highlighted? This is from the far end server to me, so does this imply an error at their end or my end? Router server capture
Packet Details 1
Packet Details 2
asked 07 May '11, 01:28  mixedup edited 08 May '11, 02:53 |
click on link to go to full size - 
One Answer:
The "Unknown Record" might be caused by a combination of your TCP and SSL protocol settings, but looking at the rest of the conversation, it's an issue in the way the packets are displayed and not an issue in the communication. The "Encrypted Alert" from your MacBook, is just it's way of telling the server that it wants to close down the connection (at the SSL level). The reason why it is closing the connection is most likely a timeout at the "Encrypted Alert" comes exactly 60 seconds after your MacBook has sent data to the server without getting any data back (just an ACK). Then the "Previous Segment Lost" in the FIN/ACK from the server shows that it did send data between the ACK in frame 63 (seq=3106) and the FIN/ACK in frame 232 (seq=3335). However, that data was not received by your MacBook (at least it's not in the trace). As your MacBook did not get that data, it sends a duplicate ACK telling the server that the last data that was received was up to seq 3106 and not 3335. So, the big question is why does the server not respond to your request in frame 61/62? Or when it did respond, why did the packet never arrive at your MacBook, which makes the Application drop the connection after 60 seconds. A trace on the server side (or further along the line towards the server) might give an answer to that question. answered 07 May '11, 02:18  SYN-bit ♦♦ showing 5 of 6 show 1 more comments |
thanks SYNbit - may be problematics asking the service provider for the trace, but I could try. Before that I'm wondering if there is a trace I could run at my router that might assist? I'm run ClearOS 5.2 (a linux based firewall/nat/etc package)...
You might want to run 'tcpdump' on the ClearOS router while also capturing on your MacBook to see whether the ClearOS router alters the traffic in any way.
You can also compare the traces of a good session (on another network) and this one to see the differences. That might also tell you something.
Other than that I guess it's mostly out of your control and you rely on the support of your ISP.
hi SYNbit - I've managed to add some additional interesting info which I just added to the poast - did a capture from my router server - I'd be interested in your comments?
PS. I've updated the server side capture (fixed the initial post where tcpdump wasn't capturing enough of the packets). Any ideas about the "Illegal Segments" that are being highlighted? This is from the far end server to me, so does this imply an error at their end or my end?
Can you post the capture of the MacBook and the Router (both made at the same time)? It's not easy (if at all possible) to analyze this based on images. If you want, you can also send them directly to me (email is in my profile).
@SYNbit - just realised I hadn't sent you the captures yet - have done so now - any insights welcome :)