Re: Problem with a 5.2.1 system and downloading

From: Ulf Zimmermann (ulf_at_Alameda.net)
Date: 05/20/04

  • Next message: David Schultz: "Re: copyin() EFAULT" 
    Date: Thu, 20 May 2004 13:18:03 -0700
To: Dan Nelson <dnelson@allantgroup.com>

    On Thu, May 20, 2004 at 02:59:24PM -0500, Dan Nelson wrote:
    > In the last episode (May 20), Ulf Zimmermann said:
    > > I got in my office two machines. One works fine, the other doesn't.
    > > Office has a Netscreen-10 as firewall which connects then to a Cisco
    > > with a T1 Frame Relay to the Internet.
    > >
    > > One machine is 4.9-REL and it works like a charm. The other is a
    > > 5.2.1-REL (cvsup'ed to latest today). It has a single CPU, PAE kernel
    > > (6GB memory). This 5 machine hangs often at different spots during
    > > fetch for ports.
    > >
    > > Today I captured the tcp connections and here is what it shows:
    > >
    > > Initial TCP setup:
    > >
    > > 12:26:25.895246 10.1.42.42.49190 > 128.125.253.59.80: S 3565497776:3565497776(0) win 65535 <mss 1460,nop,wscale 1,nop,nop,timestamp 88945 0> (DF)
    > > 12:26:25.919572 128.125.253.59.80 > 10.1.42.42.49190: S 1889662716:1889662716(0) ack 3565497777 win 5840 <mss 1460,nop,wscale 0> (DF)
    > > 12:26:25.919592 10.1.42.42.49190 > 128.125.253.59.80: . ack 1 win 32850 (DF)
    > >
    > > Here are the last 4 packets back and forth going correctly:
    > >
    > > 12:26:29.052678 128.125.253.59.80 > 10.1.42.42.49190: . 487518:488978(1460) ack 194 win 5840 (DF)
    > > 12:26:29.052689 10.1.42.42.49190 > 128.125.253.59.80: . ack 424738 win 32850 (DF)
    > > 12:26:29.060577 128.125.253.59.80 > 10.1.42.42.49190: . 488978:490438(1460) ack 194 win 5840 (DF)
    > > 12:26:29.060589 10.1.42.42.49190 > 128.125.253.59.80: . ack 424738 win 32850 (DF)
    > >
    > > And now the last data packet comes in:
    > >
    > > 12:26:29.069061 128.125.253.59.80 > 10.1.42.42.49190: . 424738:426198(1460) ack 194 win 5840 (DF)
    > >
    > > And now look at the ack:
    > >
    > > 12:26:29.069087 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 0 (DF)
    > > 12:26:29.069250 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 1790 (DF)
    > > 12:26:29.069342 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 3326 (DF)
    >
    > Looks reasonable. Note the last two acks you pasted were acking data
    > pretty early in the window. The remote end finally resends that
    > packet, and your server bumps the ack point up to the last byte it
    > received. The client process hasn't had a change to empty the socket
    > buffer yet, though, so the window slams shut.
    >
    > > 12:26:29.069461 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 4862 (DF)
    > ...
    > > 12:26:29.070155 10.1.42.42.49190 > 128.125.253.59.80: . ack 490438 win 32510 (DF)
    >
    > The client process has read all its data and the window opens up. The
    > server isn't sending any more packets for some reason, though.
    >
    > > So does this look normal to anyone ?
    >
    > Your end looks fine. Once your system started sending acks with a
    > nonzero window, the remote end should have started sending more data.
    >
    > --
    > Dan Nelson
    > dnelson@allantgroup.com

    I only got the problems with sites where I go through the netscreen. Fetching
    the same files via the 4.9 box, everything works. Looking at the full dump,
    my 5 box never really has to catch up (most of the time its one data packet,
    one ack), which is why the change from "win 32850" to "win 0" (and then climbing)
    looks strange to me. 

    -- 
Regards, Ulf.
---------------------------------------------------------------------
Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204
You can find my resume at: http://seven.Alameda.net/~ulf/resume.html
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
  • Next message: David Schultz: "Re: copyin() EFAULT"

    Relevant Pages

    • TCP connections stuck in persist state
      ... I ran into a problem recently where a TCP socket seemed to never exit persist ... What would happen is that the sender was blasting data faster than the ... opened the window. ... e-mail to net@ for the source of duplicate ACKs.) ...
      (freebsd-net)
    • Re: Why did the FBI need a battering ram to get into the duplex (Jessie Davis cas
      ... but Justin Lindstrom said they ... Law enforcement agencies have policies on how to serve warrants. ... Your point about breaking a window fails to take into account the ... and there doesn't seem to have been any reason to suspect that any evidence ...
      (alt.true-crime)
    • Re: Creating a simple windows messaging app
      ... a broker app that receives packets from a canbus and pushes them out to ... each application thread a copy of the packet. ... consists of putting the message into a queue to be sent to the bus (no ... targeted at a specific window. ...
      (microsoft.public.vc.mfc)
    • Re: Fuzzy understanding of asynchronous method calls
      ... I used asynchronous methods was so I could pass in parameters. ... As for creating the window in the main thread, ... would imagine that calling Application.Run numerous times would be ... The reason for this is that it effectively takes a ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: Creating a simple windows messaging app
      ... each application thread a copy of the packet. ... appThread responds to: ... consists of putting the message into a queue to be sent to the bus (no ... targeted at a specific window. ...
      (microsoft.public.vc.mfc)