Date: Thu, 14 Dec 2006 12:23:23 -0500 From: Adam McDougall <mcdouga9@egr.msu.edu> To: Colin Percival <cperciva@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update Message-ID: <20061214172323.GP1011@egr.msu.edu> In-Reply-To: <457B7084.9070409@freebsd.org> References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org> <20061210014924.GU81923@egr.msu.edu> <457B7084.9070409@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 09, 2006 at 06:27:16PM -0800, Colin Percival wrote: Adam McDougall wrote: > I just tested tcp.closed with 3 seconds, down from 15 earlier but both were > unsuccessful. I will look at the other options as well, but do you have any explanation > for why portsnap would use wildly randomish local ports that overlap too quickly > when fetch does not? Is that a kernel controlled behavior that I can adjust? Try setting net.inet.ip.portrange.randomized=0. This shouldn't make any difference, but it might. Colin Percival Actually that did work, I thought I had tried it before but maybe not. What I've found is when randomized=1, portsnap will use random ports for the first portion of connections: # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... using portsnap1.FreeBSD.org. Fetching snapshot tag... done. Fetching snapshot metadata... done. Updating from Sat Mar 25 06:58:08 EST 2006 to Thu Dec 14 09:39:43 EST 2006. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 4 metadata files... done. Then regardless of randomized=0 or 1, the next part will use sequential local port allocations which are likely to conflict with the previous batch of connections: Fetching 8765 patches.....10....20....3(etc) When I have randomized=0, the first portion uses sequential ports and after several runs of re-downloading the same 8765 patches, it seems to work fine every time. I made a backup copy of /var/db/portsnap so I could repeat the fetch over and over for testing. Any idea why portsnap uses sequential ports foe the Fetching stage when the kernel has randomized=1? I am pleased that the workaround functions, but it would be nice to understand if something needs to be fixed so I don't need it.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061214172323.GP1011>