On 2011-07-12, Jiri B <ji...@wolfman.devio.us> wrote: > Hello, > > with latest snapshot (Jul 11 2011) I see this strange behavior > which I haven't seen before upgrade (ping caught by strange pf > rule).
You have important information which you didn't include: the date when it last worked. Ideally read through the commits from between then and now (there are git imports of the openbsd tree with web interfaces at anoncvs.estpak.ee and git.freebsd.your.org/cgit which may be easier than reading source-changes) and try and track down which commit/s seem likely candidates. Then try building (in this case at least make includes and build a new kernel+pfctl) with the tree from before/after those times (or just bisect if nothing stands out) to track down what caused it. > > $ id ;netstat -rnf inet | grep default > uid=1000(jirib) gid=10(users) groups=10(users), 0(wheel), 5(operator) > default 192.168.1.1 UGS 6 1320 - 12 iwn0 > > $ ping 192.168.1.1 > PING 192.168.1.1 (192.168.1.1): 56 data bytes > ping: sendto: No route to host > ping: wrote 192.168.1.1 64 chars, ret=-1 > --- 192.168.1.1 ping statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > > OK, why? It was caught by pf: > > # tcpdump -i pflog0 -n -ttt -e icmp > tcpdump: WARNING: snaplen raised from 116 to 160 > > tcpdump: listening on pflog0, link-type PFLOG > Jul 12 17:43:00.412525 rule 9/(match) block out on iwn0: 192.168.1.254 > > 192.168.1.1: icmp: echo request > > Interesting... what is that rule? > > # pfctl -R 9 -vv -sr > @9 block return out log all user = 1002 > [ Evaluations: 275 Packets: 23 Bytes: 1912 States: 0 > ] > [ Inserted: uid 0 pid 30333 State Creations: 0 ] > > So, why was ping caught by rule which should apply only to > uid = 1002? FYI, the ping is caught for root as well? > > Am i doing something wrong or I haven't seen some info for > -current followers? > > jirib
