Weird problems with 'pf' (on both 5.x and 6.x)

It happens that I noticed two odd networking problems recently.
One of them is easily reproducible, and I have it tracked down
to one innocuous-looking line in my /etc/pf.conf. The other
is a problem in a chat server that I run, with a few hundred
people on it, and is much more of a hassle to reproduce. But
turning off 'pf' to solve the first problem seems to have
also solved the second problem, so I assume both problems
come from the same culprit.

Once I figured out how to reproduce the problem, it seems so
easy to reproduce that I find it odd that no one else has
run into it. But I also do not notice any PR's that seemed
to describe the problem. I'd appreciate it if people would
try to duplicate the problem on some other machines.

This problem has been seen on:
5.x-stable as built on Mon Jul 24
6.x-stable as built on Mon Jul 17
(as well as several earlier snapshots of both 5.x and 6.x).

I have a freebsd box which is the server for a print queue
named 'bill', and is running pf. I have other machines which
reference that queue. It seems that machines on the same
subnet as the server-box do not exhibit the problem. But
for other machines, if I do 'lpq -Pbill' twice in rapid
succession, then the second one will hang.

After some futzing around, I determined that if my pf.conf
has only the lines:

# Filtering: the implicit first two rules are
#pass in all
#pass out all

then I can do many many lpq's in a row, without any trouble.
But if I restart pf after adding these lines to pf.conf:

# Allow all outgoing tcp and udp connections and keep state
pass out quick proto { tcp, udp } all keep state

then I have the problem where the second 'lpq' from a remote
host will hang, if it is done right after the first one.
That's right. I add a rule which just does "quick passing"
for *outbound* connections, and somehow that screws up
(blocks?) *incoming* connections. I have no rules which
should block any packets at all, so my guess is that some
packets are getting lost, delayed, or corrupted somewhere.

--
Garance Alistair Drosehn = gad@xxxxxxxxxxxxxxxxxxxx
Senior Systems Programmer or gad@xxxxxxxxxxx
Rensselaer Polytechnic Institute or drosih@xxxxxxx
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • RE: vb6 usercontrol gives access violation when handling events
    ... It is odd that you can't reproduce the problem yet I can obtain the same ... runtimes and the machines here are used to maintain that application. ... The looping problem does not manifest itself on every run ... The nested user control access violation was found during testing of the ...
    (microsoft.public.vb.bugs)
  • Re: MFC MDI app hangs randomly on some machines, but not others (most are OK). Typical causes?
    ... If the problem is reproducible on the problematic machines, that is, the ... same file always hang on machine X, but not on Y and Z, you will probably ... old method of adding logging code to your app, ... > major Windows operating systems have failed to reproduce the bug. ...
    (microsoft.public.vc.mfc)
  • Re: Another very easy grid header question
    ... Thanks very much for your feedback. ... Actually, for your issue, I still did not find a way to reproduce out. ... this problem occur in other machines on your side? ... Thank you for your patience and cooperation. ...
    (microsoft.public.dotnet.framework.windowsforms.controls)
  • Re: FreeBSD 7.0: sockets stuck in CLOSED state...
    ... machines. ... This was with Apache servers in the proxy setup: ... reproduce the problem on my amd64, ...
    (freebsd-net)
  • Re: Stopping multiple connections
    ... I understand that WithEvents keyword will raise one more connections. ... I could not reproduce it on my machines. ...
    (microsoft.public.sqlserver.programming)