Re: pfctl -T expire
On 2020-01-24, myml...@gmx.com wrote: > Hi All, > > Thanks to Jesper and Stuart, i'm using max-pkt-rate not! > > I'm also using max-src-conn-rate and overload in conjunction with authpf > and I'm worried that potentially valid traffic may get blocked. > > I'm wondering if it's a condoned/accepted/best practice to use cron with > pfctl to expire table entries that are over a certain age. Yes, that is often required, "pfctl -T expire [number]" is for exactly this.
Re: pfctl -T expire
On 1/23/20 7:17 PM, myml...@gmx.com wrote: Hi All, Thanks to Jesper and Stuart, i'm using max-pkt-rate not! I'm also using max-src-conn-rate and overload in conjunction with authpf and I'm worried that potentially valid traffic may get blocked. I'm wondering if it's a condoned/accepted/best practice to use cron with pfctl to expire table entries that are over a certain age. I promise I did google "cron pfctl -T expire" first and only came up with someone who wrote a script from 2014!!! Thanks in advance! Thanks to Jesper and Stuart, i'm using max-pkt-rate now!
Re: pfctl: cidr typo bug
On 11/13/18 16:28, Stuart Henderson wrote: On 2018/11/13 10:15, Andrew wrote: On 11/13/18 11:08, Stuart Henderson wrote: > On 2018-11-11, Andrew wrote: > > ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5 > > 1 table created. > > 1/1 addresses added. > > This would normally fail right here. > > > ~: doas pfctl -t cidr_typo -T show > >127.0.0.1 > > I think your name resolver may be giving out 127.0.0.1 as an address > in response to a query for "1.2.3.4*5". Test with dig(1) / host(1) / > "getent hosts 1.2.3.4*5". Great insight Stuart !!! unbound on my patched 6.3 gateway is returning: > getent hosts 1.2.3.4*5 127.0.0.1 1.2.3.4*5 ::1 1.2.3.4*5 Both laptops use the gateway as a name resolver. Hope that helps !!! It doesn't happen with a standard unbound setup, so this is either something non-standard in your unbound config, or you are forwarding and it's something non-standard in your upstream resolver. OK I just tested for that. I'll start a new thread about unbound resolving 1.2.3.4*5 to 127.0.0.1. Thanks again for a great insight.
Re: pfctl: cidr typo bug
On 2018/11/13 10:15, Andrew wrote: > On 11/13/18 11:08, Stuart Henderson wrote: > > On 2018-11-11, Andrew wrote: > > > ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5 > > > 1 table created. > > > 1/1 addresses added. > > > > This would normally fail right here. > > > > > ~: doas pfctl -t cidr_typo -T show > > >127.0.0.1 > > > > I think your name resolver may be giving out 127.0.0.1 as an address > > in response to a query for "1.2.3.4*5". Test with dig(1) / host(1) / > > "getent hosts 1.2.3.4*5". > > Great insight Stuart !!! unbound on my patched 6.3 gateway is returning: > > > getent hosts 1.2.3.4*5 > 127.0.0.1 1.2.3.4*5 > ::1 1.2.3.4*5 > > Both laptops use the gateway as a name resolver. > > Hope that helps !!! It doesn't happen with a standard unbound setup, so this is either something non-standard in your unbound config, or you are forwarding and it's something non-standard in your upstream resolver.
Re: pfctl: cidr typo bug
On 11/13/18 11:08, Stuart Henderson wrote: On 2018-11-11, Andrew wrote: ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5 1 table created. 1/1 addresses added. This would normally fail right here. ~: doas pfctl -t cidr_typo -T show 127.0.0.1 I think your name resolver may be giving out 127.0.0.1 as an address in response to a query for "1.2.3.4*5". Test with dig(1) / host(1) / "getent hosts 1.2.3.4*5". Great insight Stuart !!! unbound on my patched 6.3 gateway is returning: getent hosts 1.2.3.4*5 127.0.0.1 1.2.3.4*5 ::1 1.2.3.4*5 Both laptops use the gateway as a name resolver. Hope that helps !!!
Re: pfctl: cidr typo bug
On 2018-11-11, Andrew wrote: > ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5 > 1 table created. > 1/1 addresses added. This would normally fail right here. > ~: doas pfctl -t cidr_typo -T show >127.0.0.1 I think your name resolver may be giving out 127.0.0.1 as an address in response to a query for "1.2.3.4*5". Test with dig(1) / host(1) / "getent hosts 1.2.3.4*5".
Re: pfctl: cidr typo bug
On 11/11/18 19:23, Klemens Nanni wrote: On Sun, Nov 11, 2018 at 12:01:33PM -0600, Andrew wrote: ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5 1 table created. 1/1 addresses added. I fail to reproduce this with recent snapshots on both amd64 and sparc64: # pfctl -t cidr_typo -T add 1.2.3.4*5 no IP address found for 1.2.3.4*5 ~: doas pfctl -t cidr_typo -T show127.0.0.1 # pfctl -t cidr_typo -T show pfctl: Table does not exist. --- Last one for you. I'm leaving this to your expertise. I just followed the same process on a Lenovo T440s. same bsd.rd as the T420 same install.fs same upgrade process scp bsd.rd to t440s mv bsd.rd to / mv sd from t420 to the t440s reboot boot hd0a://bsd.rd "upgrade" "disk" skipped games upgraded sets rebooted -- login #> pfctl -t cidr_typo -T add 1.2.3.4*5 1 table created 2/2 addresses added #> pfctl -t cidt_typo -T show 127.0.0.1 ::1 --- OpenBSD 6.4-current (GENERIC.MP) #432: Sun Nov 11 03:46:12 MST 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8246050816 (7864MB) avail mem = 7986860032 (7616MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (61 entries) bios0: vendor LENOVO version "GJET77WW (2.27 )" date 05/20/2014 bios0: LENOVO 20ARS0LF02 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT UEFI MSDM ASF! BATB FPDT UEFI SSDT acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 1796.13 MHz, 06-45-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 1795.85 MHz, 06-45-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 1795.85 MHz, 06-45-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i5-4300U CPU @ 1.90GHz, 1795.85 MHz, 06-45-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@148 mwait.1@0x33), C1(1000@1
Re: pfctl: cidr typo bug
On 11/11/18 19:23, Klemens Nanni wrote: On Sun, Nov 11, 2018 at 12:01:33PM -0600, Andrew wrote: ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5 1 table created. 1/1 addresses added. I fail to reproduce this with recent snapshots on both amd64 and sparc64: # pfctl -t cidr_typo -T add 1.2.3.4*5 no IP address found for 1.2.3.4*5 ~: doas pfctl -t cidr_typo -T show127.0.0.1 # pfctl -t cidr_typo -T show pfctl: Table does not exist. OK ... This test was performed earlier today on a Lenovo T420. --- OpenBSD 6.4-current (GENERIC) #412: Sun Nov 11 03:40:49 MST 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC real mem = 8451125248 (8059MB) avail mem = 8185843712 (7806MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9b000 (65 entries) bios0: vendor LENOVO version "83ET80WW (1.50 )" date 03/06/2018 bios0: LENOVO 41786UU acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT SSDT DMAR UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz, 797.54 MHz, 06-2a-07 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpicpu0 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2 acpitz0 at acpi0: critical temperature is 98 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x 0x0011 0x0001 acpicmos0 at acpi0 tpm0 at acpi0: TPM_ addr 0xfed4/0x5000: device 0x104a rev 0x4e acpibat0 at acpi0: BAT0 model "45N1001" serial 7058 type LION oem "SANYO" acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: VID_ acpivout at acpivideo0 not configured acpivideo1 at acpi0: VID_ cpu0: Enhanced SpeedStep 797 MHz: speeds: 2501, 2500, 2200, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09 inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09 drm0 at inteldrm0 inteldrm0: msi inteldrm0: 1366x768, 32bpp wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured puc0 at pci0 dev 22 function 3 "Intel 6 Series KT" rev 0x04: ports: 16 com com4 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo com4: probed fifo depth: 0 bytes em0 at pci0 dev 25 function 0 "Intel 82579LM" rev 0x04: msi, address 00:21:cc:6e:6b:14 ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x04: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 "Intel 6 Series HD Audio" rev 0x04: msi azalia0: codecs: Conexant CX20590, Intel/0x2805, using Conexant CX20590 audio0 at azalia0 ppb0 at pci0 dev 28 function 0 "Intel 6 Series PCIE" rev 0xb4: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 "Intel 6 Series PCIE" rev 0xb4: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, MIMO 2T2R, MoW, address 08:11:96:c1:b1:5c ppb2 at pci0 dev 28 function 3 "Intel 6 Series PCIE" rev 0xb4: msi pci3 at ppb2 bus 5 ppb3 at pci0 dev 28 function 4 "Intel 6 Series PCIE" rev 0xb4: msi pci4 at ppb3 bus 13 sdhc0 at pci4 dev 0 function 0 "Ricoh 5U823 SD/MMC" rev 0x05: apic 2 int 16 sdhc0: SDHC 3.0, 50 MHz base clock sdmmc0 at sdhc0: 4-bit, sd high-speed, mmc high-speed, dma "Ricoh 5U832 Firewire" rev 0x04 at pci4 dev 0 function 3 not configured ehci1 at pci0 dev 29 function 0 "Intel 6 Series USB" rev 0x04: apic 2 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 configuration 1 interface 0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
Re: pfctl: cidr typo bug
On Sun, Nov 11, 2018 at 12:01:33PM -0600, Andrew wrote: > ~: doas pfctl -t cidr_typo -T add 1.2.3.4*5 > 1 table created. > 1/1 addresses added. I fail to reproduce this with recent snapshots on both amd64 and sparc64: # pfctl -t cidr_typo -T add 1.2.3.4*5 no IP address found for 1.2.3.4*5 > ~: doas pfctl -t cidr_typo -T show127.0.0.1 # pfctl -t cidr_typo -T show pfctl: Table does not exist.
Re: pfctl tables: adding a CIDR typo to a new table
On 10/06/18 00:28, Klemens Nanni wrote: On Fri, Oct 05, 2018 at 04:02:12PM -0600, Andrew wrote: recent snapshot: $> uname -vrsm OpenBSD 6.4 GENERIC#329 amd64 What's the timestamp? Please provide more detailed information next time. $> doas pfctl -t sample -T add 74.125.0.0*16 1 table created. 1/1 addresses added. It's not recent enough: $ sysctl -n kern.version | head -n1 OpenBSD 6.4 (GENERIC.MP) #0: Thu Oct 4 00:29:55 CEST 2018 # for s in 1\*8 74.125.0.0\*16 ::1-64 ; do > pfctl -t sample -T add $s > done no IP address found for 1*8 no IP address found for 74.125.0.0*16 no IP address found for ::1-64 I'll use a different command next time. Thanks for the head's up !!! you: OpenBSD 6.4 (GENERIC.MP) #0: Thu Oct 4 00:29:55 CEST 2018 me: OpenBSD 6.4 (GENERIC) #329: Thu Oct 4 09:53:31 MDT 2018 ** Please note that you are using a different kernel from the same day ** $> doas pfctl -t 2ndtry -T add 74.125.0.0*24 1 table created. 1/1 addresses added. $> doas pfctl -t 2ndtry -T show 127.0.0.1 Thanks for the quick reply. Moving forward -- it seems to be fixed. I'll try a newer snapshot later this weekend. Have a great weekend ahead !!
Re: pfctl tables: adding a CIDR typo to a new table
On Fri, Oct 05, 2018 at 04:02:12PM -0600, Andrew wrote: > recent snapshot: > > $> uname -vrsm > OpenBSD 6.4 GENERIC#329 amd64 What's the timestamp? Please provide more detailed information next time. > $> doas pfctl -t sample -T add 74.125.0.0*16 > 1 table created. > 1/1 addresses added. It's not recent enough: $ sysctl -n kern.version | head -n1 OpenBSD 6.4 (GENERIC.MP) #0: Thu Oct 4 00:29:55 CEST 2018 # for s in 1\*8 74.125.0.0\*16 ::1-64 ; do > pfctl -t sample -T add $s > done no IP address found for 1*8 no IP address found for 74.125.0.0*16 no IP address found for ::1-64
Re: pfctl tables and a mangled ip address
On Thu, Sep 13, 2018 at 12:21:28PM -0600, Andrew wrote: > Try this on a patched 6.3 amd64. Not sure since when but this is fixed in -current. $ sysctl -n kern.version OpenBSD 6.4-beta (GENERIC.MP) #292: Mon Sep 10 18:26:22 MDT 2018 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > $> pfctl -t sample -T add 66.135.216.190.216 > 2/2 addresses added. $ doas pfctl -t sample -T add 66.135.216.190.216 no IP address found for 66.135.216.190.216 > $> pfctl -t sample -T show $ doas pfctl -t sample -T show 176.0.0.0/8 205.251.192.0/18
Re: pfctl: DIOCGETQSTATS: Bad file descriptor
I found out what the issue was. As an example, this is valid with "pfctl -f /etc/pf.conf" but will throw "pfctl: DIOCGETQSTATS: Bad file descriptor" with "pfctl -s queue": queue test on egress bandwidth 1M default This works properly with "pfctl -s queue" as well: queue test on em0 bandwidth 1M default I sent a copy to bugs@ since I doubt this is desired behavior.
Re: pfctl: DIOCGETQSTATS: Bad file descriptor
I haven't done anything other than binary releases in some time, although it's possible I may have fat fingered a terminal at some point. I infrequently check these boxes other than biannual release updates and mtier patches. The checksums and timestamps of /bsd and /sbin/pfctl match another working 5.8 box, and uname -a gives: OpenBSD hostname 5.8 GENERIC.MP#0 amd64 The box is my home router and I'm very far away for the next few weeks, so will leave it as-is since it's working for now. If no one has seen this before, I'll give it another go with a fresh binary install when I'm able to get access to the box again. Thanks all!
Re: pfctl: DIOCGETQSTATS: Bad file descriptor
On 01/11/16 04:44, li...@ggp2.com wrote: Whenever running "doas pfctl -s queue -v" on a 5.8/amd64 box (PC engines apu1d4), it outputs the error "pfctl: DIOCGETQSTATS: Bad file descriptor". My initial reaction when reading this was "this sounds like kernel and userland out of sync" and a search on the obvious keywords (as in, pasting the error message into a search engine) seems to confirm this. Did you by any chance attempt an upgrade via source recently? -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ "Remember to set the evil bit on all malicious network traffic" delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Em 11-11-2015 00:06, Nick Holland escreveu: > The point is...if you put in a DNS name, odds are you are going to end > up thinking you are blocking/passing/redirecting a DNS name..when in > reality, you are whatevering JUST the IP address that it resolves to at > the time the firewall rules were loaded. You may have missed a lot, or > it may move. > > IF you are really in a situation where the only things you are trying to > manage with DNS names are simple 1:1 name:ip mappings, an easy solution > would be to have your pf.conf file a "stub" with enough to let the > system come up, then a post boot and periodic (re)load of the "real" > rules in a separate file. I tried to help the OP by suggesting he use macros or anchors; I'd like to take it back. Don't ever use dns names on pf.conf. The only safe way to properly deal with this is using a proxy. Relayd can work quite well for simple cases. Cheers, Giancarlo Razzolini
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Em 10-11-2015 13:58, Kent Watsen escreveu: > Precondition: /etc/pf.conf contains scr_addr/dst_addr set to FQDNs > > On boot, the consoles shows error about not being able to load pf.conf > because it can't resolve the symbolic names. If your resolver can't be accessed, this will happen. > > http://www.openbsd.org/faq/faq6.html#Setup.activate says: > >    "... if you had specified a DNS-resolved symbolic name in any of >    the files, you would probably find it worked as expected after >    reconfigure, but on initial boot, your external resolver may >    not be available, so the configuration will fail." > > but I thought that the statement might be limited to `netstat`, and > /etc/rc runs `netstat` before loading the firewall rules. So I'm not > sure why it's not working... As a general rule you should avoid using dns names on anything that might cause the boot process to fail. Even more, you should really avoid using names on hostname.if files. > > Anybody run into this before? - is the fix to add all the symbolic > names to /etc/hosts? Well, if the hosts have fixed addresses, you'd be better using macros on pf.conf that translate to their IP address. This way you won't run into boot issues (or reload issues, in case your resolver is down). This has the added inconvenience that you need to update your pf.conf file manually every time one address changes. Now, if you really, really need to use fqdn's on pf.conf, my suggestion is that you use ifstated to detected if your link is up and your resolver working, and them load the rules into an anchor afterwards. Also, you can update the anchor to reflect any uplink unavailability. Or you can use unbound with local-zones or a unbound + nsd combo, if you also need authoritative. I think you'll need to hack your /etc/rc file to load them before your pf.conf is loaded. Cheers, Giancarlo Razzolini
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
On 15-11-10 01:45 PM, Giancarlo Razzolini wrote: As a general rule you should avoid using dns names on anything that might cause the boot process to fail. Even more, you should really avoid using names on hostname.if files. Anybody run into this before? - is the fix to add all the symbolic names to /etc/hosts? Well, if the hosts have fixed addresses, you'd be better using macros on pf.conf that translate to their IP address. This way you won't run into boot issues (or reload issues, in case your resolver is down). This has the added inconvenience that you need to update your pf.conf file manually every time one address changes. Now, if you really, really need to use fqdn's on pf.conf, my suggestion is that you use ifstated to detected if your link is up and your resolver working, and them load the rules into an anchor afterwards. Also, you can update the anchor to reflect any uplink unavailability. Or you can use unbound with local-zones or a unbound + nsd combo, if you also need authoritative. I think you'll need to hack your /etc/rc file to load them before your pf.conf is loaded. FWIW, yes, putting the entries into /etc/hosts *will* work, and it avoids the need to use pf.conf macros, ifstated, etc. However, it now means that you have to ensure /etc/hosts remains 100% accurate... although I shudder to think of using ifstated and anchors to do this, it does avoid the /etc/hosts maintenance problem. And make no mistake: you *will* eventually forget to update /etc/hosts. Absolutely, 100% guaranteed. -Adam
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
Hi Kent, On 2015-11-10 Tue 10:58 AM |, Kent Watsen wrote: > > Anybody run into this before?? - is the fix to add all the symbolic > names to /etc/hosts? > Yes, use /etc/hosts. Same for hostnames in /etc/syslog.conf if using localhost unbound as the only nameserver in /etc/resolv.conf. Then also: 1) have a daily script that updates /etc/hosts' IP addresses. But you must remember to add/remove the names manually. 2) reload pf's rules in /etc/rc.local - for when /etc/hosts is wrong... Cheers. -- The reason computer chips are so small is computers don't eat much.
Re: pfctl -f /etc/pf.conf fails on boot when DNS-resolved symbolic names are used
On 11/10/15 10:57, Kent Watsen wrote: > Precondition: /etc/pf.conf contains scr_addr/dst_addr set to FQDNs > > On boot, the consoles shows error about not being able to load pf.conf > because it can't resolve the symbolic names. > > http://www.openbsd.org/faq/faq6.html#Setup.activate says: > >    "... if you had specified a DNS-resolved symbolic name in any of >    the files, you would probably find it worked as expected after >    reconfigure, but on initial boot, your external resolver may >    not be available, so the configuration will fail." > > but I thought that the statement might be limited to `netstat`, and > /etc/rc runs `netstat` before loading the firewall rules. So I'm not > sure why it's not working... > > Anybody run into this before? - is the fix to add all the symbolic > names to /etc/hosts? adding yet another voice, though somewhat different answer: don't use symbolic names. Here's the thing: PF works on IP addresses. NOT DNS names. While you might argue DNS names resolve to IP addresses, they do NOT do a 1:1 correlation. You will end up with problems someday that might take a bit of investigation to figure out. Long long ago, a company I used to work for had a firewall that Wasn't My Problem. Or so I thought. It would block various sites management didn't want people going to; the user would just end up at a friendly site saying, "we don't want you to go here". Management decided that webmail was not something they wanted people going to, so they blocked most of the known major webmail services. But every once in a while, when someone would go to Google, they would get the "Blocked!" message. It was rare, but definitely happening, and it could happen all over the company. And half an hour later...problem is gone...only to appear later on someone else's computer. Maybe you are ahead of me. If so, congratulate yourself, I puzzled over this for a few weeks. Turned out the way this firewall blocked SITES was by resolving the name, and adding redirections for those addresses. Someone entered "gmail.google.com" into that table, and it quickly got lost among all the other entries. On boot, the firewall would resolve gmail.google.com, and put the one or five or whatever entries in the block/redirect table, and forget about it. Well...you see, google uses a massive front-end infrastructure for most or all of their services, and the requested name would dictate the route through the load balancers. So...this firewall was blocking probably one or five of the HUNDREDS or THOUSANDS of IP addresses Google would return for ANY of its services. So once in a while, gmail.google.com was blocked, but sometimes so was www.google.com. The point is...if you put in a DNS name, odds are you are going to end up thinking you are blocking/passing/redirecting a DNS name..when in reality, you are whatevering JUST the IP address that it resolves to at the time the firewall rules were loaded. You may have missed a lot, or it may move. IF you are really in a situation where the only things you are trying to manage with DNS names are simple 1:1 name:ip mappings, an easy solution would be to have your pf.conf file a "stub" with enough to let the system come up, then a post boot and periodic (re)load of the "real" rules in a separate file. Nick.
Re: pfctl: DIOCADDQUEUE: No such process
Hi Henning, you are true, i found the problem 1 week ago, a hidden interface in my 3000 rules' pf.conf :) -- Best regards, Loïc BLOT, Engineering UNIX Systems, Security and Network Engineer http://www.unix-experience.fr Le samedi 02 août 2014 à 12:17 +0200, Henning Brauer a écrit : * Loïc Blot loic.b...@unix-experience.fr [2014-07-23 17:12]: pfctl: DIOCADDQUEUE: No such process that most likely means you're trying to create a queue on a nonexistant inmterface.
Re: pfctl: DIOCADDQUEUE: No such process
* Loïc Blot loic.b...@unix-experience.fr [2014-07-23 17:12]: pfctl: DIOCADDQUEUE: No such process that most likely means you're trying to create a queue on a nonexistant inmterface. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services GmbH, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS. Virtual Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: pfctl: DIOCADDQUEUE: No such process
Hello after the reboot the problem persists... pfctl: DIOCADDQUEUE: No such process The default ruleset has been loaded: block drop all pass out inet6 proto ipv6-icmp all icmp6-type neighbrsol pass out inet6 proto ipv6-icmp all icmp6-type routersol pass out inet6 proto udp from any port = 546 to any port = 547 pass out inet proto icmp all icmp-type echoreq pass out inet proto udp from any port = 68 to any port = 67 pass out proto tcp from any to any port = 53 flags S/SA pass out proto udp from any to any port = 53 pass in inet6 proto ipv6-icmp all icmp6-type neighbradv pass in inet6 proto ipv6-icmp all icmp6-type routeradv pass in inet6 proto udp from any port = 547 to any port = 546 pass in proto tcp from any to any port = 22 flags S/SA pass in inet proto udp from any port = 67 to any port = 68 pass on lo0 all flags S/SA pass proto carp all keep state (no-sync) -- Best regards, Loïc BLOT, Engineering UNIX Systems, Security and Network Engineer http://www.unix-experience.fr Le jeudi 24 juillet 2014 à 17:44 +0200, Loïc Blot a écrit : Hi David, in fact no, now the ruleset is empty and everything is allowed, erf. Now i have no choice, i need to reboot this critical router :(. I think there is a bug somewhere, i'll try to found why this is happening before rebooting (maybe a patch if i can)
Re: pfctl: DIOCADDQUEUE: No such process
Erf... i found the error. An admin has configured a queue on a inexisting interface... Maybe the pfctl tell us the interface doesn't exists ? Sorry for the inconvenience -- Best regards, Loïc BLOT, Engineering UNIX Systems, Security and Network Engineer http://www.unix-experience.fr Le vendredi 25 juillet 2014 à 09:25 +0200, Loïc Blot a écrit : Hello after the reboot the problem persists... pfctl: DIOCADDQUEUE: No such process The default ruleset has been loaded: block drop all pass out inet6 proto ipv6-icmp all icmp6-type neighbrsol pass out inet6 proto ipv6-icmp all icmp6-type routersol pass out inet6 proto udp from any port = 546 to any port = 547 pass out inet proto icmp all icmp-type echoreq pass out inet proto udp from any port = 68 to any port = 67 pass out proto tcp from any to any port = 53 flags S/SA pass out proto udp from any to any port = 53 pass in inet6 proto ipv6-icmp all icmp6-type neighbradv pass in inet6 proto ipv6-icmp all icmp6-type routeradv pass in inet6 proto udp from any port = 547 to any port = 546 pass in proto tcp from any to any port = 22 flags S/SA pass in inet proto udp from any port = 67 to any port = 68 pass on lo0 all flags S/SA pass proto carp all keep state (no-sync)
Re: pfctl: DIOCADDQUEUE: No such process
Hi, thanks for the tip. No pfpurge process is running :( Here is dmesg.boot OpenBSD 5.5 (GENERIC.MP) #315: Wed Mar 5 09:37:46 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17082220544 (16290MB) avail mem = 16618885120 (15849MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xcf42c000 (77 entries) bios0: vendor Dell Inc. version 1.4.6 date 10/26/2012 bios0: Dell Inc. PowerEdge R320 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC SPCR HPET DMAR MCFG WD__ SLIC ERST HEST BERT EINJ TCPA PC__ SRAT SSDT acpi0: wakeup devices PCI0(S5) EHC1(S3) EHC2(S3) PCI1(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz, 2200.34 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz, 2200.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz, 2200.00 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E5-2407 0 @ 2.20GHz, 2200.00 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 0 pa 0xfec0, version 20, 24 pins ioapic1 at mainbus0: apid 1 pa 0xfec3f000, version 20, 24 pins ioapic1: misconfigured as apic 15, remapped to apid 1 acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEX1) acpiprt2 at acpi0: bus -1 (PEX2) acpiprt3 at acpi0: bus 8 (PEX3) acpiprt4 at acpi0: bus -1 (PEX4) acpiprt5 at acpi0: bus -1 (PEX5) acpiprt6 at acpi0: bus 10 (PEX6) acpiprt7 at acpi0: bus 2 (PEX7) acpiprt8 at acpi0: bus -1 (PEX8) acpiprt9 at acpi0: bus 3 (PEX9) acpicpu0 at acpi0 acpicpu1 at acpi0 acpicpu2 at acpi0 acpicpu3 at acpi0 ipmi at mainbus0 not configured pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel E5 Host rev 0x07 ppb0 at pci0 dev 1 function 0 Intel E5 PCIE rev 0x07 pci1 at ppb0 bus 1 mfi0 at pci1 dev 0 function 0 Symbios Logic MegaRAID SAS2008 rev 0x03: apic 1 int 2 mfi0: PERC H310 Mini, firmware 20.11.0-0002 scsibus0 at mfi0: 16 targets sd0 at scsibus0 targ 0 lun 0: DELL, PERC H310, 2.12 SCSI3 0/direct fixed naa.690b11c032dcc20018c237a20522edfe sd0: 285568MB, 512 bytes/sector, 584843264 sectors scsibus1 at mfi0: 256 targets ppb1 at pci0 dev 3 function 0 Intel E5 PCIE rev 0x07: msi pci2 at ppb1 bus 8 em0 at pci2 dev 0 function 0 Intel I350 rev 0x01: msi, address a0:36:9f:10:43:ac em1 at pci2 dev 0 function 1 Intel I350 rev 0x01: msi, address a0:36:9f:10:43:ad Intel E5 Address Map rev 0x07 at pci0 dev 5 function 0 not configured Intel E5 Error Reporting rev 0x07 at pci0 dev 5 function 2 not configured ppb2 at pci0 dev 17 function 0 Intel C600 Virtual PCIE rev 0x05 pci3 at ppb2 bus 9 Intel C600 MEI rev 0x05 at pci0 dev 22 function 0 not configured Intel C600 MEI rev 0x05 at pci0 dev 22 function 1 not configured ehci0 at pci0 dev 26 function 0 Intel C600 USB rev 0x05: apic 0 int 23 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at pci0 dev 28 function 0 Intel C600 PCIE rev 0xb5: msi pci4 at ppb3 bus 10 em2 at pci4 dev 0 function 0 Intel I350 rev 0x01: msi, address a0:36:9f:12:bf:14 em3 at pci4 dev 0 function 1 Intel I350 rev 0x01: msi, address a0:36:9f:12:bf:15 ppb4 at pci0 dev 28 function 4 Intel C600 PCIE rev 0xb5 pci5 at ppb4 bus 2 bge0 at pci5 dev 0 function 0 Broadcom
Re: pfctl: DIOCADDQUEUE: No such process
Am Mittwoch, den 23.07.2014, 17:10 +0200 schrieb Loïc Blot: Hi @misc, This afternoon i got a very strange issue on a router/firewall. I added a rule and then the following error appears: pfctl -nf /etc/pf.conf pfctl -f /etc/pf.conf pfctl: DIOCADDQUEUE: No such process I don't have any queue configured on the firewall. I also tried pfctl -d; pfctl -e; pfctl -f /etc/pf.conf I have seen this a few times. If it happens, then usually not during/right after bootup, but on a running system and it won't even accept even an empty pf.conf. A reboot usually helps, but this is not really a solution. Does pfctl -Fa help? Cheers -- David Dahlberg Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845 Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277
Re: pfctl: DIOCADDQUEUE: No such process
Hi David, in fact no, now the ruleset is empty and everything is allowed, erf. Now i have no choice, i need to reboot this critical router :(. I think there is a bug somewhere, i'll try to found why this is happening before rebooting (maybe a patch if i can) -- Best regards, Loïc BLOT, Engineering UNIX Systems, Security and Network Engineer http://www.unix-experience.fr Le jeudi 24 juillet 2014 à 12:09 +, Dahlberg, David a écrit : Am Mittwoch, den 23.07.2014, 17:10 +0200 schrieb Loïc Blot: Hi @misc, This afternoon i got a very strange issue on a router/firewall. I added a rule and then the following error appears: pfctl -nf /etc/pf.conf pfctl -f /etc/pf.conf pfctl: DIOCADDQUEUE: No such process I don't have any queue configured on the firewall. I also tried pfctl -d; pfctl -e; pfctl -f /etc/pf.conf I have seen this a few times. If it happens, then usually not during/right after bootup, but on a running system and it won't even accept even an empty pf.conf. A reboot usually helps, but this is not really a solution. Does pfctl -Fa help? Cheers
Re: pfctl: DIOCADDQUEUE: No such process
I cannot give you the dmesg output of the machine because the uptime (dmesg was polluted by some carp messages :p), i cannot reboot it at this time, it's a BGP router and the redundancy is in maintenance. try ‘cat /var/run/dmesg.boot'
Re: pfctl manpage.
On Fri, Jul 19, 2013 at 09:22:54AM +0200, Pieter Verberne wrote: From 'man pfctl': When the variable pf is set to YES in rc.conf.local(8), the rule file specified with the variable pf_rules is loaded automatically by the rc(8) scripts and the packet filter is enabled. I think pf is enabled by default now :-) agreed. i've just zapped that paragraph. jmc
Re: pfctl - show port numbers
From: Henning Brauer (lists-openbsdbsws.de) Date: Sun Dec 02 2007 - 14:45:37 CST * MikeM the.listsmgm51.com [2007-12-02 15:35]: When I run the command pfctl -sr a list of the rules is displayed, a sample line is below. pass in log quick on fxp0 inet proto tcp from 226.174.167.164 to (fxp0) port = smtp flags S/FSRA keep state Is there a way for me to tell pfctl that I want to see port = 25 instead of port = smtp ? short of hacking pfctl source, no. -- Henning Brauer, hbbsws.de, henningopenbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam Thank-you! I see the change was made in 5.1. Yea. No more hacking print_ports()!
Re: pfctl -P
On Mon, May 28, 2012 at 03:34:04PM +0200, Jan Stary wrote: The manpage says -P Print ports using their names in /etc/services if available. This works with pfctl -P -sr, but not with pfctl -P -ss - is that intended? Good catch. :) I originally created -P for use with -sr, and did not consider that it might be useful for -ss too. Let me see if I can hack something up... Thanks, Lawrence
Re: pfctl: DIOCADDRULE: Operation not supported by device
* roberth rob...@openbsd.pap.st [2011-05-09 00:29]: On the otherhand, i have been running -current for years and never have had any problem with building source with the previouse kernel (without reboot) that i can remember. Maybe my 3 digit amount of builds isn't enough or i built at the wrong states of the tree. indeed. it is not exactly the first time pf ioctls changed. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfctl: DIOCADDRULE: Operation not supported by device
On 2011-05-08, Chris Smith obsd_m...@chrissmith.org wrote: After an update to -current yesterday Internet access was lost as pf.conf could not be loaded. The error message was: pfctl: DIOCADDRULE: Operation not supported by device Address translation would break but you should still be able to get into the machine. This error occurred after upgrading the kernel and then rebooting. After userland was brought up to date as well and the system rebooted everything was fine. The system in question was local so outside of being offline for the amount of time it took to build userland there wasn't a lot to worry about. What I'm concerned with is this being an issue on a remote system where not being able to get back in after rebooting with just an updated kernel would (if it happened) be a serious issue. I would *very strongly* recommend out of band management of some sort for any important remote machine. Whether it's serial console, KVM/IP, or a remote management card (one with dedicated nic; there are good reasons why openbsd doesn't support the shared nic cards). If you skip this, it's more important than usual to the same upgrade path on the same type of machine locally first. There's usually no problem, but sometimes you get unlucky with various code changes.
Re: pfctl: DIOCADDRULE: Operation not supported by device
On 05/08/2011 03:05 PM, Otto Moerbeek wrote: On Sun, May 08, 2011 at 02:54:21PM -0400, Chris Smith wrote: After an update to -current yesterday Internet access was lost as pf.conf could not be loaded. The error message was: pfctl: DIOCADDRULE: Operation not supported by device This error occurred after upgrading the kernel and then rebooting. After userland was brought up to date as well and the system rebooted everything was fine. The system in question was local so outside of being offline for the amount of time it took to build userland there wasn't a lot to worry about. What I'm concerned with is this being an issue on a remote system where not being able to get back in after rebooting with just an updated kernel would (if it happened) be a serious issue. Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Thanks, Chris NO, it's not always safe to skip rebooting, not is it always safe to reboot, as you have exerrienced. The advise in http://www.openbsd.org/faq/faq5.html 5.2, last paragraph is there for a reason. -Otto as is the rest of FAQ 5.2, questioning why you are building the system from source, and 5.3.2, which is install the closest snapshot. So yes, there are good ways to avoid this problem -- follow the instructions. Nick.
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Mon, May 9, 2011 at 9:57 AM, Nick Holland n...@holland-consulting.net wrote: as is the rest of FAQ 5.2, questioning why you are building the system from source, and 5.3.2, which is install the closest snapshot. It's been running -current for quite some time (and the original install was from the latest snapshot), usually update every week or two, this time there were three weeks in between.
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Sun, May 08, 2011 at 02:54:21PM -0400, Chris Smith wrote: After an update to -current yesterday Internet access was lost as pf.conf could not be loaded. The error message was: pfctl: DIOCADDRULE: Operation not supported by device This error occurred after upgrading the kernel and then rebooting. After userland was brought up to date as well and the system rebooted everything was fine. The system in question was local so outside of being offline for the amount of time it took to build userland there wasn't a lot to worry about. What I'm concerned with is this being an issue on a remote system where not being able to get back in after rebooting with just an updated kernel would (if it happened) be a serious issue. Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Thanks, Chris NO, it's not always safe to skip rebooting, not is it always safe to reboot, as you have exerrienced. The advise in http://www.openbsd.org/faq/faq5.html 5.2, last paragraph is there for a reason. -Otto
Re: pfctl: DIOCADDRULE: Operation not supported by device
On 2011-05-08, at 1:54 PM, Chris Smith wrote: After an update to -current yesterday Internet access was lost as pf.conf could not be loaded. The error message was: pfctl: DIOCADDRULE: Operation not supported by device This error occurred after upgrading the kernel and then rebooting. After userland was brought up to date as well and the system rebooted everything was fine. The system in question was local so outside of being offline for the amount of time it took to build userland there wasn't a lot to worry about. What I'm concerned with is this being an issue on a remote system where not being able to get back in after rebooting with just an updated kernel would (if it happened) be a serious issue. Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Thanks, Chris Hi, Following the upgrade.html document may be the best approach. What I typically do is build the release on a system (build kernel as well as all binaries and do a make release) and then follow the upgrade.html approach for remote systems after I am sure nothing at the remote branch will break. In our case the remote branch in question is within driving distance and that makes it less risky for me but the procedure has not failed me for close to 10 years. Before 4.x I used to follow a slightly different approach (pax) but since 4.2 or so I have been following the update.html document verbatim. Vijay Vijay Sankar vsan...@foretell.ca
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Sun, 8 May 2011 14:54:21 -0400 Chris Smith obsd_m...@chrissmith.org wrote: Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Yes, just skip the reboot. Isn't adviced anymore in upgradeXX.html. Remember to save the old reboot binary as a precaution before building base when running -current or upgrading releases from source.
Re: pfctl: DIOCADDRULE: Operation not supported by device
Op 8-5-2011 21:16, roberth schreef: On Sun, 8 May 2011 14:54:21 -0400 Chris Smithobsd_m...@chrissmith.org wrote: Is there a good way to avoid this? Is it safe to skip rebooting between the kernel build and userland build? Or would it work to manually build and install pfctl before the reboot after the kernel build? Or something else that hasn't occurred to me yet? Yes, just skip the reboot. Isn't adviced anymore in upgradeXX.html. Remember to save the old reboot binary as a precaution before building base when running -current or upgrading releases from source. You are aware that this question concerns following -current? And that you are strongly advised to follow the FAQ when building -current as others already pointed out?
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Sun, 08 May 2011 21:48:25 +0200 Erik o...@vanwesten.net wrote: You are aware that this question concerns following -current? And that you are strongly advised to follow the FAQ when building -current as others already pointed out? Building from source. Got error after kernel reboot. Dude, rtfaq! Kernel and userland out of sync. Build base and reboot... Uhum. Sure that's a way to approach this. That's the supported way. With that ammount of support required. Fine with that. On the otherhand, i have been running -current for years and never have had any problem with building source with the previouse kernel (without reboot) that i can remember. Maybe my 3 digit amount of builds isn't enough or i built at the wrong states of the tree. So let me rephrase, ... Follow the FAQ and do it that way, because then you can come to the list and ask. (Like OP did.) So take my just build base without rebooting as personal advice. Never said anything about this being the project endorsed way. But it works for me, maybe it does for you, too... Don't come asking for help onlist, if you didn't follow the faq thou, might lose you karma. Just try again as the faq says and ask after that. Even if something breaks in the worst way because of not rebooting, simply updating with a snapshot will get you back on track. Concerning remote-updates, from source will run into more problems than from a known good set of tarballs. That's simple statistics, because of how many binarys are involved. (remote console access helps, but still might mess up your sla.)
Re: pfctl: DIOCADDRULE: Operation not supported by device
On Sun, May 8, 2011 at 3:25 PM, roberth rob...@openbsd.pap.st wrote: Uhum. Sure that's a way to approach this. That's the supported way. With that ammount of support required. Fine with that. I usually build the new kernel, major utilities that require the new kernel as per http://openbsd.org/faq/current.html and http://openbsd.org/upgrade*.html. Then reboot to the new kernel, and build userland. I assume the machine is out of production until it's done. On the otherhand, i have been running -current for years and never have had any problem with building source with the previouse kernel (without reboot) that i can remember. The occasional problem exists. Mostly due to a kernel call after a library is installed before the userland is upgraded. Concerning remote-updates, from source will run into more problems than from a known good set of tarballs. That's simple statistics, because of how many binarys are involved. (remote console access helps, but still might mess up your sla.) I always build release from an already upgraded master build server, so there's no potentially off binaries being distributed. jb
Re: pfctl(8) fails to correctly display rdr address pool
* Danix da...@kernel-panic.it [2010-12-26 21:40]:
Hi all,
I've made a python module for managing Packet Filter and I'm
updating it to 4.8 now; so I'm taking a close look at the pfctl
source code and I think I've stumbled upon a little bug (tested on
-current)...
To put it short:
# grep 6789 /etc/pf.conf
pass in on vic0 proto tcp from any to vic0 port 6789 rdr-to {
1.2.3.4, 1.2.3.5, 1.2.3.7 } round-robin
# pfctl -sr | grep 6789
pass in on vic0 inet proto tcp from any to 192.168.1.28 port = 6789
flags S/SA keep state rdr-to __automatic_b107482c_0 round-robin
this is correct. the pool has been turned into a table automagically.
Redirection works but pfctl(8) fails to correctly display the
redirection pool. This issue shows up only when the redirection pool
has multiple addresses and is not a table.
I suppose that (in that particular case) the addr field of the
pf_pool structure is not correctly populated in parse.y, but I can't
figure out how it should be, since a pf_addr_wrap can't represent an
address pool, but only a single address or a table...
Am I missing something?
pools don't exist any more internally. they are converted to tables at
load time.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
Re: pfctl(8) fails to correctly display rdr address pool
Danix da...@kernel-panic.it writes:
To put it short:
# grep 6789 /etc/pf.conf
pass in on vic0 proto tcp from any to vic0 port 6789 rdr-to { 1.2.3.4,
1.2.3.5, 1.2.3.7 } round-robin
# pfctl -sr | grep 6789
pass in on vic0 inet proto tcp from any to 192.168.1.28 port = 6789
flags S/SA keep state rdr-to __automatic_b107482c_0 round-robin
Redirection works but pfctl(8) fails to correctly display the
redirection pool. This issue shows up only when the redirection pool
has multiple addresses and is not a table.
This is, I think, the expected behavior. The ruleset optimizer turns
your list of addresses into a table. You could try disabling the
rulseset optimizer to see if it makes a difference, but at least on my
-current box here it doesn't seem to matter:
pe...@skapet:~$ cat danix
pass in on xl0 proto tcp from any to xl0 port 6789 rdr-to { 1.2.3.4, 1.2.3.5,
1.2.3.7 } round-robin
pe...@skapet:~$ sudo pfctl -vnf danix
table __automatic_0 const { 1.2.3.4 1.2.3.5 1.2.3.7 }
table __automatic_1 const { 1.2.3.4 1.2.3.5 1.2.3.7 }
pass in on xl0 inet proto tcp from any to 213.187.179.198 port = 6789 flags
S/SA keep state rdr-to __automatic_0 round-robin
pe...@skapet:~$ sudo pfctl -o none -vnf danix
table __automatic_0 const { 1.2.3.4 1.2.3.5 1.2.3.7 }
table __automatic_1 const { 1.2.3.4 1.2.3.5 1.2.3.7 }
pass in on xl0 inet proto tcp from any to 213.187.179.198 port = 6789 flags
S/SA keep state rdr-to __automatic_0 round-robin
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
Remember to set the evil bit on all malicious network traffic
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: pfctl -a anchorname -F all does not clear states AND pfctl -anchorname -F states clears all states even ones not created by rules in anchorname
On Sat, Jul 3, 2010 at 9:55 AM, Henning Brauer lists-open...@bsws.de wrote: # pfctl -a atelonly -F all -Fall with -a makes no sense whatsoever. -Fa clears a lot of non-anchor specific shit. we'll make pfctl bail on that combo. ok :-) So what would be the best way to flush all the states created by a specific anchor's rules when rules in that anchor is flushed? Thanks --Siju
Re: pfctl -a anchorname -F all does not clear states AND pfctl -anchorname -F states clears all states even ones not created by rules in anchorname
# pfctl -a atelonly -F all -Fall with -a makes no sense whatsoever. -Fa clears a lot of non-anchor specific shit. we'll make pfctl bail on that combo. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfctl from today seems to be somehow messed up / DIOCSETSTATUSIF
This sounds a lot like a kernel/userland mismatch. Please update both kernel and userland from the same snapshot and try again. On Thu, Jul 01, 2010 at 03:33:56AM +0200, Laurent CARON wrote: Hi, I did upgrade one of my BGP routers today with latest current. Upon reboot I have no network. pfctl returns the following error: # pfctl -f /etc/pf.conf pfctl: DIOCSETSTATUSIF A default drop all in ruleset is loaded. If I rollback to previous pfctl it loads my rules fine. If i want to load rules correctly with newer pfctl I have to remove: set loginterface $EXTIF001 from /etc/pf.conf Thanks --
Re: pfctl from today seems to be somehow messed up / DIOCSETSTATUSIF
On 01/07/2010 17:54, Ryan McBride wrote: This sounds a lot like a kernel/userland mismatch. Please update both kernel and userland from the same snapshot and try again. I always upgrade both at the same time. Kernel + userland are in synch
Re: pfctl from today seems to be somehow messed up
On 01/07/2010 21:21, Ryan McBride wrote: On Thu, Jul 01, 2010 at 09:00:18PM +0200, Laurent CARON wrote: On 01/07/2010 17:54, Ryan McBride wrote: This sounds a lot like a kernel/userland mismatch. Please update both kernel and userland from the same snapshot and try again. I always upgrade both at the same time. Kernel + userland are in synch I'm unable to reproduce this here. Can you give me the output of the following commands: sysctl kern.version OpenBSD 4.7-current (GENERIC.MP) #10: Wed Jun 30 22:07:04 CEST 2010 r...@bgpgw-002.lncsa.com:/usr/src/sys/arch/amd64/compile/GENERIC.MP pfctl -Fa -i lo0 # pfctl -Fa -i lo0 rules cleared 0 tables deleted. pfctl: don't specify an interface with -Fall usage: pfctl [-deghnqrvz] [-a anchor] [-D macro=value] [-F modifier] [-f file] [-i interface] [-K host | network] [-k host | network | label | id] [-L statefile] [-o level] [-p device] [-S statefile] [-s modifier] [-t table -T command [address ...]] [-x level] This incidentally made my other router (running openBGPd) crash with: uvm_fault(0x80cc7320, 0xdeafb000, 0, 1) - e page fault trap, code=0 Stopped at pfsync_in_clr+0x123:movq 0x10(%rbx),%rax Laurent
Re: pfctl from today seems to be somehow messed up
On Thu, Jul 01, 2010 at 10:15:26PM +0200, Laurent CARON wrote: This incidentally made my other router (running openBGPd) crash with: uvm_fault(0x80cc7320, 0xdeafb000, 0, 1) - e page fault trap, code=0 Stopped atpfsync_in_clr+0x123:movq 0x10(%rbx),%rax Interesting. Do you have the 'ps' and 'trace' output from that?
Re: pfctl from today seems to be somehow messed up
On 01/07/2010 22:21, Ryan McBride wrote: On Thu, Jul 01, 2010 at 10:15:26PM +0200, Laurent CARON wrote: This incidentally made my other router (running openBGPd) crash with: uvm_fault(0x80cc7320, 0xdeafb000, 0, 1) - e page fault trap, code=0 Stopped at pfsync_in_clr+0x123:movq 0x10(%rbx),%rax Interesting. Do you have the 'ps' and 'trace' output from that? Unfortunately not since the machine is remote this won't be easy. Currently compiling today's cvs on this Do you have any clue where it might come from ?
Re: pfctl: Cannot allocate memory and spamd-setup -bd
On 21-06-2010 22:44, Ruy Bento wrote: ... My question is: In this small env. (100 MB - RAM) I need to change the Kernel memory or other sysctl value, which one? Thank you for all your replys and comments. In 4.6 everything work perfect, so what happen 4.6 - 4.7, it need more mem? And if I can: set limit table-entries 500 And with all daemons load in mem I have: 36 processes: 35 idle, 1 on processor CPU states: 0.5% user, 0.0% nice, 0.0% system, 0.0% interrupt, 99.5% idle Memory: Real: 20M/45M act/tot Free: 41M Swap: 0K/161M used/tot What a perfect world So with 41MB free i could load more kernel ... My other servers: Core 2, i5, i7 with lots of mem (4 or 8 GB). This and the SUN its to test and see the OpenBSD continue to run happily for ever :-) :-) Thank you for your great effort and work. Best regards, Ruy Benton
Re: pfctl: Cannot allocate memory and spamd-setup -bd
On 2010-06-21, Ruy Bento r...@madeira.dyndns.org wrote: spamd_black=YES # set to YES to run spamd without greylisting you don't want blacklist-only mode if you have limited RAM.
Re: pfctl: Cannot allocate memory and spamd-setup -bd
avail mem = 87961600 (83MB) with:uatraps:china:korea: - pfctl: Cannot allocate memory. Not enough kernel memory.
Re: pfctl: Cannot allocate memory and spamd-setup -bd
Ruy Bento wrote: Hi, I have a server with: OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium II (GenuineIntel 686-class, 512KB L2 cache) 234MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX real mem = 100233216 (95MB) avail mem = 87961600 (83MB) With sendmail and spamd in blacklist (/etc/rc.conf.local): spamd_flags=-bv # for normal use: and see spamd(8) spamd_black=YES # set to YES to run spamd without greylisting spamlogd_flags=-i rl0 # use eg. -i interface and see spamlogd(8) /etc/mail/spamd.conf: with:china:korea: it's ok with:uatraps:china:korea: - pfctl: Cannot allocate memory. or :nixspam::china:korea: - pfctl: Cannot allocate memory. with the shell /usr/libexec/spamd-setup -bd vmstat -m _ pfrke_plain 92196163 1175 429 39435 168 0 88 . In use 2275K, total allocated 3808K; utilization 59.7% pstat -s Device 512-blocks UsedAvail Capacity Priority swap_device 3299800 329980 0%0 In OpenBSD 4.6 the same hardware and config ... no problem. I try several setups: Core2 Duo with 1 GB RAM (the same config) 4.6 and 4.7, works. But ... 4.6 and 4.7 with 128MB, 4.7 give the same error: pfctl: Cannot allocate memory. So I change set limit tables 1 set limit table-entries 500 in pf.conf, but no luck. My question is: In this small env. (100 MB - RAM) I need to change the Kernel memory or other sysctl value, which one? I work with OpenBSd for more 10 years Intel, AMD, PPC - Webhosting, Servers, Firewalls. Thank you for your great effort and work. Best regards, Ruy Benton OK, I'm game to ask after seeing Theo's response. I actually have some equipment like this, not that I use it this way, normally. So, change a setting or rewrite things to fit better in this small memory space? I was actually using that laptop to make some pretty extensive website changes last year, while traveling with little internet access. Filled those boring hours while I waked up hours before the world back then. No regrets having brought that old thing with me! :) Chris Bennett
Re: pfctl: Cannot allocate memory and spamd-setup -bd
OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium II (GenuineIntel 686-class, 512KB L2 cache) 234MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX real mem = 100233216 (95MB) avail mem = 87961600 (83MB) pstat -s Device 512-blocks UsedAvail Capacity Priority swap_device 3299800 329980 0%0 OK, I'm game to ask after seeing Theo's response. I actually have some equipment like this, not that I use it this way, normally. You're kidding. So, change a setting or rewrite things to fit better in this small memory space? There is no solution. The tables are in kernel memory. The kernel isn't going to go out to swap space to check if packets should flow through. Would anyone want that? No, of course not. I was actually using that laptop to make some pretty extensive website changes last year, while traveling with little internet access. Filled those boring hours while I waked up hours before the world back then. No regrets having brought that old thing with me! :) Laptops tend to have more than 83MB of available memory.
Re: pfctl: Cannot allocate memory and spamd-setup -bd
Theo de Raadt wrote: OpenBSD 4.7 (GENERIC) #558: Wed Mar 17 20:46:15 MDT 2010 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel Pentium II (GenuineIntel 686-class, 512KB L2 cache) 234MHz cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX real mem = 100233216 (95MB) avail mem = 87961600 (83MB) pstat -s Device 512-blocks UsedAvail Capacity Priority swap_device 3299800 329980 0%0 OK, I'm game to ask after seeing Theo's response. I actually have some equipment like this, not that I use it this way, normally. You're kidding. So, change a setting or rewrite things to fit better in this small memory space? There is no solution. The tables are in kernel memory. The kernel isn't going to go out to swap space to check if packets should flow through. Would anyone want that? No, of course not. I was actually using that laptop to make some pretty extensive website changes last year, while traveling with little internet access. Filled those boring hours while I waked up hours before the world back then. No regrets having brought that old thing with me! :) Laptops tend to have more than 83MB of available memory. No kidding, that sucker only has 128MB, after I added memory. And I'm serious, I really did feel perfectly safe bringing it to parts unknown, where the locals said I really shouldn't be carrying it around in the streets. I still have that antique, right here, working alongside a real computer. But anyway, thanks for answering the question clearly Chris Bennett
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
2010/6/1 Uwe Dippel udip...@uniten.edu.my To: Philip Guenther guent...@gmail.com Date: Tue, 01 Jun 2010 16:07:47 +0800 Subject: Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT On 06/01/2010 05:32 AM, Philip Guenther wrote: Was there a common thread to what did turn up? My recall is that basically every time people get Operation not supported by device errors from pfctl, it's because their userland and kernel don't match. Review your upgrade procedure, because it's clearly broken. Thanks for your help, seriously. And I don't want to start arguing, not at all, but this is one of my production boxes, without access, and I have been running the boot.bsd.rd updates since 3.8 twice a year. Being production, I diligently watched, and saw with my own eyes the asterisks advancing. I can only say, I followed standard procedures; if just for my own sanity. I *am* losing the latter, because it seems that all files in /sbin are identical to my box still on 4.6; though something has happened to them yesterday: [snip] Probably no help, but I had similar happen to me upgrading 4.5-4.6 a few months ago. Similar problem with pftcl after a diligent upgrade, and like you I have been following the upgrade procedure diligently since 3.something. I checked the timestamp on pfctl, it didn't seem right so I built from source and installed and the issue went away, so I assumed I had something wrong and thought nothing of it as generally if OpenBSD f*cks up it's down to me and not the developers ;-) I'd be interested to see if there's a common thread here, particularly before I upgrade this box to 4.7 which (like yours) is a remote box which will be upgraded over serial.
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Damon McMahon damon.mcmahon at gmail.com writes: Probably no help, but I had similar happen to me upgrading 4.5-4.6 a few months ago. Similar problem with pftcl after a diligent upgrade, and like you I have been following the upgrade procedure diligently since 3.something. I checked the timestamp on pfctl, it didn't seem right so I built from source and installed and the issue went away, so I assumed I had something wrong and thought nothing of it as generally if OpenBSD f*cks up it's down to me and not the developers Thanks so much! You saved my upcoming weekend. So I am not hallucinating. Of course, never expected the developers to solve *my* problems; only wanted to exclude a bug hitting others. You're better than me, and I only learned yesterday that the install-set files come back with the time stamp of creation. Had I known this, a lot could have been spared, because my second post already showed a lot of bad time stamps in /sbin. This 'strange' time stamp (see my earlier post) of May 31 20:28 still prevails in a number of files on my box: # ls -lR | grep May 31 20:28 | wc -l 153 , *after* I replaced the differing files in /sbin. I'd be interested to see if there's a common thread here, particularly before I upgrade this box to 4.7 which (like yours) is a remote box which will be upgraded over serial. I guess so. By now I'll have the list of the files affecting amd64 and i386 in these cases, and you should be able to correct everything using these lists. Maybe interesting enough, this timestamp was *not* when I upgraded the sets. It was the time when I upgraded the packages, respectively applied the patches. But from now on I'll be mum (I hope I can!) on this topic until a complete explanation is available. Uwe
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
On 06/01/2010 05:32 AM, Philip Guenther wrote:
Was there a common thread to what did turn up? My recall is that
basically every time people get Operation not supported by device
errors from pfctl, it's because their userland and kernel don't match.
Review your upgrade procedure, because it's clearly broken.
Thanks for your help, seriously. And I don't want to start arguing, not
at all, but this is one of my production boxes, without access, and I
have been running the boot.bsd.rd updates since 3.8 twice a year.
Being production, I diligently watched, and saw with my own eyes the
asterisks advancing. I can only say, I followed standard procedures; if
just for my own sanity.
I *am* losing the latter, because it seems that all files in /sbin are
identical to my box still on 4.6; though something has happened to them
yesterday:
(this is my 4.6-box, upgraded only on April 19th:)
$ ls -l /sbin/p*
-r-xr-xr-x 1 root bin 492664 Apr 19 13:44 /sbin/pfctl
-r-xr-xr-x 1 root bin 390264 Apr 19 13:44 /sbin/pflogd
-r-sr-xr-x 1 root bin 210040 Apr 19 13:44 /sbin/ping
-r-sr-xr-x 1 root bin 234616 Apr 19 13:44 /sbin/ping6
(This is my box upgraded yesterday, May 31st, to 4.7:)
# ls -l /sbin/p*
-r-xr-xr-x 1 root bin 492664 May 31 20:28 /sbin/pfctl
-r-xr-xr-x 1 root bin 390264 May 31 20:28 /sbin/pflogd
-r-sr-xr-x 1 root bin 210040 May 31 20:28 /sbin/ping
-r-sr-xr-x 1 root bin 234616 May 31 20:28 /sbin/ping6
So it did something, from where did it get the old files? I guess not
from a mistake on my side, because I accepted the upgrade path in the
Upgrade shell. Plus:
OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
I never copied any myself down here. As I mentioned, production, upgrade
twice per year through serial console.
And now my sanity seems to fade: I did the same to one of my i386-boxen,
and exactly the same happens there!! (Please, now I am starting to lose
ground under my feet!)
This is after the update to 4.7, i386, in front of the screen!:
(mnt is /altroot, mounted just now to check; since pfctl did the same
thing, again, here)
# ls -l /mnt/sbin/p*
-r-xr-xr-x 1 root bin 422648 Apr 19 12:51 /mnt/sbin/pfctl
-r-xr-xr-x 1 root bin 328440 Apr 19 12:51 /mnt/sbin/pflogd
-r-sr-xr-x 1 root bin 180984 Apr 19 12:51 /mnt/sbin/ping
-r-sr-xr-x 1 root bin 197368 Apr 19 12:51 /mnt/sbin/ping6
# ls -l /sbin/p*
-r-xr-xr-x 1 root bin 422648 Jun 1 12:54 /sbin/pfctl
-r-xr-xr-x 1 root bin 328440 Jun 1 12:54 /sbin/pflogd
-r-sr-xr-x 1 root bin 180984 Jun 1 12:54 /sbin/ping
-r-sr-xr-x 1 root bin 197368 Jun 1 12:54 /sbin/ping6
A mix-up of versions? I don't think so, because
$ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/base47.tgz ./sbin/pfctl
$ md5 sbin/pfctl
MD5 (sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4
exactly what you had.
Now I start to not exclude a bug any longer. Maybe under some
circumstances, the files are not overwritten, but touched; or whatnot.?
This leaves me with two questions:
1. How to debug what goes on?
2. (and more important for me): What to do? Should I tar xzvphf
{file}47.tgz; or try an new upgrade?
Uwe
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
On Tue, Jun 01, 2010 at 04:07:47PM +0800, Uwe Dippel wrote:
On 06/01/2010 05:32 AM, Philip Guenther wrote:
Was there a common thread to what did turn up? My recall is that
basically every time people get Operation not supported by device
errors from pfctl, it's because their userland and kernel don't match.
Review your upgrade procedure, because it's clearly broken.
Thanks for your help, seriously. And I don't want to start arguing,
not at all, but this is one of my production boxes, without access,
and I have been running the boot.bsd.rd updates since 3.8 twice a
year.
Being production, I diligently watched, and saw with my own eyes the
asterisks advancing. I can only say, I followed standard procedures;
if just for my own sanity.
I *am* losing the latter, because it seems that all files in /sbin
are identical to my box still on 4.6; though something has happened
to them yesterday:
(this is my 4.6-box, upgraded only on April 19th:)
$ ls -l /sbin/p*
-r-xr-xr-x 1 root bin 492664 Apr 19 13:44 /sbin/pfctl
-r-xr-xr-x 1 root bin 390264 Apr 19 13:44 /sbin/pflogd
-r-sr-xr-x 1 root bin 210040 Apr 19 13:44 /sbin/ping
-r-sr-xr-x 1 root bin 234616 Apr 19 13:44 /sbin/ping6
(This is my box upgraded yesterday, May 31st, to 4.7:)
# ls -l /sbin/p*
-r-xr-xr-x 1 root bin 492664 May 31 20:28 /sbin/pfctl
-r-xr-xr-x 1 root bin 390264 May 31 20:28 /sbin/pflogd
-r-sr-xr-x 1 root bin 210040 May 31 20:28 /sbin/ping
-r-sr-xr-x 1 root bin 234616 May 31 20:28 /sbin/ping6
So it did something, from where did it get the old files? I guess
not from a mistake on my side, because I accepted the upgrade path
in the Upgrade shell. Plus:
OpenBSD 4.7 (GENERIC.MP) #130: Wed Mar 17 20:48:50 MDT 2010
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
I never copied any myself down here. As I mentioned, production,
upgrade twice per year through serial console.
And now my sanity seems to fade: I did the same to one of my
i386-boxen, and exactly the same happens there!! (Please, now I am
starting to lose ground under my feet!)
This is after the update to 4.7, i386, in front of the screen!:
(mnt is /altroot, mounted just now to check; since pfctl did the
same thing, again, here)
# ls -l /mnt/sbin/p*
-r-xr-xr-x 1 root bin 422648 Apr 19 12:51 /mnt/sbin/pfctl
-r-xr-xr-x 1 root bin 328440 Apr 19 12:51 /mnt/sbin/pflogd
-r-sr-xr-x 1 root bin 180984 Apr 19 12:51 /mnt/sbin/ping
-r-sr-xr-x 1 root bin 197368 Apr 19 12:51 /mnt/sbin/ping6
# ls -l /sbin/p*
-r-xr-xr-x 1 root bin 422648 Jun 1 12:54 /sbin/pfctl
-r-xr-xr-x 1 root bin 328440 Jun 1 12:54 /sbin/pflogd
-r-sr-xr-x 1 root bin 180984 Jun 1 12:54 /sbin/ping
-r-sr-xr-x 1 root bin 197368 Jun 1 12:54 /sbin/ping6
A mix-up of versions? I don't think so, because
$ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/base47.tgz ./sbin/pfctl
$ md5 sbin/pfctl
MD5 (sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4
exactly what you had.
Now I start to not exclude a bug any longer. Maybe under some
circumstances, the files are not overwritten, but touched; or
whatnot.?
This leaves me with two questions:
1. How to debug what goes on?
2. (and more important for me): What to do? Should I tar xzvphf
{file}47.tgz; or try an new upgrade?
Just untarring the release should work, but it's still odd. At least the
md5sum of pfctl matches what I just downloaded, so that seems fine; did
you actually use *that* tarball, though? (Note that the right pfctl
binary is 500856 bytes long.)
Are you sure that you upgraded the right disk?
Joachim
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Joachim Schipper joachim at joachimschipper.nl writes: Just untarring the release should work, but it's still odd. At least the md5sum of pfctl matches what I just downloaded, so that seems fine; did you actually use *that* tarball, though? (Note that the right pfctl binary is 500856 bytes long.) Are you sure that you upgraded the right disk? Yep. When I untar the files (I have them locally on a webserver: ftp://metalab.uniten.edu.my/pub/OpenBSD/4.7/ all files come out perfectly well, as above. I did the upgrades using this URL; I am sure it were these files, because they only exist once locally (the speed with which the updates were done is proof that I used these local resources, downloaded by myself). In the Upgrade procedure I only added the (internal) IP for that server, accepting all else. And it can't be 4.6 that I used, kind of, because the installed (upgraded) kernel is 4.7. I need to repeat, this is a remote production machine with serial access. I have no desire ever to do anything not along clear procedures, and I followed the Upgrade Guide 4.6-4.7 meticulously (system administration is part of my job description), even ticking off point after point on the printout of the upgrade guide. So something was done to the files, at least they have the new time stamp, and some files have actually been installed correctly (kernels); as the hashsums show. So, finally, I *was* in the right directory and installed to the correct disk. Here are the kernels, on the first machine, that has seemingly the previous 'base' throughout: # cksum -a sha256 bsd SHA256 (bsd) = e2af09ed48d1d94bec27aa4c18ffa6172d8435a190c3abecae53d26940ed9536 # cksum -a sha256 bsd.sp SHA256 (bsd.sp) = a34175b766d6ea9cefcc0903efa51c4dc3d87018b1e2f85c2333133ed25e9ff4 Now I wonder if the problem was with the untar? Maybe all sets have not been installed properly? Next, I will have to identify for each and every set, a sample file, and check if it is the previous one or the recent one. Very, very strange ... Thanks so much, you did actually help me a step further, Uwe
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Joachim Schipper joac...@joachimschipper.nl writes: On Tue, Jun 01, 2010 at 04:07:47PM +0800, Uwe Dippel wrote: On 06/01/2010 05:32 AM, Philip Guenther wrote: Review your upgrade procedure, because it's clearly broken. Thanks for your help, seriously. And I don't want to start arguing, not at all, but this is one of my production boxes, without access, and I have been running the boot.bsd.rd updates since 3.8 twice a year. Being production, I diligently watched, and saw with my own eyes the asterisks advancing. I can only say, I followed standard procedures; if just for my own sanity. I *am* losing the latter, because it seems that all files in /sbin are identical to my box still on 4.6; though something has happened to them yesterday: Just untarring the release should work, but it's still odd. At least the md5sum of pfctl matches what I just downloaded, so that seems fine; did you actually use *that* tarball, though? (Note that the right pfctl binary is 500856 bytes long.) Are you sure that you upgraded the right disk? I heard that some mirrors had corrupted tarball. Maybe it is related. -- Guillaume Pinot http://www.irccyn.ec-nantes.fr/~pinot/ + Les grandes personnes ne comprennent jamais rien toutes seules, et c'est fatigant, pour les enfants, de toujours leur donner des explications... ; -- Antoine de Saint-Exupiry, Le Petit Prince () ASCII ribbon campaign -- Against HTML e-mail /\ http://www.asciiribbon.org -- Against proprietary attachments
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
On 2010-06-01, TeXitoi texitoi+n...@texitoi.eu wrote: I heard that some mirrors had corrupted tarball. Huh?
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Stuart Henderson s...@spacehopper.org writes: On 2010-06-01, TeXitoi texitoi+n...@texitoi.eu wrote: I heard that some mirrors had corrupted tarball. Huh? http://thread.gmane.org/gmane.os.openbsd.french/2168 (in french) it was ports.tar.gz, here. -- Guillaume Pinot http://www.irccyn.ec-nantes.fr/~pinot/ + Les grandes personnes ne comprennent jamais rien toutes seules, et c'est fatigant, pour les enfants, de toujours leur donner des explications... ; -- Antoine de Saint-Exupiry, Le Petit Prince () ASCII ribbon campaign -- Against HTML e-mail /\ http://www.asciiribbon.org -- Against proprietary attachments
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Download again the tar files from official mirrors and try again the upgrade. 2010/6/1 Uwe Dippel udip...@uniten.edu.my: Joachim Schipper joachim at joachimschipper.nl writes: Just untarring the release should work, but it's still odd. At least the md5sum of pfctl matches what I just downloaded, so that seems fine; did you actually use *that* tarball, though? (Note that the right pfctl binary is 500856 bytes long.) Are you sure that you upgraded the right disk? Yep. When I untar the files (I have them locally on a webserver: ftp://metalab.uniten.edu.my/pub/OpenBSD/4.7/ all files come out perfectly well, as above. I did the upgrades using this URL; I am sure it were these files, because they only exist once locally (the speed with which the updates were done is proof that I used these local resources, downloaded by myself). In the Upgrade procedure I only added the (internal) IP for that server, accepting all else. And it can't be 4.6 that I used, kind of, because the installed (upgraded) kernel is 4.7. I need to repeat, this is a remote production machine with serial access. I have no desire ever to do anything not along clear procedures, and I followed the Upgrade Guide 4.6-4.7 meticulously (system administration is part of my job description), even ticking off point after point on the printout of the upgrade guide. So something was done to the files, at least they have the new time stamp, and some files have actually been installed correctly (kernels); as the hashsums show. So, finally, I *was* in the right directory and installed to the correct disk. Here are the kernels, on the first machine, that has seemingly the previous 'base' throughout: # cksum -a sha256 bsd SHA256 (bsd) = e2af09ed48d1d94bec27aa4c18ffa6172d8435a190c3abecae53d26940ed9536 # cksum -a sha256 bsd.sp SHA256 (bsd.sp) = a34175b766d6ea9cefcc0903efa51c4dc3d87018b1e2f85c2333133ed25e9ff4 Now I wonder if the problem was with the untar? Maybe all sets have not been installed properly? Next, I will have to identify for each and every set, a sample file, and check if it is the previous one or the recent one. Very, very strange ... Thanks so much, you did actually help me a step further, Uwe
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
From: Gonzalo Rodriguez [gonz...@sepp0.com.ar]
Subject: Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Download again the tar files from official mirrors and try again the upgrade.
Thanks, Gonzalo,
but the files (sets) are correct according to their SHA256.
I have actually advanced with the problem, and inspired by Joachim's
intervention.
It seems all sets of 4.7 were installed during the otherwise flawless upgrade,
except of base47.tar.
I selected randomly files from all tar-packages (sets) that changed from 4.6
to 4.7, and compared those installed in the machine upgraded to 4.7 with those
from the tar archives ('sets'). Except of base47, everything looks fine
(identical). Only, as far as I can make out now, all (??) files of base47 were
not installed.
It is late here, I'm going to sleep, but tomorrow I'll try the same on the
i386. And chances are, the same thing happened there as well. At least the
re-occurrence of the failure of pfctl suggests so, as of now.
I really wonder, under which circumstances the installer would fail to deposit
its files in the foreseen locations; for one, the first, archive (set)?
My question remains, since this is a production machine and I don't feel like
tinkering with it: Since it is one set that failed to upgrade: what is
recommended: a whole new upgrade, or just extraction of that set into the
machine?
(I am so happy that it basically works, The only thing failing regularly until
now is the communication with apcupsd, which was always flawless. It fails
with apcupsd[18529]: apcserver: accept error. ERR=Software caused. I guess
it has to make with some out-of-sync files of the base46 set within a 4.7
machine. I hope so.)
Uwe
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
On 2010-06-01, TeXitoi texitoi+n...@texitoi.eu wrote: Stuart Henderson s...@spacehopper.org writes: On 2010-06-01, TeXitoi texitoi+n...@texitoi.eu wrote: I heard that some mirrors had corrupted tarball. Huh? http://thread.gmane.org/gmane.os.openbsd.french/2168 .. it was ports.tar.gz, here. ok, that's better. Rather than just throwing out I heard that some mirrors had corrupted tarball it would have been better to give the details so people have some idea if they might have been affected. (Though note that the installer does warn you if the checksum of the set doesn't match the checksum stored in the installer, so people would have noticed quite clearly if this affected the main *47.tgz files). (in french) given the list it was posted on, I would be disappointed if it wasn't :)
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
Joachim Schipper joachim at joachimschipper.nl writes: Just untarring the release should work, but it's still odd. At least the md5sum of pfctl matches what I just downloaded, so that seems fine; did you actually use *that* tarball, though? (Note that the right pfctl binary is 500856 bytes long.) Make this thread closed. I manually 'upgraded' (only) the file /sbin/pfctl from exactly the archive used at the upgrade 4.6-4.7 procedure, and everything 'pfctl' works fine. This leaves us with the problem of the failed upgrade procedure, twice now. Thanks to all contributors in this thread! Uwe
Re: pfctl not working in 4.7: DIOCBEGINADDRS and DIOCXCOMMIT
On Mon, May 31, 2010 at 6:20 AM, Uwe Dippel udip...@uniten.edu.my wrote: (I searched Google, but not much turned up.) Was there a common thread to what did turn up? My recall is that basically every time people get Operation not supported by device errors from pfctl, it's because their userland and kernel don't match. Since I upgraded to 4.7; what I get is: # pwd /etc # cat pf.conf # works? # pfctl -f pf.conf.47 pfctl: DIOCBEGINADDRS: Operation not supported by device That ioctl (DIOCBEGINADDRS) was removed between 4.6 and 4.7. Ergo, that is *NOT* a 4.7 pfctl binary. # which pfctl /sbin/pfctl # md5 /sbin/pfctl MD5 (/sbin/pfctl) = 3e1fa4f69809adff432f9da62010a6a7 (this is amd64) $ tar xzf /home/ftp/pub/OpenBSD/4.7/amd64/base47.tgz ./sbin/pfctl $ md5 sbin/pfctl MD5 (sbin/pfctl) = 7720c9a4dc100fe29d2d3c4a16954eb4 Review your upgrade procedure, because it's clearly broken. Philip Guenther
Re: pfctl(8): unclear docs
* Toni Mueller openbsd-m...@oeko.net [2010-03-15 12:59]: Not using -R is not too good, either, as on this particular box, reloading everything results in a severance of all existing connections. I don't believe you. pfctl -f /etc/pf.conf doesn't do that. ok, shouldn't, but I don't see where that could break. A clarification in the docs is imho the way to go. no, we'll kill that bullshit, soon. it is just leftover pf must be ipf alike goo. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfctl(8): unclear docs
* Toni Mueller openbsd-m...@oeko.net [2010-03-15 10:52]:
I've just run into the following problem on a 4.6 box:
/etc/pf.conf (excerpt):
table rfc1918 const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
block out on $extif from rfc1918
# /sbin/pfctl -F rules -R -f pf.conf
rules cleared
pfctl: Must enable table loading for optimizations
# /sbin/pfctl -s r
#
Imho, this interaction should be documented in the man page. One needs
to specify '-Tl', or else no rules will be loaded.
-A, -O, -R are bullshit and I'll happily remove them. soon.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting
Re: pfctl(8): unclear docs
Hi, On Wed, 17.03.2010 at 16:24:42 +0100, Henning Brauer lists-open...@bsws.de wrote: -A, -O, -R are bullshit and I'll happily remove them. soon. that's ok with me. I thought that changing the docs was the less-intrusive thing to do, and I have no experience with ipf, so that certainly wasn't on my mind. TIA! -- Kind regards, --Toni++
Re: pfctl(8): unclear docs
On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote: Hi, On Mon, 15.03.2010 at 13:04:04 +, Jason McIntyre j...@kerhand.co.uk wrote: doesn;t Other rules and options are ignored. already cover this? may be. But then, you are possibly only too deeply entrenched in this stuff to see the problem. it is always possible, but i don't think so in this case. i didn't honestly know about this behaviour until reading your mail. now i have read your mail, and pfctl(8), and think that we have it covered. we have to strike a balance somewhere between documenting behaviour and not bogging ourselves down in answering every possible question. i admit that balance is somewhat arbitrary. but you, the reader, have some responsibility to go digging. and to be surprised too sometimes. so i'm asking myself whether your diff improves what we have. i don;t think it does. it's just my opinion - we cannot call wrong or right here. furthermore, since -T has a load command, should we really expect -R to load tables? Should it really need to? My guess was that tables would usually have been loaded already when one goes to selectively reloads the rules, and either of spelling out that they need to be loaded explicitly, stating that, by default, the already-loaded tables are being used, or that they are being ignored, or that the whole command fails would imho be a good thing. i think what you're looking at is the side-effect of tables being hacked into pf. it may be that you can see inconsistencies, i don't know. maybe just tell yourself that when you use pfctl to load rules, it will only load rules, not other stuff. like the doc says. Ok. I go out on a limb and say that explicit is better than implicit, in a lot of cases, and would welcome the short explanation OR the modification of the command to also load tables (which would require amending the man page, too). I admit that I was unaware of the rule optimizer until it bit me into my bottom half. I mean, I usually don't care, from a user perspective, whether there is something optimizing my stuff, and consider this kind of breakage as a (an almost) hidden gotcha. An optimizer (or any other such device) which is on by default and claims to not change semantics, should imho be transparent to the user, but this one isn't. If you have other uses of disabling the optimizer except for debugging pf, I'd really like to hear. sorry, you've lost me with the optimiser stuff ;) why are you discussing that? jmc
Re: pfctl(8): unclear docs
Hi, On Tue, 16.03.2010 at 07:37:42 +0001, Jason McIntyre j...@kerhand.co.uk wrote: On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote: An optimizer (or any other such device) which is on by default and claims to not change semantics, should imho be transparent to the user, but this one isn't. If you have other uses of disabling the optimizer except for debugging pf, I'd really like to hear. sorry, you've lost me with the optimiser stuff ;) why are you discussing that? ok, I'll try again: matteo pointed me to an article which says that the problem can be bypassed by using an option to pfctl that disables the optimiser, which is enabled by default. I think that any device that automatically works on the user's input should not alter the documented semantics of what the user input, and on which the user relies. On the contrary, such devices should imho be transparent to the user, but obviously, this optimiser isn't because its use is not orthogonal to the other options of 'pfctl'. Also (I didn't mention this before), since the use of tables is advocated in about any docs (counting statements on this list in for this purpose) that I've read so far, with the optimiser being on by default, using '-R' alone should presently be impossible in the majority of real-world use cases. Therefore I advocate changing the documentation or the implementation to highlight this case of non-orthogonality. Better now? -- Kind regards, --Toni++
Re: pfctl(8): unclear docs
2010/3/16 Toni Mueller openbsd-m...@oeko.net Hi, On Tue, 16.03.2010 at 07:37:42 +0001, Jason McIntyre j...@kerhand.co.uk wrote: On Mon, Mar 15, 2010 at 10:35:23PM +0100, Toni Mueller wrote: An optimizer (or any other such device) which is on by default and claims to not change semantics, should imho be transparent to the user, but this one isn't. If you have other uses of disabling the optimizer except for debugging pf, I'd really like to hear. sorry, you've lost me with the optimiser stuff ;) why are you discussing that? ok, I'll try again: matteo pointed me to an article which says that the problem can be bypassed by using an option to pfctl that disables the optimiser, which is enabled by default. I think that any device that automatically works on the user's input should not alter the documented semantics of what the user input, and on which the user relies. On the contrary, such devices should imho be transparent to the user, but obviously, this optimiser isn't because its use is not orthogonal to the other options of 'pfctl'. Also (I didn't mention this before), since the use of tables is advocated in about any docs (counting statements on this list in for this purpose) that I've read so far, with the optimiser being on by default, using '-R' alone should presently be impossible in the majority of real-world use cases. Therefore I advocate changing the documentation or the implementation to highlight this case of non-orthogonality. Better now? -- Kind regards, --Toni++ Hi all, Toni, the article says that optimizer is enable by default on OpwnBSD 4.2 thus you don't need to pass option -R to pfctl. If you pass that option you get the warning. Best regards. -- Matteo Filippetto
Re: pfctl(8): unclear docs
2010/3/15 Toni Mueller openbsd-m...@oeko.net
Hi,
I've just run into the following problem on a 4.6 box:
/etc/pf.conf (excerpt):
table rfc1918 const { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 }
block out on $extif from rfc1918
# /sbin/pfctl -F rules -R -f pf.conf
rules cleared
pfctl: Must enable table loading for optimizations
# /sbin/pfctl -s r
#
Imho, this interaction should be documented in the man page. One needs
to specify '-Tl', or else no rules will be loaded.
TIA!
Kind regards,
--Toni++
Hi,
for me it works good ... just don't use -R option
http://kerneltrap.org/mailarchive/openbsd-misc/2007/4/6/147502
--
Matteo Filippetto
Re: pfctl(8): unclear docs
Hi, On Mon, 15.03.2010 at 12:22:35 +0100, matteo filippetto matteo.filippe...@gmail.com wrote: for me it works good ... just don't use -R option http://kerneltrap.org/mailarchive/openbsd-misc/2007/4/6/147502 thanks for this link. Not using -R is not too good, either, as on this particular box, reloading everything results in a severance of all existing connections. A clarification in the docs is imho the way to go. My 'nroff' is almost nonexistant, but here's a diff: --- pfctl.8.origWed Jun 11 09:23:36 2008 +++ pfctl.8 Mon Mar 15 12:53:04 2010 @@ -354,7 +354,9 @@ Only print errors and warnings. .It Fl R Load only the filter rules present in the rule file. -Other rules and options are ignored. +Other rules and options are ignored. If you are using +tables, you need to also specify one of -T load or +-o none. .It Fl r Perform reverse DNS lookups on states when displaying them. .It Fl s Ar modifier Kind regards, --Toni++
Re: pfctl(8): unclear docs
On Mon, Mar 15, 2010 at 12:54:09PM +0100, Toni Mueller wrote: Not using -R is not too good, either, as on this particular box, reloading everything results in a severance of all existing connections. A clarification in the docs is imho the way to go. My 'nroff' is almost nonexistant, but here's a diff: --- pfctl.8.orig Wed Jun 11 09:23:36 2008 +++ pfctl.8 Mon Mar 15 12:53:04 2010 @@ -354,7 +354,9 @@ Only print errors and warnings. .It Fl R Load only the filter rules present in the rule file. -Other rules and options are ignored. +Other rules and options are ignored. If you are using +tables, you need to also specify one of -T load or +-o none. .It Fl r Perform reverse DNS lookups on states when displaying them. .It Fl s Ar modifier doesn;t Other rules and options are ignored. already cover this? furthermore, since -T has a load command, should we really expect -R to load tables? i don;t see that it needs to be more explicit. jmc
Re: pfctl(8): unclear docs
2010/3/15 Toni Mueller openbsd-m...@oeko.net Hi, On Mon, 15.03.2010 at 12:22:35 +0100, matteo filippetto matteo.filippe...@gmail.com wrote: for me it works good ... just don't use -R option http://kerneltrap.org/mailarchive/openbsd-misc/2007/4/6/147502 thanks for this link. Not using -R is not too good, either, as on this particular box, reloading everything results in a severance of all existing connections. A clarification in the docs is imho the way to go. My 'nroff' is almost nonexistant, but here's a diff: --- pfctl.8.origWed Jun 11 09:23:36 2008 +++ pfctl.8 Mon Mar 15 12:53:04 2010 @@ -354,7 +354,9 @@ Only print errors and warnings. .It Fl R Load only the filter rules present in the rule file. -Other rules and options are ignored. +Other rules and options are ignored. If you are using +tables, you need to also specify one of -T load or +-o none. .It Fl r Perform reverse DNS lookups on states when displaying them. .It Fl s Ar modifier Kind regards, --Toni++ Hi Toni, I find this Starting in OpenBSD 4.2, the default is basic. See pf.conf(5)http://www.openbsd.org/cgi-bin/man.cgi?query=pf.confsektion=5manpath=OpenBSD+4.6for a more complete description. on faq (http://www.openbsd.org/faq/pf/options.html) and also in the man pages http://www.openbsd.org/cgi-bin/man.cgi?query=pf.confsektion=5manpath=OpenBSD+4.6 Best regards -- Matteo Filippetto
Re: pfctl(8): unclear docs
Hi, On Mon, 15.03.2010 at 13:04:04 +, Jason McIntyre j...@kerhand.co.uk wrote: doesn;t Other rules and options are ignored. already cover this? may be. But then, you are possibly only too deeply entrenched in this stuff to see the problem. furthermore, since -T has a load command, should we really expect -R to load tables? Should it really need to? My guess was that tables would usually have been loaded already when one goes to selectively reloads the rules, and either of spelling out that they need to be loaded explicitly, stating that, by default, the already-loaded tables are being used, or that they are being ignored, or that the whole command fails would imho be a good thing. Ok. I go out on a limb and say that explicit is better than implicit, in a lot of cases, and would welcome the short explanation OR the modification of the command to also load tables (which would require amending the man page, too). I admit that I was unaware of the rule optimizer until it bit me into my bottom half. I mean, I usually don't care, from a user perspective, whether there is something optimizing my stuff, and consider this kind of breakage as a (an almost) hidden gotcha. An optimizer (or any other such device) which is on by default and claims to not change semantics, should imho be transparent to the user, but this one isn't. If you have other uses of disabling the optimizer except for debugging pf, I'd really like to hear. -- Kind regards, --Toni++
Re: pfctl table cleared time is jumping around
On Wed, Feb 24, 2010 at 08:30:05AM +0100, Henning Brauer wrote: * Dan Harnett dan...@harnett.name [2010-02-23 21:19]: Probably wrong, but this fixes it. i would not call that wrong. i don't understand how this ever worked and I don't understand what broke it. the only commit in that timeframe that could cause this is ryan's pool removal and that doesn't touch anything near that codepath. puzzled. Ryan's commit actually removed a very similar line. $ cd /usr/src/sys/net $ cvs diff -D 2010/01/11 -D 2010/01/12 pf_table.c Index: pf_table.c === RCS file: /home/cvs/openbsd/src/sys/net/pf_table.c,v retrieving revision 1.80 retrieving revision 1.81 diff -u -p -r1.80 -r1.81 --- pf_table.c 24 Nov 2008 13:22:09 - 1.80 +++ pf_table.c 12 Jan 2010 03:20:51 - 1.81 [... snip! ...] @@ -1087,7 +,6 @@ pfr_walktree(struct radix_node *rn, void as.pfras_a.pfra_fback = PFR_FB_NOCOUNT; } splx(s); - as.pfras_tzero = ke-pfrke_tzero; if (COPYOUT(as, w-pfrw_astats, sizeof(as), flags)) return (EFAULT); [... snip! ...]
Re: pfctl table cleared time is jumping around
* Dan Harnett dan...@harnett.name [2010-02-24 15:29]: On Wed, Feb 24, 2010 at 08:30:05AM +0100, Henning Brauer wrote: * Dan Harnett dan...@harnett.name [2010-02-23 21:19]: Probably wrong, but this fixes it. i would not call that wrong. i don't understand how this ever worked and I don't understand what broke it. the only commit in that timeframe that could cause this is ryan's pool removal and that doesn't touch anything near that codepath. puzzled. Ryan's commit actually removed a very similar line. I'm blind and the mystery is solved. thanks for tracking this down. $ cd /usr/src/sys/net $ cvs diff -D 2010/01/11 -D 2010/01/12 pf_table.c Index: pf_table.c === RCS file: /home/cvs/openbsd/src/sys/net/pf_table.c,v retrieving revision 1.80 retrieving revision 1.81 diff -u -p -r1.80 -r1.81 --- pf_table.c 24 Nov 2008 13:22:09 - 1.80 +++ pf_table.c 12 Jan 2010 03:20:51 - 1.81 [... snip! ...] @@ -1087,7 +,6 @@ pfr_walktree(struct radix_node *rn, void as.pfras_a.pfra_fback = PFR_FB_NOCOUNT; } splx(s); - as.pfras_tzero = ke-pfrke_tzero; if (COPYOUT(as, w-pfrw_astats, sizeof(as), flags)) return (EFAULT); [... snip! ...] -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfctl table cleared time is jumping around
On Mon, Feb 22, 2010 at 10:40:29PM +0100, Michael Lechtermann wrote: it's a slightly weird side-effect. a quick glance indicates that the tzero timestamp is part of the stats struct and tables don't keep stats/counters by default any more. for some time tho. i don't remember any recent changes to the table code (as if anybody wanted to touch that mess) by default, does that mean it is possible to somehow keep the stats/counters with a configuration option and have it work again? Add 'counters' to the table definition. That didn't fix it. The stats are shown now, but the dates are still jumping around. :-( 'pfctl -t tablename -T expire ' is also currently broken. Everything appears to be removed from the table immediately regardless of ''. $ sudo cat /etc/pf.conf table testing persist counters $ sudo pfctl -vv -t testing -T add 172.16.1.8 172.16.1.9 2/2 addresses added. A 172.16.1.8 A 172.16.1.9 $ sudo pfctl -vv -t testing -T expire 7200 2/2 addresses expired. D 172.16.1.8 D 172.16.1.9
Re: pfctl table cleared time is jumping around
* Dan Harnett dan...@harnett.name [2010-02-23 17:19]: 'pfctl -t tablename -T expire ' is also currently broken. Everything appears to be removed from the table immediately regardless of ''. $ sudo cat /etc/pf.conf table testing persist counters $ sudo pfctl -vv -t testing -T add 172.16.1.8 172.16.1.9 2/2 addresses added. A 172.16.1.8 A 172.16.1.9 $ sudo pfctl -vv -t testing -T expire 7200 2/2 addresses expired. D 172.16.1.8 D 172.16.1.9 I don't remember any changes in that area lately so this puzzles me. do we know when this breakage was introduced, approximately? -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfctl table cleared time is jumping around
On 2010-02-23, Henning Brauer lists-open...@bsws.de wrote: * Dan Harnett dan...@harnett.name [2010-02-23 17:19]: 'pfctl -t tablename -T expire ' is also currently broken. Everything appears to be removed from the table immediately regardless of ''. $ sudo cat /etc/pf.conf table testing persist counters $ sudo pfctl -vv -t testing -T add 172.16.1.8 172.16.1.9 2/2 addresses added. A 172.16.1.8 A 172.16.1.9 $ sudo pfctl -vv -t testing -T expire 7200 2/2 addresses expired. D 172.16.1.8 D 172.16.1.9 I don't remember any changes in that area lately so this puzzles me. do we know when this breakage was introduced, approximately? I found a couple of boxes with May 2009 kernels where expire works as expected. I can't think of anything I have running code dated between then and now to pinpoint it any better than that (the downside of actually testing diffs ;-)
Re: pfctl table cleared time is jumping around
Hi, I don't remember any changes in that area lately so this puzzles me. do we know when this breakage was introduced, approximately? I found a couple of boxes with May 2009 kernels where expire works as expected. I can't think of anything I have running code dated between then and now to pinpoint it any better than that (the downside of actually testing diffs ;-) It still worked with the snapshot from around 08/2009. Michael
Re: pfctl table cleared time is jumping around
On Tue, Feb 23, 2010 at 05:24:30PM +0100, Henning Brauer wrote: * Dan Harnett dan...@harnett.name [2010-02-23 17:19]: 'pfctl -t tablename -T expire ' is also currently broken. Everything appears to be removed from the table immediately regardless of ''. $ sudo cat /etc/pf.conf table testing persist counters $ sudo pfctl -vv -t testing -T add 172.16.1.8 172.16.1.9 2/2 addresses added. A 172.16.1.8 A 172.16.1.9 $ sudo pfctl -vv -t testing -T expire 7200 2/2 addresses expired. D 172.16.1.8 D 172.16.1.9 I don't remember any changes in that area lately so this puzzles me. do we know when this breakage was introduced, approximately? I have narrowed it down to between 2010/01/11 and 2010/01/12. It worked fine on 2010/01/11.
Re: pfctl table cleared time is jumping around
On Tue, Feb 23, 2010 at 02:28:17PM -0500, Dan Harnett wrote: On Tue, Feb 23, 2010 at 05:24:30PM +0100, Henning Brauer wrote: I don't remember any changes in that area lately so this puzzles me. do we know when this breakage was introduced, approximately? I have narrowed it down to between 2010/01/11 and 2010/01/12. It worked fine on 2010/01/11. Probably wrong, but this fixes it. Index: pf_table.c === RCS file: /cvs/src/sys/net/pf_table.c,v retrieving revision 1.82 diff -N -u -p pf_table.c --- pf_table.c 18 Jan 2010 23:52:46 - 1.82 +++ pf_table.c 23 Feb 2010 20:09:59 - @@ -1112,6 +1112,7 @@ pfr_walktree(struct radix_node *rn, void *arg) as.pfras_a.pfra_fback = PFR_FB_NOCOUNT; } splx(s); + as.pfras_tzero = ke-u._ke._pfrke_tzero; if (COPYOUT(as, w-pfrw_astats, sizeof(as), flags)) return (EFAULT);
Re: pfctl table cleared time is jumping around
* Dan Harnett dan...@harnett.name [2010-02-23 21:19]: On Tue, Feb 23, 2010 at 02:28:17PM -0500, Dan Harnett wrote: On Tue, Feb 23, 2010 at 05:24:30PM +0100, Henning Brauer wrote: I don't remember any changes in that area lately so this puzzles me. do we know when this breakage was introduced, approximately? I have narrowed it down to between 2010/01/11 and 2010/01/12. It worked fine on 2010/01/11. Probably wrong, but this fixes it. i would not call that wrong. i don't understand how this ever worked and I don't understand what broke it. the only commit in that timeframe that could cause this is ryan's pool removal and that doesn't touch anything near that codepath. puzzled. Index: pf_table.c === RCS file: /cvs/src/sys/net/pf_table.c,v retrieving revision 1.82 diff -N -u -p pf_table.c --- pf_table.c18 Jan 2010 23:52:46 - 1.82 +++ pf_table.c23 Feb 2010 20:09:59 - @@ -1112,6 +1112,7 @@ pfr_walktree(struct radix_node *rn, void *arg) as.pfras_a.pfra_fback = PFR_FB_NOCOUNT; } splx(s); + as.pfras_tzero = ke-u._ke._pfrke_tzero; if (COPYOUT(as, w-pfrw_astats, sizeof(as), flags)) return (EFAULT); -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfctl table cleared time is jumping around
Hi, it's a slightly weird side-effect. a quick glance indicates that the tzero timestamp is part of the stats struct and tables don't keep stats/counters by default any more. for some time tho. i don't remember any recent changes to the table code (as if anybody wanted to touch that mess) by default, does that mean it is possible to somehow keep the stats/counters with a configuration option and have it work again? I couldn't find anything regarding that in the pf.conf manpage. Michael
Re: pfctl table cleared time is jumping around
On 2010-02-22, Michael Lechtermann mich...@lechtermann.net wrote: Hi, it's a slightly weird side-effect. a quick glance indicates that the tzero timestamp is part of the stats struct and tables don't keep stats/counters by default any more. for some time tho. i don't remember any recent changes to the table code (as if anybody wanted to touch that mess) by default, does that mean it is possible to somehow keep the stats/counters with a configuration option and have it work again? Add 'counters' to the table definition.
Re: pfctl table cleared time is jumping around
Hi, it's a slightly weird side-effect. a quick glance indicates that the tzero timestamp is part of the stats struct and tables don't keep stats/counters by default any more. for some time tho. i don't remember any recent changes to the table code (as if anybody wanted to touch that mess) by default, does that mean it is possible to somehow keep the stats/counters with a configuration option and have it work again? Add 'counters' to the table definition. That didn't fix it. The stats are shown now, but the dates are still jumping around. :-( Michael
Re: pfctl table cleared time is jumping around
* Didier Wiroth dwir...@gmail.com [2010-01-23 23:15]: On Wednesday 20 January 2010 23:21:35 Michael Lechtermann wrote: Am 20.01.2010 23:15, schrieb frantisek holop: hmm, on Wed, Jan 20, 2010 at 04:58:32PM +0100, Michael Lechtermann said that it seems there is a bug in pfctl regarding the cleared time of a table entry. The attack actually happend this year, but the date shown is constantly changing: been like this forever... -pa-r-- bad-ssh Addresses: 3 Cleared: Thu Jan 1 01:00:00 1970 References: [ Anchors: 0 Rules: 2 ] Evaluations: [ NoMatch: 0 Match: 0 ] In/Block:[ Packets: 0 Bytes: 0 ] In/Pass: [ Packets: 0 Bytes: 0 ] In/XPass:[ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ] Out/XPass: [ Packets: 0 Bytes: 0 ] i think i have sent a message about it ages ago but only to misc@ For me, it is a new behavior. It still worked with OpenBSD snapshot from around 08/2009. Hello, I'm running latest current and I have the same issues now: # pfctl -t tb1 -Ts -vvv 172.16.43.34 Cleared: Wed Dec 31 11:19:39 1969 172.16.43.35 Cleared: Wed Dec 31 11:19:39 1969 Actually this used to be displayed correctly 2 or 3 snapshots ago. Is this a known bug? it's a slightly weird side-effect. a quick glance indicates that the tzero timestamp is part of the stats struct and tables don't keep stats/counters by default any more. for some time tho. i don't remember any recent changes to the table code (as if anybody wanted to touch that mess) -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting
Re: pfctl table cleared time is jumping around
On Wednesday 20 January 2010 23:21:35 Michael Lechtermann wrote: Am 20.01.2010 23:15, schrieb frantisek holop: hmm, on Wed, Jan 20, 2010 at 04:58:32PM +0100, Michael Lechtermann said that it seems there is a bug in pfctl regarding the cleared time of a table entry. The attack actually happend this year, but the date shown is constantly changing: been like this forever... -pa-r-- bad-ssh Addresses: 3 Cleared: Thu Jan 1 01:00:00 1970 References: [ Anchors: 0 Rules: 2 ] Evaluations: [ NoMatch: 0 Match: 0 ] In/Block:[ Packets: 0 Bytes: 0 ] In/Pass: [ Packets: 0 Bytes: 0 ] In/XPass:[ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ] Out/XPass: [ Packets: 0 Bytes: 0 ] i think i have sent a message about it ages ago but only to misc@ For me, it is a new behavior. It still worked with OpenBSD snapshot from around 08/2009. Hello, I'm running latest current and I have the same issues now: # pfctl -t tb1 -Ts -vvv 172.16.43.34 Cleared: Wed Dec 31 11:19:39 1969 172.16.43.35 Cleared: Wed Dec 31 11:19:39 1969 Actually this used to be displayed correctly 2 or 3 snapshots ago. Is this a known bug? Kind regards, Didier
Re: pfctl table cleared time is jumping around
hmm, on Wed, Jan 20, 2010 at 04:58:32PM +0100, Michael Lechtermann said that it seems there is a bug in pfctl regarding the cleared time of a table entry. The attack actually happend this year, but the date shown is constantly changing: been like this forever... -pa-r-- bad-ssh Addresses: 3 Cleared: Thu Jan 1 01:00:00 1970 References: [ Anchors: 0 Rules: 2 ] Evaluations: [ NoMatch: 0 Match: 0 ] In/Block:[ Packets: 0 Bytes: 0 ] In/Pass: [ Packets: 0 Bytes: 0 ] In/XPass:[ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ] Out/XPass: [ Packets: 0 Bytes: 0 ] i think i have sent a message about it ages ago but only to misc@ -f -- this message written by sandy. a highly trained dolphin.
Re: pfctl table cleared time is jumping around
Am 20.01.2010 23:15, schrieb frantisek holop: hmm, on Wed, Jan 20, 2010 at 04:58:32PM +0100, Michael Lechtermann said that it seems there is a bug in pfctl regarding the cleared time of a table entry. The attack actually happend this year, but the date shown is constantly changing: been like this forever... -pa-r-- bad-ssh Addresses: 3 Cleared: Thu Jan 1 01:00:00 1970 References: [ Anchors: 0 Rules: 2 ] Evaluations: [ NoMatch: 0 Match: 0 ] In/Block:[ Packets: 0 Bytes: 0 ] In/Pass: [ Packets: 0 Bytes: 0 ] In/XPass:[ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ] Out/XPass: [ Packets: 0 Bytes: 0 ] i think i have sent a message about it ages ago but only to misc@ For me, it is a new behavior. It still worked with OpenBSD snapshot from around 08/2009.
Re: pfctl -x fails on -current
* Danix da...@kernel-panic.it [2009-07-09 23:13]:
Hi all,
I'm running the OpenBSD 4.6 snapshot from June 26th and I can't get
pfctl(8) to set the debug level:
# pfctl -si | grep Debug
Status: Enabled for 0 days 01:37:04 Debug: Urgent
# pfctl -x loud
debug level set to 'loud'
# pfctl -si | grep Debug
Status: Enabled for 0 days 01:37:12 Debug: Urgent
I've seen that there have recently been some changes in how the debug
level is set in pf_ioctl.c... is it still a work in progress? Am I
missing something?
shit. I forgot to commit a chunk.
Index: pfctl.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl.c,v
retrieving revision 1.282
diff -u -p -r1.282 pfctl.c
--- pfctl.c 16 Apr 2009 04:40:19 - 1.282
+++ pfctl.c 9 Jul 2009 21:33:36 -
@@ -1900,8 +1900,15 @@ pfctl_set_interface_flags(struct pfctl *
void
pfctl_debug(int dev, u_int32_t level, int opts)
{
- if (ioctl(dev, DIOCSETDEBUG, level))
- err(1, DIOCSETDEBUG);
+ struct pfr_buffer t;
+
+ memset(t, 0, sizeof(t));
+ t.pfrb_type = PFRB_TRANS;
+ if (pfctl_trans(dev, t, DIOCXBEGIN, 0) ||
+ ioctl(dev, DIOCSETDEBUG, level) ||
+ pfctl_trans(dev, t, DIOCXCOMMIT, 0))
+ err(1, pfctl_debug ioctl);
+
if ((opts PF_OPT_QUIET) == 0) {
fprintf(stderr, debug level set to ');
switch (level) {
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services, http://bsws.de
Full-Service ISP - Secure Hosting, Mail and DNS Services
Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: pfctl no longer showing table details in 4.5
* Egbert Krook egbert.kr...@amarin.co.th [2009-06-21 11:58]: I've run into a small problem with pfctl as it's no longer showing the details for each individual IP address in our tables, just the date the table was last cleared. really. reading the manpage would solve your confusion. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
Re: pfctl no longer showing table details in 4.5
On Thu, Jun 18, 2009 at 04:16:02PM +0700, Egbert Krook wrote: Hi, I've just finished upgrading one of our systems from OpenBSD 4.2 to 4.5. I've run into a small problem with pfctl as it's no longer showing the details for each individual IP address in our tables, just the date the table was last cleared. You need the counters option for each table. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Re: pfctl -si insane enabled time counter on -current
On Thu, 2009-04-30 at 21:57 +0200, Henning Brauer wrote: # pfctl -si Status: Enabled for 49710 days 04:40:06 Debug: Urgent that really looks like userland and kernel out of sync or similiar. I cannot reproduce that. It happens when i start ntpd with -s to set the clock. The clock is off by 2 hours on boot (maybe daylight saving, I'm in UTC+1), probably due to multibooting into other OSes. ciao Luca
