Re: Cannot configure wi-fi card
I installed on a dedicated desktop computer at home. And it is not dual boot. I have only OpenBSD installed on my ssd drive. On Sat, May 28, 2022 at 03:11:12PM +0900, Fabrizio Francione wrote: > Are You installing on a VM like Proxmox or is that a dedicated HW? > > Do you have a dual boot or related?
Re: Cannot configure wi-fi card
Are You installing on a VM like Proxmox or is that a dedicated HW? Do you have a dual boot or related? On 5/28/2022 1:21 PM, Matsuda Kenji wrote: Thank you for your reply. Did you install the iwm firmware? https://www.openbsd.org/faq/faq4.html#WifiOnly I can connect to the Internet via Ethernet, and iwm firmware was installed by fw_update at the first boot. There is firmware files in /etc/firmware: $ls /etc/firmware/iwm* /etc/firmware/iwm-3160-17 /etc/firmware/iwm-3168-29 /etc/firmware/iwm-7260-17 /etc/firmware/iwm-7265-17 /etc/firmware/iwm-7265D-29 /etc/firmware/iwm-8000C-34 /etc/firmware/iwm-8000C-36 /etc/firmware/iwm-8265-34 /etc/firmware/iwm-8265-36 /etc/firmware/iwm-9000-34 /etc/firmware/iwm-9000-46 /etc/firmware/iwm-9260-34 /etc/firmware/iwm-9260-46 /etc/firmware/iwm-license Matsuda Kenji
Re: Cannot configure wi-fi card
Thank you for your reply. > Did you install the iwm firmware? > https://www.openbsd.org/faq/faq4.html#WifiOnly I can connect to the Internet via Ethernet, and iwm firmware was installed by fw_update at the first boot. There is firmware files in /etc/firmware: $ls /etc/firmware/iwm* /etc/firmware/iwm-3160-17 /etc/firmware/iwm-3168-29 /etc/firmware/iwm-7260-17 /etc/firmware/iwm-7265-17 /etc/firmware/iwm-7265D-29 /etc/firmware/iwm-8000C-34 /etc/firmware/iwm-8000C-36 /etc/firmware/iwm-8265-34 /etc/firmware/iwm-8265-36 /etc/firmware/iwm-9000-34 /etc/firmware/iwm-9000-46 /etc/firmware/iwm-9260-34 /etc/firmware/iwm-9260-46 /etc/firmware/iwm-license Matsuda Kenji
Re: Cannot configure wi-fi card
Did you install the iwm firmware? https://www.openbsd.org/faq/faq4.html#WifiOnly Elias On Fri, May 27, 2022 at 19:25 Matsuda Kenji wrote: > Hello. > > I just installed OpenBSD 7.1 and am having trouble > setting up a wi-fi card. > There is no wi-fi interface in ifconfig output. > Dmesg says that there is some error configuring NIC: > iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260"\ > rev 0x29, msix > iwm0: Failed to wake up the nic. > > What am I missing? > > With best regards, > Matsuda Kenji > > -dmesg output > OpenBSD 7.1 (RAMDISK_CD) #440: Mon Apr 11 18:09:13 MDT 2022 > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > real mem = 16799301632 (16021MB) > avail mem = 16286146560 (15531MB) > random: good seed from bootblocks > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7e978000 (51 entries) > bios0: vendor American Megatrends Inc. version "P1.30" date 08/16/2018 > bios0: ASRock Z390 Pro4 > acpi0 at bios0: ACPI 6.1 > acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT AAFT SSDT HPET SSDT > UEFI LPIT SSDT DBGP DBG2 SSDT SSDT DMAR WSMT > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz, 3600.00 MHz, 06-9e-0c > 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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 256KB 64b/line 8-way L2 cache > cpu0: apic clock running at 24MHz > cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > cpu at mainbus0: not configured > ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins > acpihpet0 at acpi0: 2399 Hz > acpiprt0 at acpi0: bus 0 (PCI0) > acpiprt1 at acpi0: bus -1 (PEG0) > acpiprt2 at acpi0: bus -1 (PEG1) > acpiprt3 at acpi0: bus -1 (PEG2) > acpiprt4 at acpi0: bus -1 (RP01) > acpiprt5 at acpi0: bus -1 (RP02) > acpiprt6 at acpi0: bus -1 (RP03) > acpiprt7 at acpi0: bus -1 (RP04) > acpiprt8 at acpi0: bus -1 (RP05) > acpiprt9 at acpi0: bus -1 (RP06) > acpiprt10 at acpi0: bus -1 (RP07) > acpiprt11 at acpi0: bus -1 (RP08) > acpiprt12 at acpi0: bus -1 (RP09) > acpiprt13 at acpi0: bus -1 (RP10) > acpiprt14 at acpi0: bus -1 (RP11) > acpiprt15 at acpi0: bus -1 (RP12) > acpiprt16 at acpi0: bus -1 (RP13) > acpiprt17 at acpi0: bus -1 (RP14) > acpiprt18 at acpi0: bus -1 (RP15) > acpiprt19 at acpi0: bus -1 (RP16) > acpiprt20 at acpi0: bus -1 (RP17) > acpiprt21 at acpi0: bus -1 (RP18) > acpiprt22 at acpi0: bus -1 (RP19) > acpiprt23 at acpi0: bus 1 (RP20) > acpiprt24 at acpi0: bus -1 (RP21) > acpiprt25 at acpi0: bus -1 (RP22) > acpiprt26 at acpi0: bus -1 (RP23) > acpiprt27 at acpi0: bus -1 (RP24) > acpiec0 at acpi0: not present > acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x > com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo > acpicmos0 at acpi0 > "PNP0C14" at acpi0 not configured > "PNP0C0E" at acpi0 not configured > "PNP0C14" at acpi0 not configured > "PNP0C14" at acpi0 not configured > "INT33A1" at acpi0 not configured > "PNP0C0C" at acpi0 not configured > acpipwrres at acpi0 not configured > acpipwrres at acpi0 not configured > acpipwrres at acpi0 not configured > acpipwrres at acpi0 not configured > acpipwrres at acpi0 not configured > acpicpu at acpi0 not configured > acpipwrres at acpi0 not configured > cpu0: using Skylake AVX MDS workaround > pci0 at mainbus0 bus 0 > pchb0 at pci0 dev 0 function 0 "Intel Core 8G Host" rev 0x0a > vga1 at pci0 dev 2 function 0 "Intel UHD Graphics 630" rev 0x00 > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) > "Intel 300 Series Thermal" rev 0x10 at pci0 dev 18 function 0 not > configured > xhci0 at pci0 dev 20 function 0 "Intel 300 Series xHCI" rev 0x10: msi, > xHCI 1.10 > usb0 at xhci0: USB revision 3.0 > uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev > 3.00/1.00 addr 1 > "Intel 300 Series Shared SRAM" rev 0x10 at pci0 dev 20 function 2 not > configured > "Intel 300 Series HECI" rev 0x10 at pci0 dev 22 function 0 not configured > ahci0 at pci0 dev 23 function 0 "Intel 300 Series AHCI" rev 0x10: msi, > AHCI 1.3.1 > ahci0: port 0: 6.0Gb/s > ahci0: PHY offline on port 1 > ahci0: port 2: 6.0Gb/s > ahci0: PHY offline on port 3 > ahci0: PHY offline on port 4 > ahci0: PHY offline on port 5 > scsibus0 at ahci0: 32 targets > sd0 at scsibus0 targ 0 lun 0: > naa.539fe6ea4038 > sd0:
Re: C states lost on amd64
On Fri, 27 May 2022, Jan Stary wrote:
> ... and with the latest snapshot, they are back.
...
> acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> acpicpu2 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
> acpicpu3 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> C1(1000@1 mwait.1), PSS
>
> On May 26 14:34:43, h...@stare.cz wrote:
> > This is current/adm64, dmesgs below.
> > With the current snapshot, the C states are gone:
> >
> > -acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> > C1(1000@1 mwait.1), PSS
> > -acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> > C1(1000@1 mwait.1), PSS
> > -acpicpu2 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> > C1(1000@1 mwait.1), PSS
> > -acpicpu3 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10),
> > C1(1000@1 mwait.1), PSS
> > +acpicpu0 at acpi0: C1(@1 halt!), PSS
> > +acpicpu1 at acpi0: C1(@1 halt!), PSS
> > +acpicpu2 at acpi0: C1(@1 halt!), PSS
> > +acpicpu3 at acpi0: C1(@1 halt!), PSS
> >
> > Is this expected?
> > Is it related to the recent apmd -A change?
Not really. Well, unless your box is one where the states change
depending on, say, whether the box is plugged in.
You could give this diff a shot. It enables processing of CST change
notifications. No committers have a (working) box that does that, so I
couldn't get any interest and I have no idea when--or even if--it might go
in.
Philip Guenther
Index: sys/dev/acpi/acpicpu.c
===
RCS file: /data/src/openbsd/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.92
diff -u -p -r1.92 acpicpu.c
--- sys/dev/acpi/acpicpu.c 6 Apr 2022 18:59:27 - 1.92
+++ sys/dev/acpi/acpicpu.c 12 Apr 2022 06:13:55 -
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -80,6 +81,7 @@ void acpicpu_setperf_ppc_change(struct a
#define CST_FLAG_FALLBACK 0x4000 /* fallback for broken _CST */
#define CST_FLAG_SKIP 0x8000 /* state is worse choice */
+#define FLAGS_NOCST0x01
#define FLAGS_MWAIT_ONLY 0x02
#define FLAGS_BMCHECK 0x04
#define FLAGS_NOTHROTTLE 0x08
@@ -113,8 +115,10 @@ struct acpi_cstate
uint64_taddress;/* or mwait hint */
};
-unsigned long cst_stats[4] = { 0 };
-
+/*
+ * Locking:
+ * m sc_mtx
+ */
struct acpicpu_softc {
struct device sc_dev;
int sc_cpu;
@@ -130,6 +134,10 @@ struct acpicpu_softc {
struct cpu_info *sc_ci;
SLIST_HEAD(,acpi_cstate) sc_cstates;
+ struct mutexsc_mtx;
+ struct acpi_cstate *sc_cstates_active; /* [m] */
+ int sc_mwait_only; /* [m] */
+
bus_space_tag_t sc_iot;
bus_space_handle_t sc_ioh;
@@ -161,10 +169,13 @@ struct acpicpu_softc {
void acpicpu_add_cstatepkg(struct aml_value *, void *);
void acpicpu_add_cdeppkg(struct aml_value *, void *);
+void acpicpu_cst_activate(struct acpicpu_softc *);
intacpicpu_getppc(struct acpicpu_softc *);
intacpicpu_getpct(struct acpicpu_softc *);
intacpicpu_getpss(struct acpicpu_softc *);
intacpicpu_getcst(struct acpicpu_softc *);
+intacpicpu_cst_changed(struct acpicpu_softc *);
+void acpicpu_free_states(struct acpi_cstate *);
void acpicpu_getcst_from_fadt(struct acpicpu_softc *);
void acpicpu_print_one_cst(struct acpi_cstate *_cx);
void acpicpu_print_cst(struct acpicpu_softc *_sc);
@@ -510,11 +521,11 @@ acpicpu_getcst(struct acpicpu_softc *sc)
struct acpi_cstate *cx, *next_cx;
int use_nonmwait;
- /* delete the existing list */
- while ((cx = SLIST_FIRST(&sc->sc_cstates)) != NULL) {
- SLIST_REMOVE_HEAD(&sc->sc_cstates, link);
- free(cx, M_DEVBUF, sizeof(*cx));
- }
+ /* set aside the existing list and free it if not active */
+ cx = SLIST_FIRST(&sc->sc_cstates);
+ SLIST_INIT(&sc->sc_cstates);
+ if (cx != sc->sc_cstates_active)
+ acpicpu_free_states(cx);
/* provide a fallback C1-via-halt in case _CST's C1 is bogus */
acpicpu_add_cstate(sc, ACPI_STATE_C1, CST_METH_HALT,
@@ -528,8 +539,10 @@ acpicpu_getcst(struct acpicpu_softc *sc)
/* only have fallback state? then no _CST objects were understood */
cx = SLIST_FIRST(&sc->sc_cstates);
- if (cx->flags & CST_FLAG_FALLBACK)
+ if (cx->flags & CST_FLAG_FALLBACK) {
+ sc->sc_flags &= ~FLAGS_MWAIT_ONLY;
return (1);
+ }
/*
* Skip states >= C2 if the CPU's LAPIC timer stops in deep
@@ -558,6 +571,38
Cannot configure wi-fi card
Hello. I just installed OpenBSD 7.1 and am having trouble setting up a wi-fi card. There is no wi-fi interface in ifconfig output. Dmesg says that there is some error configuring NIC: iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260"\ rev 0x29, msix iwm0: Failed to wake up the nic. What am I missing? With best regards, Matsuda Kenji -dmesg output OpenBSD 7.1 (RAMDISK_CD) #440: Mon Apr 11 18:09:13 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD real mem = 16799301632 (16021MB) avail mem = 16286146560 (15531MB) random: good seed from bootblocks mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7e978000 (51 entries) bios0: vendor American Megatrends Inc. version "P1.30" date 08/16/2018 bios0: ASRock Z390 Pro4 acpi0 at bios0: ACPI 6.1 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT AAFT SSDT HPET SSDT UEFI LPIT SSDT DBGP DBG2 SSDT SSDT DMAR WSMT acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz, 3600.00 MHz, 06-9e-0c 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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured cpu at mainbus0: not configured ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP01) acpiprt5 at acpi0: bus -1 (RP02) acpiprt6 at acpi0: bus -1 (RP03) acpiprt7 at acpi0: bus -1 (RP04) acpiprt8 at acpi0: bus -1 (RP05) acpiprt9 at acpi0: bus -1 (RP06) acpiprt10 at acpi0: bus -1 (RP07) acpiprt11 at acpi0: bus -1 (RP08) acpiprt12 at acpi0: bus -1 (RP09) acpiprt13 at acpi0: bus -1 (RP10) acpiprt14 at acpi0: bus -1 (RP11) acpiprt15 at acpi0: bus -1 (RP12) acpiprt16 at acpi0: bus -1 (RP13) acpiprt17 at acpi0: bus -1 (RP14) acpiprt18 at acpi0: bus -1 (RP15) acpiprt19 at acpi0: bus -1 (RP16) acpiprt20 at acpi0: bus -1 (RP17) acpiprt21 at acpi0: bus -1 (RP18) acpiprt22 at acpi0: bus -1 (RP19) acpiprt23 at acpi0: bus 1 (RP20) acpiprt24 at acpi0: bus -1 (RP21) acpiprt25 at acpi0: bus -1 (RP22) acpiprt26 at acpi0: bus -1 (RP23) acpiprt27 at acpi0: bus -1 (RP24) acpiec0 at acpi0: not present acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo acpicmos0 at acpi0 "PNP0C14" at acpi0 not configured "PNP0C0E" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "INT33A1" at acpi0 not configured "PNP0C0C" at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpipwrres at acpi0 not configured acpicpu at acpi0 not configured acpipwrres at acpi0 not configured cpu0: using Skylake AVX MDS workaround pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 "Intel Core 8G Host" rev 0x0a vga1 at pci0 dev 2 function 0 "Intel UHD Graphics 630" rev 0x00 wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) "Intel 300 Series Thermal" rev 0x10 at pci0 dev 18 function 0 not configured xhci0 at pci0 dev 20 function 0 "Intel 300 Series xHCI" rev 0x10: msi, xHCI 1.10 usb0 at xhci0: USB revision 3.0 uhub0 at usb0 configuration 1 interface 0 "Intel xHCI root hub" rev 3.00/1.00 addr 1 "Intel 300 Series Shared SRAM" rev 0x10 at pci0 dev 20 function 2 not configured "Intel 300 Series HECI" rev 0x10 at pci0 dev 22 function 0 not configured ahci0 at pci0 dev 23 function 0 "Intel 300 Series AHCI" rev 0x10: msi, AHCI 1.3.1 ahci0: port 0: 6.0Gb/s ahci0: PHY offline on port 1 ahci0: port 2: 6.0Gb/s ahci0: PHY offline on port 3 ahci0: PHY offline on port 4 ahci0: PHY offline on port 5 scsibus0 at ahci0: 32 targets sd0 at scsibus0 targ 0 lun 0: naa.539fe6ea4038 sd0: 2861588MB, 512 bytes/sector, 5860533168 sectors sd1 at scsibus0 targ 2 lun 0: t10.ATA_KimMiDi_SSD_TB900_256GB_AA001047 sd1: 244198MB, 512 bytes/sector, 500118192 sectors, thin ppb0 at pci0 dev 27 function 0 "Intel 300 Series PCIE" rev 0xf0: msi pci1 at ppb0 bus 1 iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless-AC 9260" rev 0x29, msix iwm0: Fai
Re: spamd on VirtualBox vm - rdr-to rules not working as expected
Thank you for your insight. I believe you are exactly correct. I have previously run OpenBSD as my router and spamd in the classic setup, so that is my past experience base. I was hoping to use it in this situation as just a proxy in front of the mail server, but that seems to be getting outside of the typical use case, so I’ll look at other options/configuration. Again, thank you for your time. -Alex Alex Johnson ax.john...@gmail.com (P.S. Just changed the e-mail registered on the list, so this is the same Alex) > On May 27, 2022, at 12:29 AM, Stuart Henderson > wrote: > > On 2022-05-27, Arete wrote: >> I’m setting up spamd in front of a Postfix mail server, and am having >> an issue with rdr-to rules not working the way I expect. >> >> My setup: Re-purposed Mac Mini running MacOS 12.4 Monterey, Postfix & >> Dovecot, smtp port-forwarded to this box from my firewall. OpenBSD 7.1 >> running in a VirtualBox machine on the same Mac Mini, with bridged >> networking enabled. >> >> Postfix on the Mac Mini can receive mail just fine from the internet >> through the firewall. The mini has the IP address 192.168.20.15. >> OpenBSD is configured and running with spamd (greylisting enabled) in >> the VM, with IP address 192.168.20.16 - pf.conf rules as follows: > > So if I understand correctly you have > > internet -> firewall -> 192.168.20.0/24 > > and in 192.168.20.0/24 you have > > - firewall > - vm running spamd > - machine running postfix > > incoming packet flow is internet -> firewall -> spamd -> postfix, but > as the source address is unchanged by rdr-to, return packet flow is > postfix -> firewall -> internet, bypassing the spamd vm, so there is > nothing to "untranslate" the rdr-to. > > The classic spamd setup is where it's run on a firewall which is set as > default gateway on the mail server. Alternatively it also works where the > mail daemon is running directly on the machine running spamd. > > To run the mail daemon on another machine in the same subnet _alongside_ > spamd, you need to provide a way to get the return packets back through > the spamd machine; if the mail server was running OoenBSD you could > probably do this with "pass in quick from !192.168.20.0/24 to port > smtp reply-to 192.168.20.16". There might be a way to do this with the > version of PF in MacOS but I couldn't say how. > > To be honest what I would do in your situation is forget about spamd. > You could use postfix with postscreen and enable "after-greeting" tests, > which means that an unknown client must attempt a connection, get a > temporary failure, and reconnect (which it can do straight away) > before being able to send mail. Or you could use explicit greylisting > software (e.g. postgrey, policyd) or spam-filtering software that can > also do greylisting (rspamd can do this and is typically configured > to skip greylisting on mail with a low spam-score, which significantly > reduces the negative impact of greylisting). > > > -- > Please keep replies on the mailing list. >
Re: C states lost on amd64
... and with the latest snapshot, they are back. OpenBSD 7.1-current (GENERIC.MP) #556: Thu May 26 12:15:05 MDT 2022 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 14861991936 (14173MB) avail mem = 14394216448 (13727MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xf0100 (36 entries) bios0: vendor Award Software International, Inc. version "F2" date 04/20/2011 bios0: Gigabyte Technology Co., Ltd. Z68MX-UD2H-B3 acpi0 at bios0: ACPI 1.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP HPET MCFG ASPT SSPT EUDS MATS TAMG APIC SSDT MATS acpi0: wakeup devices PCI0(S5) PEX0(S5) PEX1(S5) PEX2(S5) PEX3(S5) PEX4(S5) PEX5(S5) PEX6(S5) PEX7(S5) HUB0(S5) UAR1(S3) USBE(S3) USE2(S3) AZAL(S5) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 acpimcfg0: addr 0xf400, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3193.20 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,MD_CLEAR,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, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz, 3192.76 MHz, 06-2a-07 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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) Core(TM) i5-2400 CPU @ 3.10GHz, 3192.76 MHz, 06-2a-07 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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN 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) Core(TM) i5-2400 CPU @ 3.10GHz, 3192.76 MHz, 06-2a-07 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,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins, remapped acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus 1 (PEX0) acpiprt4 at acpi0: bus -1 (PEX1) acpiprt5 at acpi0: bus -1 (PEX2) acpiprt6 at acpi0: bus 2 (PEX3) acpiprt7 at acpi0: bus 3 (PEX4) acpiprt8 at acpi0: bus 4 (PEX5) acpiprt9 at acpi0: bus 5 (PEX6) acpiprt10 at acpi0: bus 6 (PEX7) acpibtn0 at acpi0: PWRB acpipci0 at acpi0 PCI0 acpicmos0 at acpi0 com0 at acpi0 UAR1 addr 0x3f8/0x8 irq 4: ns16550a, 16 byte fifo "pnp0c14" at acpi0 not configured acpicpu0 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(350@96 mwait.1@0x20), C2(500@64 mwait.1@0x10), C1(1000@1 mwait.1), PSS cpu0: using VERW MDS workaround (except on vmm entry) cpu0: Enhanced SpeedStep 3193 MHz: speeds: 3301, 3300, 3200, 3100, 3000, 2900, 2800, 2700, 2600, 2500, 2400, 2300, 2200, 2100, 2000, 1900, 1800, 1700, 1600 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 2000" rev 0x09 drm0 at inteldrm0 inteldrm0: apic 2 int 16, SANDYBRIDGE, gen 6 "Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured ehci0 at pci0 dev 26 function 0 "Intel 6 Series USB" rev 0x05: apic 2 int 18 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"
Re: spamd on VirtualBox vm - rdr-to rules not working as expected
On Thu, 26 May 2022, Arete wrote: My setup: Re-purposed Mac Mini running MacOS 12.4 Monterey, Postfix & Dovecot, smtp port-forwarded to this box from my firewall. OpenBSD 7.1 running in a VirtualBox machine on the same Mac Mini, with bridged networking enabled. insert obvious comment about OpenBSD's ability to run Postfix and Dovecot. a connection is never made to the Postfix server on the host machine (192.168.20.15:25). Sounds like a routing triangle. The host machine should have its default gateway as 192.168.20.16 and not the internet firewall. (for other protocols, you could NAT inbound requests to the .16 address, but this is smtp... you want the source IPs for spamd purposes, etc.) I’m sure there’s something I’m missing, but I haven’t been able to figure out what. Any insight is most appreciated. tcpdump or wireshark are a good way to see requests and responses (or lack thereof) P.S. dmesg for the OpenBSD VM: I suggest adjusting your virtual hardware for higher performance/lower overhead: wd0 at pciide0 channel 0 drive 0: OpenBSD supports virtio-scsi, much faster than emulated IDE em0 at pci0 dev 3 function 0 "Intel 82540EM" rev 0x02: apic 1 int 19, address 08:00:27:a4:36:7c OpenBSD supports virtio-net, which has lower overhead than a virtualized EM device. You also get much higher throughput with the host auich0 at pci0 dev 5 function 0 "Intel 82801AA AC97" rev 0x01: apic 1 int 21, ICH I suggest removing the emulated sound card
Re: spamd on VirtualBox vm - rdr-to rules not working as expected
On 2022-05-27, Arete wrote: > I’m setting up spamd in front of a Postfix mail server, and am having > an issue with rdr-to rules not working the way I expect. > > My setup: Re-purposed Mac Mini running MacOS 12.4 Monterey, Postfix & > Dovecot, smtp port-forwarded to this box from my firewall. OpenBSD 7.1 > running in a VirtualBox machine on the same Mac Mini, with bridged > networking enabled. > > Postfix on the Mac Mini can receive mail just fine from the internet > through the firewall. The mini has the IP address 192.168.20.15. > OpenBSD is configured and running with spamd (greylisting enabled) in > the VM, with IP address 192.168.20.16 - pf.conf rules as follows: So if I understand correctly you have internet -> firewall -> 192.168.20.0/24 and in 192.168.20.0/24 you have - firewall - vm running spamd - machine running postfix incoming packet flow is internet -> firewall -> spamd -> postfix, but as the source address is unchanged by rdr-to, return packet flow is postfix -> firewall -> internet, bypassing the spamd vm, so there is nothing to "untranslate" the rdr-to. The classic spamd setup is where it's run on a firewall which is set as default gateway on the mail server. Alternatively it also works where the mail daemon is running directly on the machine running spamd. To run the mail daemon on another machine in the same subnet _alongside_ spamd, you need to provide a way to get the return packets back through the spamd machine; if the mail server was running OoenBSD you could probably do this with "pass in quick from !192.168.20.0/24 to port smtp reply-to 192.168.20.16". There might be a way to do this with the version of PF in MacOS but I couldn't say how. To be honest what I would do in your situation is forget about spamd. You could use postfix with postscreen and enable "after-greeting" tests, which means that an unknown client must attempt a connection, get a temporary failure, and reconnect (which it can do straight away) before being able to send mail. Or you could use explicit greylisting software (e.g. postgrey, policyd) or spam-filtering software that can also do greylisting (rspamd can do this and is typically configured to skip greylisting on mail with a low spam-score, which significantly reduces the negative impact of greylisting). -- Please keep replies on the mailing list.
