Hi Andrej, 
     
    I'm having similar trouble telling a story around that. 
     
    As though Frame #3 had not arrived at the Server (85.17.148.76) ...
    if that were the case, then the trace would make more sense. 
    However, you say that you captured /on/ the Server ... so,
    minimally, libpcap saw Frame #3 ... I would expect the TCP stack to
    receive a copy as well. 
     
    (1) Does anyone know of circumstances under which libpcap acquires a
    copy of a frame while the TCP stack does not? 
     
    (2) Does the TCP stack report problems ( 'bad segments received')
    right after this experience? 
    linux> netstat -s 
    [...] 
    Tcp: 
        372 active connections openings 
        4509 passive connection openings 
        120 failed connection attempts 
        2 connection resets received 
        1 connections established 
        43095 segments received 
        33255 segments send out 
        0 segments retransmited 
        0 bad segments received. 
        120 resets sent 
     
    (3) Would you be willing to post a detailed view of Frames 1-3? 
     
    --sk 
     
     
    On 5/5/2012 10:00 PM, Andrej van der Zee wrote:
    
      Hi,
I am experiencing some weird behavior in the network traffic between a
mobile device and an Apache server 2.2 running on Linux (tried Ubuntu
and CentOS). See attachment for a packet capture on the server.
The client establishes a connection with the server in packet 1-3.
Then, for some unknown reason, the client does not send any HTTP
request. After 3 seconds, the server resends the SYN+ACK. I am trying
to understand what is going on here and why would TCP/IP resend the
SYN+ACK in packet 4?
Thanks,
Andrej
 
       
      
       
      ___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
     
  
 |