I'm investigating some strange error on OS X. When I'm sending multiple HTTP request to one host. One of the HTTP request sent in the middle receives an error "Error Domain=NSURLErrorDomain Code=-1004 "Could not connect to the server."". I've limited connection per host to 1. I've noticed that this error appears when number of connection per host is lower than number of HTTP requests sent in single time. I can see this issue only with some servers. Now I need verify that this issue is caused by Apple library not by actual error in network traffic. When I'm looking on thing which Wireshark captured everything looks fine to me. I'm not very good with TCP protocol so my question is what shall I see in Wireshark when I have this kind of errors. I used filter: So what kind of TCP packet should I see if connection to server can't be established? asked 13 Aug '16, 00:57  Marek R |
One Answer:
You should see connections with just a SYN packet, or a SYN packet with an Reset packet coming back in as a response. Easiest way to find those is by using the Statistics menu, and choosing "Conversations". Select the TCP tab, and check if you see any connection to the server IP that has less than 4 packets (SYN packets are often resend to retry). If you find one, use the popup menu to filter on it "A<->B", meaning both directions. My guess is that your problem is not an error at all - if you limit connections per host to 1 (or, as you say, less than HTTP requests) there's going to be a problem. I don't know OS X, so I guess this is some kind of firewall setting. If a web page needs n requests to pull all page content, and you set the limit to n-1, the kernel will stop at n-1 and not make the final connection at all. If you set the limit to 1, only one connection will be made. At least that's what I experience on my firewall. Keep in mind that, depending on the target server, HTTP may be forced to open multiple TCP connections to pull all content. This happens when the HTTP server is either using HTTP/1.0 or if it refuses the "connection: keep alive" option and tears down the connection. If you limit your TCP connections per host to 1 (or anything less than the number of required connections), you're in trouble. It will only work for hosts that can keep a TCP connection open to pull the remaining content. answered 13 Aug '16, 06:00  Jasper ♦♦ |
so if I use filer:
ip.addr == <server ip> && tcp.flags.reset == 1I should be able localize all occurrences of this error? If this filter is Ok than this must be a bug inNSURLSession. Conversation view doesn't show any errors, every entry for each "Port A" has at least 4 packets.The conversations view will show you the individual sessions as individual lines at the TCP tab, as each of the TCP sessions from the same client to the same server uses a different ephemeral port (the dynamically assigned one at client side). Use a display filter
ip.addr == <server ip>in the main window and tick the "limit to display filter" in the conversations window.The way how the session is rejected outside your machine (if it is) may vary:
if the error is reported immediately, you should see packets with
tcp.flags.reset == 1 or tcp.flags.fin == 1if it is rejected by something outside your machine.if it takes many tens of seconds, you should see several repetitions of a SYN packet (
tcp.flags.syn == 1) from the same ephemeral port, but no response to any of them. But as you say everything is "green", I do not expect any SYN retransmissions.