Am 28.07.2006 um 22:20 schrieb Garance A Drosihn:
At 9:30 PM +0200 7/28/06, Stefan Bethke wrote:
What I do find curious is that the client keeps using
port 1023 consistently. I was under the impression that
reusing the same port number (thus having the same
src-ip/port+dst-ip/port tuple) shouldn't work, because
"old" packets could arrive after the original connection
was closed; that's what the CLOSE_WAIT state in netstat is.
Hmm. Well, I did wait a few seconds between the two lpq's,
just so it would be easier tell them apart in the packet dumps.
Perhaps solaris is quicker to reuse ports, while 'pf'
remembers that src-ip/port+dst-ip/port tuple for a
longer stretch of time?
Thinking about it, it must be pf's notion of when to forget about a
closed TCP connection. lpq (in FreeBSD) is intent on using port
1023, tells the kernel it's OK to reuse it, and will try until it
gets it, with an exponential backoff and an upper limit on the number
of tries. I'd think the Solaris lpq does the same. Since the client
and server "know" it's OK, they can deal with the not-yet-expired
TIME_WAIT (by ignoring it). But pf obviously cannot know about it,
and will drop packets that are received during TIME_WAIT, including a
new SYN.
For this case in particular, you should be able to use a pair of
static rules (instead of keep state), since both source and
destination ports will always be the same. Something like
pass out quick proto tcp from $client 1023 to $server 515
pass in quick proto tcp from $server 515 to $client 1023
I'm not certain this is a bug in pf, maybe someone more knowledgeable
can explain how the TCP state machine in pf works.
Stefan
--
Stefan Bethke <[EMAIL PROTECTED]> Fon +49 170 346 0140
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
