seeing a weird issue when trying to access a webserver 10.100.20.175 from my local PC 10.100.21.157 as you can see from the packet capture everything looks normal till no 9 , after which i start seeing a whole bunch of arp requests and the webpage on 10.100.20.175 never loads asked 15 Oct '14, 08:01  tmkunte edited 20 Oct '14, 03:03  JeffMorriss ♦ |
One Answer:
Well, that's no broadcast storm for sure: look at the amount of time that passes between frames. Broadcast storms are thousands of packets per second (or at least hundreds). What you've got there looks pretty normal. Is the problem consistent? Do you always get the lost segment at the beginning? For some reason one of the segments from the web server is missing and it doesn't appear to retransmit it (or at least Wireshark doesn't see the retransmission). I suppose it's possible the TCP stack over there is broken but I'd think it's more likely some firewall software or something is interfering. answered 20 Oct '14, 03:02 JeffMorriss ♦ |
its the same issue everytime.
another thing that was puzzling was no 19
why would the source 10.100.21.157 do an ARP request for the destination 10.100.20.175 when traffic is already flowing between the 2 ?
Maybe the server has a problem where it can't send the big packet (at least I'm guessing the missing packet is a big one. And doesn't retransmit. I'd guess the problem is on the server side.
ARP entries expire--even when there's traffic flowing (at least that's my experience).
The ARP in packet 19 isn't a broadcast, but a unicast arp (that is, a refresh rather than a discover). This is all normal.
I think the most you can tell from that trace is that the client sends the GET message and the response isn't fully received by the client after that. I'd next want to trace at the server, and from there the question becomes why the server didn't fully respond to the GET (or, if it did, in which case what happened to the packets between the server and the client).