On Sat, Mar 04, 2006 at 08:00:17AM -0800, Dmitriy wrote:
> Looking at my tcpdump output above, it looks like the new connection
> uses port 1019, while the old connection used 1020. So that shouldn't
> be a problem.
In your output, there is no indication whether port 1019 was previously
used, but if it was (like 30s before you started the capturing), that
might explain the problem.
Can you repeat the procedure (providing the same tcpdump on int/ext you
did before, which is helpful) and also
a) enable debug logging (pfctl -xm) before, and check
/var/log/messages for anything from pf afterwards
b) run pfctl -si before and after, and checking which counters
increase (especially the error counters)
c) run tcpdump -nvvvettti pflog0 for the entire duration of the test,
providing any output you get there
d) run pfctl -vvss right when you see the first couple of SYNs
blocked, providing any entries that are related to the SYN
being blocked (matching source/destination address/port)
What we're looking for is whether pf has an (old or concurrent) state
entry matching the new SYN. If it does, it won't be able to insert a new
state for the same source/destination address/port pairs until the old
one is removed after it times out.
Daniel
