Re: Not possible to sysupgrade via snapshots right now?
On Sat, May 8, 2021 9:19 pm, Scott Vanderbilt wrote: > On 5/8/2021 6:04 PM, trondd wrote: >> On Sat, May 8, 2021 7:58 pm, Scott Vanderbilt wrote: >>> Apologies if this is a question to which there is an obvious answer, >>> but >>> I could not find one in the sysupgrade man page, >> >> What is sysupgrade trying to do? What do you want it to do? >> >> No? Read it again. It's not that long. >> > > Another responder politely pointed out I needed to add the -s switch, > which in fact eliminated the error. > > But your reply seems to imply I'm doing something unreasonable. > I looked at the -s switch in the man page, where it says: > > -sUpgrade to a snapshot. This is the default if the system > is currently running a snapshot. > > I thus disregarded this switch for two reasons: > > (1) As I am already running a snapshot (6.9-current as stated in my > original post), I concluded that the switch would effectively be a NOOP > since it specifically says it's the _default behavior_ under these > circumstances. > > (2) I've used sysupgrade without the -s switch for years and it's always > worked fine. > > What is not clear or explained anywhere that I can find is why it > behaves differently right now. Notwithstanding your suggestion, reading > the man page more than once does not make the answer magically appear. > Probably too late now, but what did `sysctl kern.version` actually show? If you were still in the period after -beta and before switching back to -current, the system will be detected as a release version.
Re: Not possible to sysupgrade via snapshots right now?
On 5/8/2021 6:04 PM, trondd wrote: On Sat, May 8, 2021 7:58 pm, Scott Vanderbilt wrote: Apologies if this is a question to which there is an obvious answer, but I could not find one in the sysupgrade man page, What is sysupgrade trying to do? What do you want it to do? No? Read it again. It's not that long. Another responder politely pointed out I needed to add the -s switch, which in fact eliminated the error. But your reply seems to imply I'm doing something unreasonable. I looked at the -s switch in the man page, where it says: -s Upgrade to a snapshot. This is the default if the system is currently running a snapshot. I thus disregarded this switch for two reasons: (1) As I am already running a snapshot (6.9-current as stated in my original post), I concluded that the switch would effectively be a NOOP since it specifically says it's the _default behavior_ under these circumstances. (2) I've used sysupgrade without the -s switch for years and it's always worked fine. What is not clear or explained anywhere that I can find is why it behaves differently right now. Notwithstanding your suggestion, reading the man page more than once does not make the answer magically appear.
Re: Not possible to sysupgrade via snapshots right now?
On Sat, May 8, 2021 9:04 pm, trondd wrote: > On Sat, May 8, 2021 7:58 pm, Scott Vanderbilt wrote: >> Apologies if this is a question to which there is an obvious answer, but >> I could not find one in the sysupgrade man page, > > What is sysupgrade trying to do? What do you want it to do? > > No? Read it again. It's not that long. > That got sent before I was ready. :( Reread the man page, is what I was refering to.
Re: Not possible to sysupgrade via snapshots right now?
On Sat, May 8, 2021 7:58 pm, Scott Vanderbilt wrote: > Apologies if this is a question to which there is an obvious answer, but > I could not find one in the sysupgrade man page, What is sysupgrade trying to do? What do you want it to do? No? Read it again. It's not that long.
Not possible to sysupgrade via snapshots right now?
Apologies if this is a question to which there is an obvious answer, but I could not find one in the sysupgrade man page, in the FAQ, or by Googling. Is it not possible to do a sysupgrade from 6.9-current to latest using snapshots at the moment? When I try, I get the following response from sysupgrade: $ doas sysupgrade Fetching from https://ftp.OpenBSD.org/pub/OpenBSD/7.0/amd64/ sysupgrade: Error retrieving https://ftp.OpenBSD.org/pub/OpenBSD/7.0/amd64/SHA256.sig: 404 Not Found It's been this way for the past three days. Presumably something to do with the recent release of 6.9. Many thanks in advance.
Thinkpad P50 "OpenBSD 6.9 freeze using X"
Hello, I'm running 6.9 fresh install with cwm on Thinkpad P50, OS freeze after 5 to 10 min of use, on text mode the system is fine only when using X the system freeze. Any suggestions would be great. Thanks Jacky OpenBSD 6.9 (GENERIC.MP) #473: Mon Apr 19 10:40:28 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 33679724544 (32119MB) avail mem = 32643620864 (31131MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x8702f000 (65 entries) bios0: vendor LENOVO version "N1EET89W (1.62 )" date 06/18/2020 bios0: LENOVO 20EQS1J600 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP UEFI SSDT SSDT ECDT HPET APIC MCFG SSDT DBGP DBG2 BOOT BATB SLIC SSDT SSDT MSDM SSDT SSDT ASF! FPDT UEFI acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) XHCI(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 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) i7-6820HQ CPU @ 2.70GHz, 2594.92 MHz, 06-5e-03 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,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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 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) i7-6820HQ CPU @ 2.70GHz, 2593.97 MHz, 06-5e-03 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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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) i7-6820HQ CPU @ 2.70GHz, 2593.96 MHz, 06-5e-03 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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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) i7-6820HQ CPU @ 2.70GHz, 2593.96 MHz, 06-5e-03 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,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,SGX,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SRBDS_CTRL,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,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, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 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 (EXP1) acpiprt5 at acpi0: bus -1 (EXP3) acpiprt6 at acpi0: bus -1 (EXP4) acpiprt7 at acpi0: bus 2 (EXP5) acpiprt8 at acpi0: bus -1 (RP09) acpiprt9 at acpi0: bus 6 (EX13) acpiprt10 at acpi0: bus -1 (EX17) acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpipci0 at acpi0 PCI0: 0x0010 0x0011 0x acpicmos0 at acpi0 acpibat0 at acpi0: BAT0 model "00NY493" serial 953 type LiP oem "SMP" acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0: version 1.0 "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured "PNP
miniroot.img boot-looping on rpi-4b
Hello, I am trying to install OpenBSD 6.9 on a Raspberry Pi 4B. I copied miniroot69.img to the SD card with this command: dd if=miniroot69.img of=/dev/rdisk2 bs=1m I put it in the Pi and upon boot it fails with this error message printed out through serial: U-Boot 2021.01 (Apr 16 2021 - 15:39:01 +1000) DRAM: 1.9 GiB RPI 4 Model B (0xb03114) MMC: mmcnr@7e30: 1, emmc2@7e34: 0 Loading Environment from FAT... ** No partition table - mmc 0 ** In:serial Out: serial Err: serial Net: eth0: ethernet@7d58 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: probe failed, error -110 No working controllers found Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ** Bad device specification :1 bootfstype ** "Synchronous Abort" handler, esr 0x9604 elr: 0009197c lr : 000930c8 (reloc) elr: 3b36d97c lr : 3b36f0c8 x0 : 6d63625f646e7320 x1 : 5f656c62 x2 : 3b3d30a0 x3 : 0001 x4 : 3afe9fe0 x5 : x6 : 3b3d30a0 x7 : 3b3d30b0 x8 : 3afea070 x9 : 0008 x10: 3b3d07f2 x11: 3af64780 x12: x13: 0004 x14: 3af4be58 x15: x16: 4110 x17: 2285e5950900a046 x18: 3af57da0 x19: 3afe9940 x20: 0811 x21: 0811 x22: x23: x24: x25: x26: 0028 x27: 0003 x28: x29: 3af4bac0 Code: 2a1b03e1 97e5 2a0003f8 140d (f8777800) Resetting CPU ... resetting ... Any help would be appreciated. Rob
Re: Home Assistant
There is some guidance for installing Home Assistant on FreeBSD. Probably the most useful piece of the article is the init script that starts Home Assistant from a virtual env. I bet with minor tweaks, you could get this to work on OpenBSD. https://community.home-assistant.io/t/installation-of-home-assistant-on-your-freenas/195158 On Sat, May 8, 2021 at 1:12 PM pas...@pascallen.nl wrote: > Dear all, > > What would be the best way to install HASS on Openbsd? > Containers are a nogo? > > Run it in virtual env from python? > > Any Howto on the subject with Openbsd? > > > Currently I got it running as from the website with the "core" version. > But a startup script which runs with a non-root user is where I get > stuck. > > > > > -- > Met vriendelijke groet, > > Pascal Huisman > > > Fundamentally, there may be no basis for anything. > >
Home Assistant
Dear all, What would be the best way to install HASS on Openbsd? Containers are a nogo? Run it in virtual env from python? Any Howto on the subject with Openbsd? Currently I got it running as from the website with the "core" version. But a startup script which runs with a non-root user is where I get stuck. -- Met vriendelijke groet, Pascal Huisman Fundamentally, there may be no basis for anything. signature.asc Description: This is a digitally signed message part
Bidirectional audio between OpenBSD sndiod <-> Debian pulseaudio
Hi list, It is great to have bidirectional audio between OpenBSD host and Debian guest (headless). I hope I move in a right way to make this thing working. Required configuration: mic-in on OpenBSD host >> Debian VMM guest audio-out from Debian VMM guest >> OpenBSD host Does anybody using pulseaudio or any other driver to have bidirectional network audio stream between VMM guest and OpenBSD host system? Martin
Re: Openbsd 6.9 Default gateway
Thank you You are right Irshad > On 8 May 2021, at 11:55 AM, Stuart Henderson wrote: > > On 2021-05-07, Irshad Sulaiman wrote: >> Hi >>How to set only one default gateway if I have multiple interface , one is >> in DHCP and other in Static ip >> I have set /etc/mygate 192.168.100.1 and hostname.em0 (DHCP) and >> hostname.iwn0 (static 192.168.100.163 255.255.255.0) > > Sounds like you want to request an address by DHCP, but ignore the gateway > handed out by the DHCP server; "ignore routers;" in dhclient.conf should > do the trick. > >
Re: openssl cms -encrypt does not work with EC key/cert
On 2021-05-08, Theodore Wynnychenko wrote: > > Hello again: > > I am re-posting this message with additional information.. > While I have no expectation that there will be any reply, I am hopeful there > may be. Confirmed, and it also fails with OpenSSL 1.0.2u, but succeeds with 1.1.1k. I think perhaps this is just something that has been added to newer OpenSSL but not added to LibreSSL yet.
Read SMART from NVME disks like 'atactl /dev/sdx smartstatus' for HDDs
Hi list, I'm looking a way to monitor SMART alike parameters of NVME drives in OpenBSD 6.9amd64. How do people monitor modern disks? Martin
Re: openssl cms -encrypt does not work with EC key/cert
Hello again: I am re-posting this message with additional information.. While I have no expectation that there will be any reply, I am hopeful there may be. In any case, I have been struggling with this, and cannot get it to work with EC certificates. I am now wondering if this is a bug or a, currently, unsupported function in Libressl.. $ openssl version LibreSSL 3.3.2 > Hello > > > I recently decided to change from RSA to EC keys/certs. > I do this primarily as a learning exercise (there is no real corporate > or > professional demand to have this working). > I am running OpenBSD current (6.9) from about 1 month ago. > > Now that I am migrating to EC keys/certificates, I need to switch to > "openssl cms". It is my understanding that openssl smime only supports RSA certs, but openssl cms should support RSA and EC certificates. > > However, I am unable to encrypt using the EC certificate. > > When I use: > (I am going to obfuscate the emails in plain text.) > > cat text.in | /usr/bin/openssl cms -encrypt -from 'User > ' -to 'Admin ' -subject "Test > Email" > -aes256 encryption.pem > encrypted.out > > with the old RSA certificate, everything works as expected. > > But, when I replace the RSA cert with the EC certificate, it does not. > Instead, I see: > > 15724089243112:error:2EFFF06F:CMS routines:CRYPTO_internal:ctrl > failure:/usr/src/lib/libcrypto/cms/cms_env.c:124: > 15724089243112:error:2EFFF074:CMS routines:CRYPTO_internal:error > setting > recipientinfo:/usr/src/lib/libcrypto/cms/cms_env.c:944: > 15724089243112:error:2EFFF068:CMS routines:CRYPTO_internal:cms > lib:/usr/src/lib/libcrypto/cms/cms_smime.c:850: > > And the output file is zero size. > > I tried a more basic command: > > openssl cms -encrypt -in text.in -out encrypted.out -recip > encryption.pem > > Works with RSA certificate, same error with EC certificate. > > I also tried (not really understanding): > > openssl cms -encrypt -in text.in -out encrypted.out -recip > encryption.pem > -keyopt ecdh_kdf_md:sha256 > > and got the same error. > > I then created some very basic self-signed EC certs. > ... > > The second with the CN as the email, but no email in the DN: > > Certificate: > Data: > Version: 1 (0x0) > Serial Number: > e5:fd:15:21:f1:b2:71:de > Signature Algorithm: ecdsa-with-SHA384 > Issuer: C=US, ST=State, L=City, O=Org, OU=Home, > CN=ad...@example.com > Validity > Not Before: May 6 17:18:43 2021 GMT > Not After : May 6 17:18:43 2022 GMT > Subject: C=US, ST=State, L=City, O=Org, OU=Home, > CN=ad...@example.com > Subject Public Key Info: > Public Key Algorithm: id-ecPublicKey > Public-Key: (384 bit) > pub: > 04:8e:11:20:73:c8:8d:5d:61:43:c4:6b:bf:04:fe: > c6:5d:a8:22:79:ae:0a:eb:de:0b:67:e6:32:24:43: > 30:56:61:0a:e6:31:e4:82:cc:a8:9c:37:e9:90:01: > df:e7:90:79:dc:d5:f1:c6:0c:6e:2f:bd:51:f8:98: > 4e:4b:1b:16:52:73:73:d6:fd:1f:00:a1:f6:39:03: > 98:3e:64:43:77:c3:c5:95:61:c3:22:05:3c:e6:d2: > 86:29:e1:a3:9c:b9:32 > ASN1 OID: secp384r1 > NIST CURVE: P-384 > Signature Algorithm: ecdsa-with-SHA384 > 30:64:02:30:3f:06:2c:b1:e1:2f:b1:0b:1e:a1:1a:eb:29:1e: > 8c:e5:c4:6a:73:f5:43:4e:24:77:88:bf:b1:99:51:15:02:50: > 12:cd:50:ae:d1:7f:4f:e5:3b:ba:38:06:c4:26:ea:4b:02:30: > 66:9d:a4:38:7e:45:ed:7d:db:7c:3e:f9:f7:68:80:e0:13:79: > 8b:85:9c:5d:b6:29:91:73:59:04:6a:73:8e:bb:bb:15:49:cc: > 68:63:25:b9:c6:fe:30:40:39:65:97:57 > > Both using the same EC secp384r1 key. > > When I try to do the most (I think) basic openssl cms -encrypt, I get > the > same error. > > openssl cms -encrypt -in in.txt -out encrypt.out test.pem > openssl cms -encrypt -in in.txt -out encrypt.out -recip test.pem > openssl cms -encrypt -in in.txt -out encrypt.out -recip test.pem - > keyopt > ecdh_kdf_md:sha256 > > with either of the certificates (email in DN or not), they all produce: > > 11034533897704:error:2EFFF06F:CMS routines:CRYPTO_internal:ctrl > failure:/usr/src/lib/libcrypto/cms/cms_env.c:124: > 11034533897704:error:2EFFF074:CMS routines:CRYPTO_internal:error > setting > recipientinfo:/usr/src/lib/libcrypto/cms/cms_env.c:944: > 11034533897704:error:2EFFF068:CMS routines:CRYPTO_internal:cms > lib:/usr/src/lib/libcrypto/cms/cms_smime.c:850: However, if I do the same thing (create a basic, self signed RSA certificate): Certificate: Data: Version: 1 (0x0) Serial Number: df:31:84:a5:79:b6:d4:7a Signature Algorithm: sha384WithRSAEncryption Issuer: C=US, ST=State, L=City, O=Org, OU=Home, CN=ad...@example.com Validity Not Before: May 8 13:18:17 2021 GMT Not After : May 8 13:18:17 2022 GMT
Re: pf ipv6 source-routing 6.9
Le 08/05/2021 à 11:56, Stuart Henderson a écrit : Does it work if you use the syntax suggested in the upgrade notes for the example with "pass in on pppoe1 reply-to ..."? For incoming connections, I tried pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state Those aren't exactly expected to work (I don't think pf really handles link locals)... that was my initial question, as the previous versions handled them correctly with "(ifname LLaddr)" pass in on pppoe0 inet6 reply-to (pppoe0:peer) keep state ...but I was hoping that this would (and it might possibly be a bug that it doesn't). It works with IPv4, but I don't think is handled the same way IPv4 is on this kind of links. my hostname.pppoe0 has : dest 0.0.0.1 inet6 eui64 !/usr/local/sbin/dhcp6c pppoe0 none of these worked If pf cannot handle LL anymore, I guess I'll have to downgrade to 6.8 :( -- Bastien Durel
Re: pf ipv6 source-routing 6.9
On 2021-05-08, Bastien Durel wrote:
> Le 08/05/2021 à 10:58, Stuart Henderson a écrit :
>> On 2021-05-08, Bastien Durel wrote:
>>> Le 07/05/2021 à 22:50, Stuart Henderson a écrit :
On 2021-05-07, Bastien Durel wrote:
> Hello,
>
> I have multiple ISPs plugged on my OpenBSD box, each one providing its
> IPv6 address space.
>
> I used to route outgoing streams with :
>
> net2_if = pppoe0
> ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
> ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
> table const { $ovh_v6_prefix, $free_v6_prefix,
> $ripe_v6_prefix }
> pass out on $net_if from $ovh_v6_prefix to ! route-to
> $ovh_v6_router
> pass out on $tun_ifs from $ovh_v6_prefix to ! route-to
> $ovh_v6_router
This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
>>> I read the upgrade note, but there is nothing about IPv6 LL addresses
>>>
>>> As said in my previous e-mail :
I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0
>>
>> Does it work if you use the syntax suggested in the upgrade notes
>> for the example with "pass in on pppoe1 reply-to ..."?
>>
>>
> For incoming connections, I tried
>
> pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
> pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state
Those aren't exactly expected to work (I don't think pf really
handles link locals)...
> pass in on pppoe0 inet6 reply-to (pppoe0:peer) keep state
...but I was hoping that this would (and it might possibly be a bug
that it doesn't).
>
> none of these worked
>
Re: pf ipv6 source-routing 6.9
Le 08/05/2021 à 10:58, Stuart Henderson a écrit :
On 2021-05-08, Bastien Durel wrote:
Le 07/05/2021 à 22:50, Stuart Henderson a écrit :
On 2021-05-07, Bastien Durel wrote:
Hello,
I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.
I used to route outgoing streams with :
net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to ! route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to ! route-to $ovh_v6_router
This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
I read the upgrade note, but there is nothing about IPv6 LL addresses
As said in my previous e-mail :
I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
For incoming connections, I tried
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800%pppoe0 keep state
pass in on pppoe0 inet6 reply-to fe80::520f:80ff:fe65:8800 keep state
pass in on pppoe0 inet6 reply-to (pppoe0:peer) keep state
none of these worked
--
Bastien Durel
Re: pf ipv6 source-routing 6.9
On 2021-05-08, Bastien Durel wrote:
> Le 07/05/2021 à 22:50, Stuart Henderson a écrit :
>> On 2021-05-07, Bastien Durel wrote:
>>> Hello,
>>>
>>> I have multiple ISPs plugged on my OpenBSD box, each one providing its
>>> IPv6 address space.
>>>
>>> I used to route outgoing streams with :
>>>
>>> net2_if = pppoe0
>>> ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
>>> ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
>>> table const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
>>> pass out on $net_if from $ovh_v6_prefix to ! route-to
>>> $ovh_v6_router
>>> pass out on $tun_ifs from $ovh_v6_prefix to ! route-to
>>> $ovh_v6_router
>>
>> This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
>>
>>
> I read the upgrade note, but there is nothing about IPv6 LL addresses
>
> As said in my previous e-mail :
> > I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0
Does it work if you use the syntax suggested in the upgrade notes
for the example with "pass in on pppoe1 reply-to ..."?
Re: Openbsd 6.9 Default gateway
On 2021-05-07, Irshad Sulaiman wrote: > Hi > How to set only one default gateway if I have multiple interface , one is > in DHCP and other in Static ip > I have set /etc/mygate 192.168.100.1 and hostname.em0 (DHCP) and > hostname.iwn0 (static 192.168.100.163 255.255.255.0) Sounds like you want to request an address by DHCP, but ignore the gateway handed out by the DHCP server; "ignore routers;" in dhclient.conf should do the trick.
Re: Can't compile php from ports
On Fri, May 07, 2021 at 11:08:00PM +, Mik J wrote: > Hello, > Does anyone knows why compiling php from ports systematically fails ? It's > been since openbsd 6.8 that it acts this way Why do you ask this on misc@ instead of ports@ ? Second, it actually works for all of us... so it must be something you're doing. > Renaming /usr/ports/pobj/php-7.4.19/fake-amd64/debug-pkg/Makefile.new to > Makefile > > Extracting debug info from > > /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/php-7.4 [...] > Installing /usr/ports/lang/php/7.4/pkg/php74_fpm.rc as > /usr/ports/pobj/php-7.4.19/fake-amd64/etc/rc.d/php74_fpm > ===> Building package for php-7.4.19 > Create /usr/ports/packages/amd64/all/php-7.4.19.tgz > Creating package php-7.4.19 > Creating package debug-php-7.4.19 > Link to /usr/ports/packages/amd64/ftp/php-7.4.19.tgz > Link to /usr/ports/packages/amd64/ftp/debug-php-7.4.19.tgz > `/usr/ports/pobj/php-7.4.19/fake-amd64/.fake_done' is up to date. > > Extracting debug info from > > /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/php-7.4 > Warning: no debug-info in > /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/php-7.4 > dwz: /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/.debug/php-7.4.dbg: > .debug_info section not present > objcopy: > /usr/ports/pobj/php-7.4.19/fake-amd64/usr/local/bin/.debug/php-7.4.dbg: > Invalid operation oh look, it's doing the same thing TWICE. But wait: there's a Makefile involved. Now why would it do that ? It could only happen if somehow, the dates are completely wacked. Would you by any chance use NFS for your pobj tree, or anything that would get your clock to act strangely ?...
Re: pf ipv6 source-routing 6.9
Le 07/05/2021 à 22:50, Stuart Henderson a écrit :
On 2021-05-07, Bastien Durel wrote:
Hello,
I have multiple ISPs plugged on my OpenBSD box, each one providing its
IPv6 address space.
I used to route outgoing streams with :
net2_if = pppoe0
ovh_v6_router = "(" $net2_if fe80::230:88ff:fe04:63c9 ")"
ovh_v6_prefix = "2001:41d0:fe4b:ec00::0/56"
table const { $ovh_v6_prefix, $free_v6_prefix, $ripe_v6_prefix }
pass out on $net_if from $ovh_v6_prefix to ! route-to $ovh_v6_router
pass out on $tun_ifs from $ovh_v6_prefix to ! route-to $ovh_v6_router
This is no longer valid syntax for route-to. Check the 6.9 upgrade notes.
I read the upgrade note, but there is nothing about IPv6 LL addresses
As said in my previous e-mail :
> I replaced ovh_v6_router by fe80::230:88ff:fe04:63c9%pppoe0
--
Bastien Durel
