b4e7a303   
   From: ndav1@cox.net   
      
   sgifford@suspectclass.com wrote:   
   > On Jan 28, 9:28 pm, Barry Margolin  wrote:   
   >> In article   
   >> <26782998-9070-47dd-a23f-52cf3b276...@g39g2000pri.googlegroups.com>,   
   >>   
   >>  "sgiff...@suspectclass.com"  wrote:   
   >>> Hello,   
   >>> I'm having a weird problem accepting a TCP connection on my Linux Web   
   >>> server from a Blackberry client.  Linux server is kernel   
   >>> 2.6.18-1.2798.fc6 from Fedora Core 6.  The initial SYN packet from the   
   >>> client arrives as I expect.  The server then sends its SYN/ACK and the   
   >>> client sends the final ACK in the 3-way handshake, again as I expect.   
   >>> But after that, the server keeps retransmitting its SYN/ACK, and the   
   >>> client continues to respond with an ACK.  It's as if the server isn't   
   >>> accepting the ACK from the client, but I can't figure out why.  After   
   >>> awhile the client starts to send data, and is sent a RST in response.   
   >>> Here is the packet trace from tcpdump:   
   >> This is the behavior you'd see if the server never receives the ACK.   
   >>   
   >> Which machine did you run tcpdump on, the client or the server?  If you   
   >> ran it on the client, try again on the server and see whether it   
   >> receives the ACK packets.   
   >   
   > Thanks for the reply Barry.   
   >   
   > I was running tcpdump on the server, so I can see that the ACK is   
   > arriving at the server.  And I'm inferring that the client is   
   > receiving the SYN/ACK because it's sending the ACK.   
   >   
   > -----Scott.   
   >   
      
   First could the sequence number for the client's ACK be incorrect?   
   You'll need to dump the entire packet to see it. Second, could iptables   
   or some other firewall be strangely configured?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)