Re: Resuming from suspend takes 12-14 seconds
amdgpu startup is slow. not our fault. Subhaditya Nath wrote: > Hi there! > > I have installed OpenBSD 6.9 on my ThinkPad E495, and I have run > syspatch and fw_update to install all the necessary patches and > firmwares. I have been running it for a few weeks now, and I absolutely > love it! > > Except, there is one very annoying issue. > Resuming from suspend _always_ takes 12-14 seconds at least. > > Say, I press the sleep button. Within two seconds, the PC goes into > sleep. Then, I press any button on the keyboard to wake up the PC. As > soon as I press the button, the POWER LED lights up, indicating that the > hardware is up and running. But, the screen stays OFF for the next 11-13 > seconds. Then, the display turns on and shows ttyC0, and after a second, > automatically switches to Xenocara. > > > Any idea what's causing the 11-13 second delay in the screen turning on? > How do I go about diagnosing the problem? > > > Also, in case it is relevant, I have noticed that these lines appear in > dmesg when I suspend and resume - > > uhub0 detached > video0 detached > uvideo0 detached > uhub1 detached > iwm0: acquiring device failed > uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev > 3.00/1.00 addr 1 > uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev > 3.00/1.00 addr 1 > uvideo0 at uhub1 port 2 configuration 1 interface 0 "SunplusIT Inc > Integrated Camera" rev 2.01/54.22 addr 2 > video0 at uvideo0 > > I presume that the first four lines are from suspending? And that the > remaining lines are from resuming? > > I wondered if it could be that the delay is being caused by the failure to > acquire iwm0? (iwm0 is my Intel WiFi card) > So, I disabled my WiFi in BIOS. I also disabled USB, Camera, Microphone, > Ethernet, and the Memory Card slot. But the problem is still there! > > Now, these lines appear on dmesg on suspend-resume (I don't know what > uhub0 and uhub1 are) - > > uhub0 detached > uhub1 detached > uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" > rev > 3.00/1.00 addr 1 > uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" > rev > 3.00/1.00 addr 1 > > > I have no idea what is causing the delay. Any help to identify the > problem is appreciated. > > Please pardon me if this is a simple mistake in my part... I am new to > OpenBSD :) > > > > The full dmesg (with everything except Bluetooth enabled) follows - > - > OpenBSD 6.9 (GENERIC.MP) #1: Sat May 22 13:19:59 MDT 2021 > > r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > real mem = 32103845888 (30616MB) > avail mem = 31115493376 (29674MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc627000 (58 entries) > bios0: vendor LENOVO version "R11ET40W (1.20 )" date 11/17/2020 > bios0: LENOVO 20NES02J00 > acpi0 at bios0: ACPI 5.0 > acpi0: sleep states S0 S3 S4 S5 > acpi0: tables DSDT FACP SSDT SSDT SSDT TPM2 SSDT MSDM BATB HPET APIC > MCFG SBST WSMT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI > acpi0: wakeup devices GPP0(S3) GPP1(S4) GPP2(S3) GPP3(S3) GPP4(S3) > GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) > SLPB(S3) > acpitimer0 at acpi0: 3579545 Hz, 32 bits > acpihpet0 at acpi0: 14318180 Hz > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx, 2096.33 MHz, 17-18-01 > cpu0: > FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 24MHz > cpu0: mwait min=64, max=64, C-substates=1.1, IBE > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx, 2096.08 MHz, 17-18-01 > cpu1: >
Resuming from suspend takes 12-14 seconds
Hi there! I have installed OpenBSD 6.9 on my ThinkPad E495, and I have run syspatch and fw_update to install all the necessary patches and firmwares. I have been running it for a few weeks now, and I absolutely love it! Except, there is one very annoying issue. Resuming from suspend _always_ takes 12-14 seconds at least. Say, I press the sleep button. Within two seconds, the PC goes into sleep. Then, I press any button on the keyboard to wake up the PC. As soon as I press the button, the POWER LED lights up, indicating that the hardware is up and running. But, the screen stays OFF for the next 11-13 seconds. Then, the display turns on and shows ttyC0, and after a second, automatically switches to Xenocara. Any idea what's causing the 11-13 second delay in the screen turning on? How do I go about diagnosing the problem? Also, in case it is relevant, I have noticed that these lines appear in dmesg when I suspend and resume - uhub0 detached video0 detached uvideo0 detached uhub1 detached iwm0: acquiring device failed uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 uvideo0 at uhub1 port 2 configuration 1 interface 0 "SunplusIT Inc Integrated Camera" rev 2.01/54.22 addr 2 video0 at uvideo0 I presume that the first four lines are from suspending? And that the remaining lines are from resuming? I wondered if it could be that the delay is being caused by the failure to acquire iwm0? (iwm0 is my Intel WiFi card) So, I disabled my WiFi in BIOS. I also disabled USB, Camera, Microphone, Ethernet, and the Memory Card slot. But the problem is still there! Now, these lines appear on dmesg on suspend-resume (I don't know what uhub0 and uhub1 are) - uhub0 detached uhub1 detached uhub0 at usb0 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 uhub1 at usb1 configuration 1 interface 0 "AMD xHCI root hub" rev 3.00/1.00 addr 1 I have no idea what is causing the delay. Any help to identify the problem is appreciated. Please pardon me if this is a simple mistake in my part... I am new to OpenBSD :) The full dmesg (with everything except Bluetooth enabled) follows - - OpenBSD 6.9 (GENERIC.MP) #1: Sat May 22 13:19:59 MDT 2021 r...@syspatch-69-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 32103845888 (30616MB) avail mem = 31115493376 (29674MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.1 @ 0xbc627000 (58 entries) bios0: vendor LENOVO version "R11ET40W (1.20 )" date 11/17/2020 bios0: LENOVO 20NES02J00 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT SSDT SSDT TPM2 SSDT MSDM BATB HPET APIC MCFG SBST WSMT IVRS SSDT CRAT CDIT FPDT SSDT SSDT SSDT UEFI acpi0: wakeup devices GPP0(S3) GPP1(S4) GPP2(S3) GPP3(S3) GPP4(S3) GPP5(S3) GPP6(S3) GP17(S3) XHC0(S3) XHC1(S3) GP18(S3) LID_(S3) SLPB(S3) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx, 2096.33 MHz, 17-18-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu0: ITLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: DTLB 64 4KB entries fully associative, 64 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=1.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx, 2096.08 MHz, 17-18-01 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,FMA3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,RDRAND,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,SKINIT,TCE,TOPEXT,CPCTR,DBKP,PCTRL3,MWAITX,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,RDSEED,ADX,SMAP,CLFLUSHOPT,SHA,IBPB,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 8-way L2 cache cpu1: ITLB 64 4KB entries fully
Re: after upgrade to 6.9, iked does not pass traffic
I have a vpn from a Windows machine to a network behind an OpenBSD router. It was working fine until I upgraded the router to 6.9 (amd64). The VPN is still coming up fine, but the traffic is blocked somehow. Using tcpdump on the interface protected by the router (vlan0 in my case), I see the ping requests from the remote vpn address, and the ping replies, but on enc0 I only see the requests. I confirmed that pf is not blocking packets. doas tcpdump -nni enc0 tcpdump: listening on enc0, link-type ENC 08:48:05.289341 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:09.914843 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:14.914988 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:19.915348 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) ^C 4 packets received by filter 0 packets dropped by kernel tcpdump -nni vlan0 host 192.168.9.208 tcpdump: listening on vlan0, link-type EN10MB 09:12:21.467671 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:21.468371 arp who-has 192.168.9.208 tell 192.168.9.101 09:12:21.468386 arp reply 192.168.9.208 is-at ec:eb:b8:5d:94:a0 09:12:21.468937 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:21.468961 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:26.410587 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:26.411144 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:26.411168 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:31.414257 192.168.9.208 > 192.168.9.101: icmp: echo request It looks like 'keep state (if-bound)' iked.conf(5) is not present or being respected on the return traffic to the VPN device/firewall from your internal network. ICMP traffic is coming into the VPN device encrypted, being decrypted and passed to the destination. The destination responds back but the VPN device is not taking those responses and pushing them back through enc0. We have updated a number of IKEv2 devices already without issue. Our testing environment where we are trying out different configurations and scenarios also working fine. Cheers, Jason.
Re: Using relayd as a reverse proxy for multiple local servers
Hi, In my testings, using « listen on * port https tls » doesn’t work either. What I did is replace the « * » with the IP address where I want relayd to listen to. And as my gateway has several interfaces, I created a relay section for each single interface I wanted relayd to bind to. Regards, Joel Envoyé de mon iPad > Le 27 mai 2021 à 11:03, Philip Kaludercic a écrit : > listen on * port https tls
after upgrade to 6.9, iked does not pass traffic
Hello, I have a vpn from a Windows machine to a network behind an OpenBSD router. It was working fine until I upgraded the router to 6.9 (amd64). The VPN is still coming up fine, but the traffic is blocked somehow. Using tcpdump on the interface protected by the router (vlan0 in my case), I see the ping requests from the remote vpn address, and the ping replies, but on enc0 I only see the requests. I confirmed that pf is not blocking packets. My setup : Remote Windows machine : fixed IP address 192.168.1.109 OpenBSD router : bge0 192.168.8.2 vlan0 192.168.9.2 also arp -s 192.168.9.208 12:34:56:ab:cd:ef permanent pub iked.conf : set nomobike ikev2 "windows" passive esp \ from 192.168.8.2 to 192.168.1.109 \ from 192.168.9.0/24 to 192.168.9.208 \ local 192.168.8.2 peer 192.168.1.109 \ srcid 192.168.8.2 \ rsa \ config address 192.168.9.208 \ config netmask 255.255.255.0 \ config name-server 192.168.1.222 \ config netbios-server 192.168.1.222 netstat -rn -inet (removing unrelated interfaces) : NameMtu Network Address Ipkts IerrsOpkts Oerrs Colls Time lo0 327680 00 0 0 0 lo0 32768 ::1/128 ::1 0 00 0 0 0 lo0 32768 fe80::%lo0/ fe80::1%lo0 0 00 0 0 0 lo0 32768 127/8 127.0.0.10 00 0 0 0 bge0150012:34:56:ab:cd:ef 167154089 0 36267061 0 00 bge01500 192.168.8/2 192.168.8.2 167154089 0 36267061 0 00 enc0* 0 140 00 0 0 0 vlan0 150012:34:56:ab:cd:ef 126698124 0 360 0 00 vlan0 1500 192.168.9/2 192.168.9.2 126698124 0 360 0 00 pflog0 331360 0 1642609 0 0 0 Log extract : May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: recv IKE_SA_INIT req 0 peer 192.168.1.109:500 local 192.168.8.2:500, 528 bytes, policy 'windows' May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: send IKE_SA_INIT res 0 peer 192.168.1.109:500 local 192.168.8.2:500, 278 bytes May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: recv IKE_AUTH req 1 peer 192.168.1.109:500 local 192.168.8.2:500, 7440 bytes, policy 'windows' May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: send IKE_AUTH res 1 peer 192.168.1.109:500 local 192.168.8.2:500, 1600 bytes May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: ikev2_childsa_enable: loaded SPIs: 0x6487e520, 0x36d4127b (enc aes-256 auth hmac-sha1) May 27 08:10:20 mymachine iked[14895]: spi=0x41f8d1c369853156: established peer 192.168.1.109:500[ASN1_DN//C=CA/ST=Quebec/L=Somewhere/O=Org/OU=Department/CN=192.168.1.109/emailAddress=xyz@domain.local] local 192.168.8.2:500[IPV4/192.168.8.2] policy 'windows' as responder (enc aes-256 auth hmac-sha2-256 group modp1024 prf hmac-sha2-256) doas tcpdump -nni enc0 tcpdump: listening on enc0, link-type ENC 08:48:05.289341 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:09.914843 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:14.914988 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) 08:48:19.915348 (authentic,confidential): SPI 0x11aad700: 192.168.9.208 > 192.168.9.101: icmp: echo request (encap) ^C 4 packets received by filter 0 packets dropped by kernel tcpdump -nni vlan0 host 192.168.9.208 tcpdump: listening on vlan0, link-type EN10MB 09:12:21.467671 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:21.468371 arp who-has 192.168.9.208 tell 192.168.9.101 09:12:21.468386 arp reply 192.168.9.208 is-at ec:eb:b8:5d:94:a0 09:12:21.468937 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:21.468961 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:26.410587 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:26.411144 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:26.411168 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:31.414257 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:31.415117 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:31.415141 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:36.409094 192.168.9.208 > 192.168.9.101: icmp: echo request 09:12:36.409680 192.168.9.101 > 192.168.9.208: icmp: echo reply 09:12:36.409705 192.168.9.101 > 192.168.9.208: icmp: echo reply ^C 3134 packets received by filter 0 packets dropped by kernel Thanks! Sebastien Leclerc
Re: Using relayd as a reverse proxy for multiple local servers
Kent Watsen writes: > A redacted version of my /etc/relayd.conf follows. But note that I > also have `httpd` running on this machine, listening for inbound port > 80 requests, in order to 1) handle ACME requests and 2) redirect all > port 80 requests to port 443. Both configs follow. Could it be that you have only one certificate, for every service? My understanding was that a protocol could specify more than one "tls keypair" directive, and the "right one" would be chosen, depending on the actual request. > PS: there are many ways to skin the cat. For example, you’re running > different httpd instances on ports versus my running them on different > VMs. I am not sure if this makes a difference, after all non-encrypted traffic operates the way it should. -- Philip K.
Re: libexpat.so.14.0 missing in latest -current
On Thu, May 27, 2021 at 4:53 PM Theo de Raadt wrote: > Occasionally a bad snapshot will ship out, because we are actively > developing. It is rare. Shrug. > > And OpenBSD even has some awesome tools to discover this, so it's really not a big problem and that tool is vmm. I have a VM that I upgrade first. If that goes swell, my primary and backup firewall gets the upgrade. -- chs
Re: libexpat.so.14.0 missing in latest -current
Anthony Campbell wrote: > After upgrading to -current today I found that xenodm would not run > because of a missing /usr/lib/libexpat.so.14.0_ Various other things > didn['t work either, including vim. > > As a temporary work-round I made a link for it to libexpat.so.13.0, > which seems to have made everything function again. Occasionally a bad snapshot will ship out, because we are actively developing. It is rare. Shrug.
Re: Using relayd as a reverse proxy for multiple local servers
I did this too, because I have:
1) a single external IP
2) multiple internal HTTP-based services
3) a port-based firewall policy
This whole issue would disappear, and remove a single point of failure
(relayd), if my firewall directed inbound traffic based on URLs (for port 80)
and SNI (for port 443). Alas, I’m not there yet, and this setup has been
working okay for me for a couple years now.
My biggest complaint is that, if one internal site is down (e.g., 'www'),
`relayd` will direct traffic to that site to another (‘blog’), which may seem
innocent, but could be a real problem if, e.g., the external IP is shared by
multiple domains and traffic to 'www.domain1.com' gets mapped to
‘www.domain2.com’. I’ve never really looked into solving the issue, as it’s
easier to restart the downed service, but would be thrilled if someone could
explain how to fix it.
A redacted version of my /etc/relayd.conf follows. But note that I also have
`httpd` running on this machine, listening for inbound port 80 requests, in
order to 1) handle ACME requests and 2) redirect all port 80 requests to port
443. Both configs follow.
PS: there are many ways to skin the cat. For example, you’re running different
httpd instances on ports versus my running them on different VMs. Also, how we
approach handling port 80 and ACME requests. Still, hopefully seeing my config
helps.
K.
/etc/httpd.conf
# This rule is used to redirect all (except ACME) external
# HTTP/80 requests to the HTTPS/443 equivalent.
#
# Note that `relayd` (/etc/relayd.conf) terminates *all*
# external HTTPS/443 requests and forward them to
# the appropriate HTTP/80 server
server "default" {
listen on egress port 80
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
location "*" {
block return 301 "https://$HTTP_HOST$REQUEST_URI;
}
}
/etc/relayd.conf
# this is the ONLY machine that accepts inbound connections to
# :443
#
# it uses the certificate maintained by Let's Encrypt (acme-client)
#
# it fowards the request to the correct :80
# via inspecting the "Host" HTTP header field's value
# define some variables
www_example_net="10.0.1.X"
blog_example_net=“10.0.1.Y"
git_example_net=“10.0.1.Z”
# make a table out of each
table { $www_example_net }
table { $blog_example_net }
table { $git_example_net }
# http protocol-specific rules
http protocol "my_http_protocol_config" {
match request header "Host" value "www.example.net" forward to
match request header "Host" value "blog.example.net" forward to
match request header "Host" value "git.example.net" forward to
match response header remove "Server"
# is this supposed to be "request" or "response"? (I see both in the
forums!)
match request header set "Connection" value "close"
match response header set "Connection" value "close"
tcp { nodelay, sack }
tls keypair example.net
}
# handle inbound port 443 traffic
relay "my_relay" {
listen on egress port 443 tls
protocol my_http_protocol_config
forward to port 80 check tcp
forward to port 80 check tcp
forward to port 80 check tcp
}
Re: libexpat.so.14.0 missing in latest -current
Hi, * Anthony Campbell wrote: > After upgrading to -current today I found that xenodm would not run > because of a missing /usr/lib/libexpat.so.14.0_ Various other things > didn['t work either, including vim. Had the same. Just fetch latest sets again and all is working. ftp.hostserver.de has the latest sets with the new libexpat. Cheers Matthias
libexpat.so.14.0 missing in latest -current
After upgrading to -current today I found that xenodm would not run because of a missing /usr/lib/libexpat.so.14.0_ Various other things didn['t work either, including vim. As a temporary work-round I made a link for it to libexpat.so.13.0, which seems to have made everything function again. -- Anthony Campbellhttps://www.acampbell.uk
Re: Usage of .note.openbsd.ident
Thank you for the reply, I was just curious. On Thu, 27 May 2021 at 04:21, Philip Guenther wrote: > > On Fri, May 21, 2021 at 5:28 AM George Brown <321.geo...@gmail.com> wrote: >> >> It seems this ELF note was used for the now dead compat_linux feature. >> Aside from compat systems in other operating systems that may wish to >> identify OpenBSD binaries does this note have any other active uses? > > > The point of the note (and/or the OS/ABI field in the ELF header) is to > permit portable ELF tools to identify how to interpret OS-specific values, > those in the OS-ranges for types, for example. Not inserting _some_ > identifying factor is basically doing an embrace-and-extend on ELF and > actively hostile to portability of tooling. > > If you find that ELF note obnoxious, just fix the linkers to instead set the > ELF ABI field correctly. As I understand it, the 'go' tool chain has done > that for years. It's really the better choice for this, would take less > space and be faster to process. > > > Philip Guenther >
Using relayd as a reverse proxy for multiple local servers
Hi,
I have been trying to configure relayd for a few days now to multiplex
multiple servers running on the same local machine, while at the same
time taking care of TLS.
A simplified state of my configuration looks something like this:
log connection
log state changes
table { 127.0.0.1 }
table { 127.0.0.1 }
table { 127.0.0.1 }
table { 127.0.0.1 }
http protocol "http" {
match request header "Host" value "example.com" forward to
match request header "Host" value "sub.example.com" forward to
match request header "Host" value "beispiel.de" forward to
match request path "/.well-known/acme*" forward to
}
http protocol "https" {
tls keypair "example.com" # responsible for example.com and
sub.example.com
tls keypair "beispiel.de"
match request header "Host" value "example.com" forward to
match request header "Host" value "sub.example.com" forward to
match request header "Host" value "beispiel.de" forward to
match request path "/.well-known/acme*" forward to
}
relay plain {
listen on * port http
protocol "http"
forward to port 8080
forward to port 8081
forward to port 8082
forward to port 8080
}
relay secure {
listen on * port https tls
protocol "https"
forward to port 8080
forward to port 8081
forward to port 8082
forward to port 8080
}
The "plain" relayd works just the way it should, it redirects every
request to the right destination. "secure" on the other hand triggers an
error I cannot make sense of:
# relayd -nvvv
relay_load_certfiles: using certificate /etc/ssl/example.com:443.crt
relay_load_certfiles: using private key /etc/ssl/private/example.com:443.key
relay_load_certfiles: using certificate /etc/ssl/beispiel.de:443.crt
relay_load_certfiles: using private key /etc/ssl/private/beispiel.de:443.key
/etc/relayd.conf:46: cannot load certificates for relay secure4:443
I have looked into the source code, but couldn't find where "secure4"
comes from. The certificates and keys were generated using acme-client,
and they have the default permissions (crt is 444, key is 400).
Am I doing the right thing here, considering what I want to achieve? I
would be very grateful for any comments or hints on what I could be
doing wrong.
--
Philip K.
Re: 6.9 + 001: uvm_fault
On Thu, May 27, 2021 at 07:57:28AM +0200, Harald Dunkel wrote: > On 5/17/21 12:27 AM, Antonino Sidoti wrote: > > Hi, > > > > I also have this issue on a fresh install of 6.9 amd64. I reported it as a > > bug last week to “bugs” mail list with all appropriate information. I can > > confirm that plugging in a monitor will allow my system to boot. I did not > > have the 001 patch installed. > > > > I have sent a metoo on this list, but there was no response. Here is the mail you were both sent: https://marc.info/?l=openbsd-bugs=162123695228236=2 If no one tries patches and no fix is found there can be no syspatch.
