Re: kernel rebuild to debug problem
On 20/05/2024 00:03, Kirill A. Korinsky wrote: > On Sun, 19 May 2024 20:52:56 +0100, > Kapetanakis Giannis wrote: >> I'm trying to bisect a bug and compile an older kernel from cvs >> >> cvs checkout -D "2023-01-05" src/sys >> >> and following https://www.openbsd.org/faq/faq5.html#Options >> + make install >> >> New kernel compiles and boots but I get: >> >> # pfctl -f /etc/pf.conf >> pfctl: DIOCADDRULE: Operation not supported by device >> >> # pfctl -sr >> pfctl: Permission denied >> >> # pfctl -si | head -1 >> Status: Enabled for 0 days 00:05:03 Debug: err >> >> any ideas about this? >> > You need to build / use no only old kernel but the whole system. > > The simplest way is to use archived version of snapshots from > https://openbsd.cs.toronto.edu/archive/ or another mirror. Thanks for the reply. I did also build pfctl. Unfortunately the date I'm looking for is older than the archives on toronto or hostserver.de Anyway I'll try a build the whole system. Any hints of what specific is needed would be nice, since building the whole system every time until I find the commit I'm looking for would be a pain. G
Re: kernel rebuild to debug problem
On Sun, 19 May 2024 20:52:56 +0100, Kapetanakis Giannis wrote: > > I'm trying to bisect a bug and compile an older kernel from cvs > > cvs checkout -D "2023-01-05" src/sys > > and following https://www.openbsd.org/faq/faq5.html#Options > + make install > > New kernel compiles and boots but I get: > > # pfctl -f /etc/pf.conf > pfctl: DIOCADDRULE: Operation not supported by device > > # pfctl -sr > pfctl: Permission denied > > # pfctl -si | head -1 > Status: Enabled for 0 days 00:05:03 Debug: err > > any ideas about this? > You need to build / use no only old kernel but the whole system. The simplest way is to use archived version of snapshots from https://openbsd.cs.toronto.edu/archive/ or another mirror. -- wbr, Kirill
kernel rebuild to debug problem
I'm trying to bisect a bug and compile an older kernel from cvs cvs checkout -D "2023-01-05" src/sys and following https://www.openbsd.org/faq/faq5.html#Options + make install New kernel compiles and boots but I get: # pfctl -f /etc/pf.conf pfctl: DIOCADDRULE: Operation not supported by device # pfctl -sr pfctl: Permission denied # pfctl -si | head -1 Status: Enabled for 0 days 00:05:03 Debug: err any ideas about this? G
Re: pf anchors attached to irrelevant states
On 5/19/24 13:37, Stuart Henderson wrote: I can confirm this is a problem, definitely seen in 7.4, I can't remember if 7.3 was affected. 7.2 from Dec 22 seems ok. Yes, 7.3 is affected. It is the same problem reported here: https://marc.info/?l=openbsd-misc=168754952806369
Re: pf anchors attached to irrelevant states
On 19/05/2024 14:37, Stuart Henderson wrote: On 2024-05-19, Kapetanakis Giannis wrote: This is a bit strange. pf works normal, but rules after an enchor an being attached to the anchor (somehow). All states that are created from rules after the anchor, show the anchor (pf rule) number instead of (only) the rule number in pfctl -vv and in pflog. I can confirm this is a problem, definitely seen in 7.4, I can't remember if 7.3 was affected. 7.2 from Dec 22 seems ok. 7.3 release was also affected, just tested on a vm. G
Re: pf anchors attached to irrelevant states
On 2024-05-19, Kapetanakis Giannis wrote: > This is a bit strange. pf works normal, but rules after an enchor an > being attached to the anchor (somehow). > > All states that are created from rules after the anchor, show the anchor > (pf rule) number instead of (only) the rule number in pfctl -vv and in > pflog. I can confirm this is a problem, definitely seen in 7.4, I can't remember if 7.3 was affected. 7.2 from Dec 22 seems ok.
pf anchors attached to irrelevant states
This is a bit strange. pf works normal, but rules after an enchor an
being attached to the anchor (somehow).
All states that are created from rules after the anchor, show the anchor
(pf rule) number instead of (only) the rule number in pfctl -vv and in
pflog.
Here is a quite simple example.
# pfctl -sr -a'*' -vv | egrep -v "Evaluations|Inserted" | head -6
@0 match in all scrub (no-df random-id)
@1 pass in quick on vio0 from to any flags S/SA set (prio 6) keep
state (if-bound, pflow) tag from_external
@2 anchor "test" quick all {
@0 pass out log quick on egress inet proto tcp from any to any port = 2000
flags S/SA keep state (if-bound) rdr-to 127.0.0.1
}
@3 pass out log quick inet proto tcp from any to yy.yy.yy.yy port = 22 flags
S/SA keep state (if-bound, pflow)
Test traffic for anchor rule works fine (xx.xx.xx.xx is my external ip)
# telnet 8.8.8.8 2000
pflog: May 19 13:54:03.427024 rule 2.test.0/(match) pass out on vio0: xx.xx.xx.36179
> 8.8.8.8.2000: S 4080176752:4080176752(0) win 16384 (DF) [tos 0x10]
# pfctl -ss -vv | grep -A3 8.8.8.8
vio0 tcp xx.xx.xx.xx:36179 -> 127.0.0.1:2000 (8.8.8.8:2000)
SYN_SENT:CLOSED
[4080176752 + 2] [0 + 1]
age 00:00:01, expires in 00:01:59, 1:0 pkts, 64:0 bytes, anchor 2, rule 0
<<<--- this rule 0 of anchor which is correct
id: 661391580039aaa3 creatorid: bfd893f9
See what happens if I try to triger rule @3 and ssh to yy.yy.yy.yy
pflog: May 19 13:55:42.386186 rule 2/(match) pass out on vio0: xx.xx.xx.xx.23564 >
yy.yy.yy.yy.22: S 3631867116:3631867116(0) win 16384 (DF) [tos 0x48]
pfctl -ss -vv|grep -A3 yy.yy.yy.yy
vio0 tcp xx.xx.xx.xx:23564 -> yy.yy.yy.yy:22 ESTABLISHED:ESTABLISHED
[3631869502 + 37760] wscale 6 [3744464382 + 16384] wscale 7
age 00:01:10, expires in 23:58:54, 16:19 pkts, 3229:3857 bytes, anchor 2,
rule 3, pflow
id: 661391580039ab07 creatorid: bfd893f9
pflog, logs "rule 2" which is the anchor instead of "rule 3"
pfctl, shows "anchor 2, rule 3" instead of just "rule 3"
Traffic works normally but there is something fishy here.
quick on anchor does not make any difference, although to my understanding it
shouldn't matter either set or not set in this case.
G
