Re: Encrypt traffic using one interface
-Original Message-
From: owner-m...@openbsd.org
Sent: Thursday, 4 November 2021 7:50 AM
To: misc@openbsd.org
Subject: Encrypt traffic using one interface
set skip on lo
set skip on enc0
match in all scrub (no-df)
block return
block in from { $ipv4_exthost, $ipv6_exthost } block in quick on egress from
$localIPs block out quick on egress to $localIPs block in quick from
pass in on $int_if proto udp from 192.168.1.2 to 192.168.1.1 port 500 pass
out on $int_if proto udp from 192.168.1.1 to 192.168.1.2 port 500 pass in on
$int_if proto esp from 192.168.1.2 to 192.168.1.1 pass out on $int_if proto
esp from 192.168.1.1 to 192.168.1.2 [...]
The above should work. It appears that your IKE session is working correctly
(I usually stick with the defaults). Things to try would be placing a
'quick' in your udp/esp rules in the event that there is some rule below it
that we can't see, causing a different outcome. Also, your 'block' above
that rule is pretty aggressive and we have no idea what is in your macros or
table. What happens if you add to these existing rules 'port { 500, 4500 }'.
I know NAT isn't involved here between the two hosts, but I have been
surprised where I haven't used any NAT but still see 4500 traffic for some
reason.
Jason.
Re: rc.firsttime after package daemons
> On Nov 3, 2021, at 01:42, Kapetanakis Giannis > wrote: > Anyway, I followed Stuart's advice of adding a second DNS server in > resolv.conf apart from 127.0.0.1 > which was my usual practice for caching servers. I see no harm on this. I generally always run resolving and authoritative servers as pairs. For authoritative servers, that’s obvious. For resolving servers, it’s less obvious, but it’s so I can do maintenance on one of them (at a time) and not kill everything that uses them. And if you run two resolving servers, point both of them at both of them. :-) Sean
Re: mmap with the arguments PROT_NONE and MAP_STACK
overcq wrote: > Theo de Raadt wrote: > > > There would need to be justification for why that program wants to do > > that, before changing this. The restriction for stacks is a bit like > > a safety belt. > > I don't know how much stack each task will need, and I reserve all tasks > equally from all available memory. When a new task is created, > I take away the top of the stack from everyone else, so that again > all tasks have the same amount of the stack reserved. But I allocate > real memory only after the task reaches for this memory. > > Perhaps the solution is not to change this protection, as it is only > a matter of ensuring that real memory is not allocated before it is used That is not making any sense to me. The mmap calls do not allocate memory. Instead, mmap allocates address space, indicating a allocation/permission policy, which allows the kernel to fault in (provide) memory when required. A page of memory in the range is not actually allocated from the system until code touches it.
Re: mmap with the arguments PROT_NONE and MAP_STACK
overcq wrote: > Hello, > > I am trying to run a program I wrote that was ported from Linux. > It allows you to run in-program tasks as C functions. Each such task > is set up with its own allocated stack. > > However, in OpenBSD I cannot allocate the stack with mmap > with the PROT_NONE flag, and later in the SIGSEGV handler change > mprotect to PROT_READ | PROT_WRITE because mmap returns with error > errno == 22 (Invalid argument). > > Is there a workaround for this so that you don't have to allocate > the entire stack first? > > Below is a link to the code where mmap returns with an error: > https://github.com/overcq/oux/blob/master/module/base/flow-drv.cx#L188 At the moment we require stacks to be R|W sys/uvm/uvm_mmap.c line 260 There would need to be justification for why that program wants to do that, before changing this. The restriction for stacks is a bit like a safety belt.
Re: Mouse scrolling issues for anyone else?
Ricky Cintron wrote: > I'm a bit confused as to why the snapshot from Oct. 30 included a > commit from Oct. 31, but everything else seems clear now. Diffs under review often land in snapshots.
Re: iwm stopped working on 7.0 after installing patches 001,002,003
On Wed, Nov 03, 2021 at 08:34:19AM -0600, Theo de Raadt wrote: > I do not think it is the errata, because they are completely unrelated > to 802.11 drivers or stack. You can look at the errata closer and > realize it has nothing to do with wifi. > > I suspect your firmware was updated. Or you changed something else. > > > Doros Eracledes wrote: > > > Thanks Stefan, I did try booting the snapshot bsd.rd kernel but got an > > error about failing to load firmware, see attached screenshot. Testing with bsd.rd is tricky because you will need to mount your installed rootfs at /mnt before firmware can be loaded. The ramdisk kernel does not carry intel wifi firmware files. So please trying booting bsd.mp (.mp, not .rd) instead. You should end up in your installed 7.0 system. A new kernel with old userland is technically not a supported system configuration but it should be good enough to confirm whether wifi is working at all, and you can go back to your reguler kernel afterwards. You could also upgrade your system to a -current snapshot using the bsd.rd kernel you have. But then there is no way back to 7.0. FWIW, my 9560 device seems to be working just fine in -current.
Re: iwm stopped working on 7.0 after installing patches 001,002,003
I do not think it is the errata, because they are completely unrelated to 802.11 drivers or stack. You can look at the errata closer and realize it has nothing to do with wifi. I suspect your firmware was updated. Or you changed something else. Doros Eracledes wrote: > Thanks Stefan, I did try booting the snapshot bsd.rd kernel but got an > error about failing to load firmware, see attached screenshot. > > thanks > Doros > > On Wed, 3 Nov 2021, 4:05 pm Stefan Sperling, wrote: > > > > > > > Could you please give a -current kernel a try to see whether this > > issue has been fixed since? Temporarily booting into a bsd.mp image > > from the latest snapshot should be enough for testing purposes. > > You do not need to upgrade the entire system if you do not want to. > >
Re: iwm stopped working on 7.0 after installing patches 001,002,003
On Wed, Nov 03, 2021 at 03:36:38PM +0200, Doros Eracledes wrote: > Hi, > > my iwm0 on my Lenovo T490 stopped working right after installing 7.0 > patches 001,002 and 003 and rebooting. I "takes" an ip from the router but I > can't ping the router. > > I then tried with a USB urtwn and it worked fine, I also uninstalled the > firmware and reinstalled it and rebooted but no change. > > Thanks Doros Could you please give a -current kernel a try to see whether this issue has been fixed since? Temporarily booting into a bsd.mp image from the latest snapshot should be enough for testing purposes. You do not need to upgrade the entire system if you do not want to.
iwm stopped working on 7.0 after installing patches 001,002,003
Hi, my iwm0 on my Lenovo T490 stopped working right after installing 7.0 patches 001,002 and 003 and rebooting. I "takes" an ip from the router but I can't ping the router. I then tried with a USB urtwn and it worked fine, I also uninstalled the firmware and reinstalled it and rebooted but no change. Thanks Doros OpenBSD 7.0 (GENERIC.MP) #1: Fri Oct 29 12:04:07 MDT 2021 r...@syspatch-70-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16801161216 (16022MB) avail mem = 16275922944 (15521MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0x5ddf5000 (68 entries) bios0: vendor LENOVO version "N2IET73W (1.51 )" date 07/18/2019 bios0: LENOVO 20N2000CCY acpi0 at bios0: ACPI 6.1 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT SSDT SSDT TPM2 UEFI SSDT HPET APIC MCFG ECDT SSDT SSDT BOOT SLIC SSDT LPIT WSMT SSDT DBGP DBG2 MSDM BATB NHLT FPDT UEFI DMAR BGRT acpi0: wakeup devices GLAN(S4) XHC_(S3) XDCI(S4) HDAS(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 2399 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz, 1570.05 MHz, 06-8e-0b 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES 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 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz, 1500.71 MHz, 06-8e-0b 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES 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-8265U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0b 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES 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-8265U CPU @ 1.60GHz, 1496.52 MHz, 06-8e-0b 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,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,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus -1 (RP02) acpiprt3 at acpi0: bus -1 (RP03) acpiprt4 at acpi0: bus -1 (RP04) acpiprt5 at acpi0: bus 2 (RP05) acpiprt6 at acpi0: bus -1 (RP06) acpiprt7 at acpi0: bus -1 (RP07) acpiprt8 at acpi0: bus -1 (RP08) acpiprt9 at acpi0: bus 60 (RP09) acpiprt10 at acpi0: bus -1 (RP10) acpiprt11 at acpi0: bus -1 (RP11) acpiprt12 at acpi0: bus -1 (RP12) acpiprt13 at acpi0: bus 61 (RP13) acpiprt14 at acpi0: bus -1 (RP14) acpiprt15 at acpi0: bus -1 (RP15) acpiprt16 at acpi0: bus -1 (RP16) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at
Re: rc.firsttime after package daemons
On 03/11/2021 06:53, cho...@jtan.com wrote: > ... > > On the gripping hand, all it does is run fw_update and syspatch. This. Unless there is something more. Anyway, I followed Stuart's advice of adding a second DNS server in resolv.conf apart from 127.0.0.1 which was my usual practice for caching servers. I see no harm on this. Thanks for comments on unbound/nsd. I'm familiar and using those in another setup but it adds complexity when you want your caching servers to also have live copies (+live updates) of internal authoritative zones. You setup the zones twice (nsd and unbound stub-zone), which is not that bad, but you also have caching/negative caching on unbound until TTL or flush to see the updates/changes, which is more disturbing. G
Re: Mouse scrolling issues for anyone else?
* Ricky Cintron [2021-11-03 04:07]: > I'm not sure if this is a bug, so I'm sending this to misc to see if others > are experiencing the same thing (or can test to confirm the existence > of an issue). > > After upgrading my OpenBSD-current system this past Saturday (Oct. 30 > snapshot), > scrolling with my mouse in tmux and neovim stopped working. However, scrolling > in xterm, mupdf, and Firefox continues to work normally. I upgrade weekly, > so I don't know when this changed other than at some point during the week > after Saturday Oct. 23. I upgraded on Sunday and Monday to check if it was > already dealt with, but the issue remains. That looks like an intentional change: https://marc.info/?l=openbsd-cvs=163570554325770=2 You can enable mouse tracking again with: - CTRL+Right-Mouse-Button->Allow Mouse Ops - xterm -xrm 'xterm*allowMouseOps: true' - put the above setting into Xresources Regards Ralf
