Fwd: Re: pf: BAD state happens often with portsnap fetch update
Adam McDougall
mcdouga9 at egr.msu.edu
Thu Dec 14 09:40:18 PST 2006
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.
More information about the freebsd-current
mailing list