Re: 50Gbe
Only bnxt and mcx support 50. Intel chips that do are 800 series, beyond ixl. On August 11, 2021 5:13:11 p.m. Chris Cappuccio wrote: ha...@sdf.org [ha...@sdf.org] wrote: > Hi folks! > > I wonder if OBSD supports 50Gbe network cards. And what is the cable > standard to support such data transfers ? > > Thanks. > > -- > The lion and the tiger may be more powerful, but the wolves do not perform > in the circus $ apropos 50gb bnxt(4) - Broadcom NetXtreme-C/E 10/25/40/50Gb Ethernet device https://man.openbsd.org/bnxt.4 mcx and ixl cards are the most likely 10/25/40/50/100 GbE chips to be well supported, bnxt doesn't even support per-CPU queues yet Sent with Aqua Mail for Android https://www.mobisystems.com/aqua-mail
Re: How to troubleshoot DHCP issues?
Thanks a lot Stuart! Really appreciate your insights. I've been running some more tests and here are some new results: 1. Without MAC spoofing and a statically assigned IP address, axe lasted around twelve days on an AX88772B before throwing the following error: axe0: watchdog timeout axe0: usb error on tx: IN PROGRESS axe0: usb error on tx: TIMEOUT This time tcpdump shows only incoming packets but not outgoing packets. (which is opposite from last time...) Have not yet tested axen and ure without MAC spoofing yet, but I highly suspect that there will be similar errors. I start to have a feeling that the problems are specific to Raspberry Pi 4B because these USB adapters seem really common and someone else would definitely have discovered the issue before me should amd64 be affected. 2. I tried changing MAC address to a fixed value on bse with `lladdr XX:XX:XX:XX:XX:XX`, and it has been running without issue for four days so far... But frankly I don't know how much randomness there are in those issues. > I'm still pondering the fact that you don't see incoming packets even > when tcpdump is running, as (unless you used tcpdump -p) that > would set the nic in promiscuous mode.. I believe I did `tcpdump -n -i `, sometimes with '-vvv'. Best Regards On 8/6/21 3:46 AM, Stuart Henderson wrote: hopefully copying to bugs@ (if I remember how to do that correctly from slrn/gmane..) Please keep that in CC's when replying. Earlier misc@ mail copied in below to keep things together in one place. On 2021-08-06, beebeet...@posteo.de wrote: My first suggestion might be to stay with a single lladdr for a while to see if your setup works for more than a day and a half. Thanks for the suggestion! It seems that with `lladdr random` removed, the problem does not seem to disappear. On 2021-08-06, beebeet...@posteo.de wrote: Sorry, there was a typo: The problem *does disappear* with `lladdr random` removed . Good, so you have a workaround for now. lladdr random Why this line? I was wondering the same thing. What problem do you think you are solving by doing this? I try to make it harder for my ISP to gather information about the device I'm using, thus was using random MAC address. The "random" lladdr catches my eye. But I don't know how frequently that changes. Could it change every time the lease is renewed? Skimming through the code for dhcpleased, looks like there's no invocation of the SIOCSIFLLADDR ioctl, so I would assume that the lladdr stays the same unless the netstart script is re-run (thus invoking ifconfig to change lladdr), but I will to test that to make sure. It smells of a bug somewhere... I mean, as long as the lladdr does not change in the middle of the lease, then the router should have been able to successfully obtain a new IP address, right? It only changes when "ifconfig $_iface lladdr random" is actually called, i.e. normally just when the interface is configured at boot, unless you re-run netstart. I don't think it will be a problem of using a random lladdr in particular but more likely if the MAC address is changed at all. One area that might be implicated is the hardware address filters which need to be reprogrammed by the driver when the address is changed. Though the fact that it happens with at least ure, bse, axe makes me think that it might be some other issue. I'm still pondering the fact that you don't see incoming packets even when tcpdump is running, as (unless you used tcpdump -p) that would set the nic in promiscuous mode.. On 2021-08-03, beebeet...@posteo.de wrote: Can anyone offer some suggestions on what I can do to nail down the issue? Below are some of the observations I've made so far: - Doesn't matter whether I'm using dhclient of dhcpleased, same issue. - When it stops working, tcpdump still shows outgoing packets, checksums all OK, but no incoming packets. - `dhcpleasectl show interface ` shows that there is still one day before the lease expires. - When this first happens, `arp -a` shows that the link layer address of the gateway is still in the ARP table. But of course it will expire after some time, and the router won't be able to obtain the link layer address of the gateway again after that. - The `netstat -R` still shows the IP address of the gateway. - My ISP would offer a few short leases at first, and then offer a two day lease. This issue seems always to occur around half way of the two day lease period. - I tried several interface cards with drivers including axen, ure, axe, bse. axen dies every 10-20 min, outputing some watchdog timeout error; ure has the same issue described here, but throws some rx/tx error to dmesg in addition; bse and axe doesn't seem to output any errors, but both have the issue described here. - The issue doesn't occur when the IP address is statically assigned. - Didn't experience this problem when I was running Linux on the
Re: libusb1 and Yoctopuce USB sensors
On 2021-08-11, Julian Smith wrote:
> On Mon, 9 Aug 2021 17:35:36 - (UTC)
> Stuart Henderson wrote:
>
>> On 2021-08-08, Julian Smith wrote:
>> > I've been trying to get a yoctopuce (https://www.yoctopuce.com/) USB
>> > sensor to work on OpenBSD, but have run into problems.
>> >
>> > The sensor has Linux code
>> > (https://github.com/yoctopuce/yoctolib_cpp.git) that uses libusb, but
>> > on OpenBSD using the libusb1 package, libusb_kernel_driver_active() and
>> > libusb_detach_kernel_driver() are returning error code -12
>> > (LIBUSB_ERROR_NOT_SUPPORTED).
>> >
>> > I found some rather old advice saying that these errors can be
>> > ignored (https://github.com/apple/cups/issues/4088), but then i get an
>> > error -12 from libusb_submit_transfer().
>>
>> There's no support for detaching a kernel USB driver from userland.
>>
>> If the device is attaching to a driver other than ugen, your first is to
>> prevent that and try again. Devices often attach to uhid(4) and libusb
>> functionality is very limited there. But that's an easy case to work around,
>> there's a UQ_BAD_HID quirk (see /usr/src/sys/dev/usb/usb_quirks.c),
>> you can add an entry using that to prevent the vid/pid of your device
>> from attaching and build a new kernel, it is then likely to end up on
>> ugen(4) and then has a better chance to do what you need.
>
> Many thanks for this, i've set up a separate machine for experimenting,
> and built a new kernel as suggested and it all seems to be working now.
>
> I'm still getting -12 from libusb_kernel_driver_active() and
> libusb_detach_kernel_driver() but then things seem to work ok so for
> example i'm seeing correct-looking CO2 measurements from the device.
>
> Here's the diff:
>
> cvs server: Diffing .
> Index: usb_quirks.c
>===
> RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
> retrieving revision 1.78
> diff -u -p -r1.78 usb_quirks.c
> --- usb_quirks.c24 Mar 2021 02:49:57 - 1.78
> +++ usb_quirks.c11 Aug 2021 22:43:20 -
> @@ -161,6 +161,9 @@ const struct usbd_quirk_entry {
> { USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_TYPECOVER2,
> ANY,{ UQ_ALWAYS_OPEN }},
>
> +/* Yoctopuce. */
> + { 0x24e0, 0x008b, ANY, { UQ_BAD_HID }},
> +
> { 0, 0, 0, { 0 } }
> };
>
> I tried adding Yoctopuce as vendor 0x24e0 and 0x008b as CO2V2 (it
> measures CO2 levels etc) to /usr/src/sys/dev/usb/usbdevs but rebuilding
> the kernel didn't seem to force regeneration of
> /usr/src/sys/dev/usb/usbdevs.h for some reason, hence the direct use of
> 0x24e0 and 0x008b in the above patch.
If you run "make" in sys/dev/usb it will generate usbdevs.h etc from
usbdevs, it's not automated.
> Is the device incorrect when it claims to be a Human Interface Device?
> If so i could maybe contact the manufacture.
No it's not incorrect. OpenBSD only gives partial access to usb devices
attached to uhid via libusb (and IIRC none at all for devices attached to
drivers other than ugen or uhid). Things can go badly if you've got a
kernel device driver and a userland "pseudo-driver" talking to the same
device. And since we don't have a way to detach a device from a driver
on-the-fly like other OS using libusb do, the only way is to knock out
the device from being attached to another kernel driver (either UQ_BAD_HID
for HID class devices, or disabling the driver in the kernel, or modifying
the probe function to skip it).
>> > I notice that 'pkg_info -R libusb1' shows just 9 ports depend on
>> > libusb1, so i'm wondering whether the libusb1 port is expected to work
>> > generally on OpenBSD, or whether it be better to try to use the usb(4)
>> > ioctl API?
>>
>> Many more use it via libusb-compat. Support is limited though and there's
>> some resistance to doing anything to help userland control of USB devices
>> so if it still doesn't work I'd suggest controlling it from another OS
>> unless you fancy writing a kernel driver.
>>
>
> Interesting, do you know of somewhere i can read some more about why
> userland control of USB is not recommended? Now i've managed to get this
There are some very different opinions on this. Some people think it's
better if these are handled by kernel drivers; others think that running
some of this code in the kernel is likely to be risky and maybe userland
is a better idea in cases where there aren't more stringent timing
requirements or high data rates. Anyway it seems unlikely to change.
> simple USB device working, i'm vaguely wondering about looking at
> making a USB terrestrial TV receiver work with Kaffeine on OpenBSD. I
> was hoping that doing this in user space might be easier than writing a
> kernel driver, though i guess the data rate might be too high?
That's an example of something that very likely does want to be
in kernel, partly data rates, partly it would want to interface with
the video(4) subsystem (which provides a reasonably V4L2-compatible
API to userland), partly b
Re: libusb1 and Yoctopuce USB sensors
On Mon, 9 Aug 2021 17:35:36 - (UTC)
Stuart Henderson wrote:
> On 2021-08-08, Julian Smith wrote:
> > I've been trying to get a yoctopuce (https://www.yoctopuce.com/) USB
> > sensor to work on OpenBSD, but have run into problems.
> >
> > The sensor has Linux code
> > (https://github.com/yoctopuce/yoctolib_cpp.git) that uses libusb, but
> > on OpenBSD using the libusb1 package, libusb_kernel_driver_active() and
> > libusb_detach_kernel_driver() are returning error code -12
> > (LIBUSB_ERROR_NOT_SUPPORTED).
> >
> > I found some rather old advice saying that these errors can be
> > ignored (https://github.com/apple/cups/issues/4088), but then i get an
> > error -12 from libusb_submit_transfer().
>
> There's no support for detaching a kernel USB driver from userland.
>
> If the device is attaching to a driver other than ugen, your first is to
> prevent that and try again. Devices often attach to uhid(4) and libusb
> functionality is very limited there. But that's an easy case to work around,
> there's a UQ_BAD_HID quirk (see /usr/src/sys/dev/usb/usb_quirks.c),
> you can add an entry using that to prevent the vid/pid of your device
> from attaching and build a new kernel, it is then likely to end up on
> ugen(4) and then has a better chance to do what you need.
Many thanks for this, i've set up a separate machine for experimenting,
and built a new kernel as suggested and it all seems to be working now.
I'm still getting -12 from libusb_kernel_driver_active() and
libusb_detach_kernel_driver() but then things seem to work ok so for
example i'm seeing correct-looking CO2 measurements from the device.
Here's the diff:
cvs server: Diffing .
Index: usb_quirks.c
===
RCS file: /cvs/src/sys/dev/usb/usb_quirks.c,v
retrieving revision 1.78
diff -u -p -r1.78 usb_quirks.c
--- usb_quirks.c24 Mar 2021 02:49:57 - 1.78
+++ usb_quirks.c11 Aug 2021 22:43:20 -
@@ -161,6 +161,9 @@ const struct usbd_quirk_entry {
{ USB_VENDOR_MICROSOFT, USB_PRODUCT_MICROSOFT_TYPECOVER2,
ANY,{ UQ_ALWAYS_OPEN }},
+/* Yoctopuce. */
+ { 0x24e0, 0x008b, ANY, { UQ_BAD_HID }},
+
{ 0, 0, 0, { 0 } }
};
I tried adding Yoctopuce as vendor 0x24e0 and 0x008b as CO2V2 (it
measures CO2 levels etc) to /usr/src/sys/dev/usb/usbdevs but rebuilding
the kernel didn't seem to force regeneration of
/usr/src/sys/dev/usb/usbdevs.h for some reason, hence the direct use of
0x24e0 and 0x008b in the above patch.
Is the device incorrect when it claims to be a Human Interface Device?
If so i could maybe contact the manufacture.
>
> > I notice that 'pkg_info -R libusb1' shows just 9 ports depend on
> > libusb1, so i'm wondering whether the libusb1 port is expected to work
> > generally on OpenBSD, or whether it be better to try to use the usb(4)
> > ioctl API?
>
> Many more use it via libusb-compat. Support is limited though and there's
> some resistance to doing anything to help userland control of USB devices
> so if it still doesn't work I'd suggest controlling it from another OS
> unless you fancy writing a kernel driver.
>
Interesting, do you know of somewhere i can read some more about why
userland control of USB is not recommended? Now i've managed to get this
simple USB device working, i'm vaguely wondering about looking at
making a USB terrestrial TV receiver work with Kaffeine on OpenBSD. I
was hoping that doing this in user space might be easier than writing a
kernel driver, though i guess the data rate might be too high?
Thanks,
- Jules
--
http://op59.net
Re: 50Gbe
Brad Smith [b...@comstyle.com] wrote: > Only bnxt and mcx support 50. Intel chips that do are 800 series, beyond ixl. > Oh and bnxt does support multiple queues I was wrong in that last email.
X hang after Mesa update
Hi, Since the recent Mesa update to 21.1.5 I have been experiencing a partial hang in X. It is triggered mostly while browsing in qutebrowser (which is the most graphically intensive program on my desktop). When this happens, the display freezes but the cursor can be moved and it even changes shape depending on what is actually on the screen. The system remains responsive and I can tell the GUI is responding to clicks and keyboard shortcuts, but the display does not update. I can start or quit programs blind, and also switch to text mode and back. In order to recover, even quitting my WM (FVWM2) does not work, although I can see by moving the cursor and observing its shape changing that the xenodm login screen is being displayed. Login will work blindly. All this time the display is frozen, displaying the screen contents from the time the problem was triggered. If I restart xenodm, which fully restarts X, then everything starts working again. My system is using the /usr/X11R6/lib/modules/dri/iris_dri.so library. I read some material on the web which seem to suggest that Mesa using this (new) library can cause issues on Linux, and in some cases switching to the older i965_dri.so can work around some of these bugs. So as a test I am using the line: export MESA_LOADER_DRIVER_OVERRIDE=i965 in my .xsession. The directive works and programs are now using the i965 library. I can't be 100% sure, but so far after intensive testing I have not been able to reproduce the issue. Further information about my system: kern.version=OpenBSD 6.9-current (GENERIC.MP) #164: Wed Aug 4 11:25:07 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP dmesg: OpenBSD 6.9-current (GENERIC.MP) #164: Wed Aug 4 11:25:07 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34201006080 (32616MB) avail mem = 33148534784 (31612MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xe (94 entries) bios0: vendor Dell Inc. version "1.5.6" date 12/07/2016 bios0: Dell Inc. OptiPlex 7040 acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT SSDT UEFI LPIT SSDT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT MSDM SLIC DMAR TPM2 ASF! BGRT acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) PS2K(S3) PS2M(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) PXSX(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3393.07 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, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz, 3392.10 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-6700 CPU @ 3.40GHz, 3392.10 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-6700 CPU @ 3.40GH
Re: 50Gbe
ha...@sdf.org [ha...@sdf.org] wrote: > > Hi folks! > > > > I wonder if OBSD supports 50Gbe network cards. And what is the cable > > standard to support such data transfers ? > > > > Thanks. > > > > -- > > The lion and the tiger may be more powerful, but the wolves do not perform > > in the circus > > $ apropos 50gb > bnxt(4) - Broadcom NetXtreme-C/E 10/25/40/50Gb Ethernet device > > https://man.openbsd.org/bnxt.4 mcx and ixl cards are the most likely 10/25/40/50/100 GbE chips to be well supported, bnxt doesn't even support per-CPU queues yet
Re: Transferring ownership of SSH connection from process A to B, letting A quit nicely?
On Wednesday, August 11th, 2021 at 7:57 AM, m brandenberg wrote: > Check msg.msg_flags here. I think you will receive a hint. msg_flags is always zero. Seems okay, after all, the FDs are received correctly.
Re: Transferring ownership of SSH connection from process A to B, letting A quit nicely?
On Tue, Aug 10, 2021 at 12:13 PM mid wrote: > On Monday, August 9th, 2021 at 5:36 AM, Philip Guenther < > guent...@gmail.com> wrote: > > > If you're 100% sure you have it right, then it should be easy to provide > a > > program that demonstrates > > 1. passing an fd between processes > > 2. using it successfully in the receiving process > > 3. the sending process exiting > > 4. attempts to us it failing the receiving process > > Not 100%, but I'm out of ideas, so here goes nothing. > > client.c (process A): > ... > Compiled with: > cc -std=c99 -o server server.c > cc -std=c99 -o client client.c > > `client` is also the shell of the user, but the results are the same if > I call it from within a "real" shell, too. > > The server receives the correct FDs, and prints > "Hello from the Server\n" correctly, too. But as soon as `client` > exits, the SSH connection goes with it, instead of staying (as in, > I get "Connection to localhost closed"). > Your problems have nothing to do with fd passing but rather are around not understanding how session management works. The client is passing its stdin/stdout, which are either pipes or a pseudo-tty connected to the ssh server and NOT the actual TCP socket carrying the ssh connection. When the session leader process exits the kernel will perform various cleanup operations (block tty access, send some signals). If you _really_ want to hack around in this area, you need to do a bunch of reading and research. I recommend buying/borrowing a copy of _Advanced_Programming_in_the_UNIX_Environment_ by W. Richard Stevens. Philip Guenther
Re: (bug?) relayd forward to directives interfering
On 2021-08-11, Vladimir Nikishkin wrote: > I do not think my setup is related to "TLS Inspection". > > There is no problem connecting to the TLS-enabled backend. The problem > appears when connecting to the HTTP backend, when, _at the same time_, > in the same relay there is another redirect to the TLS backend. > > On Wed, 11 Aug 2021 at 16:15, Jean-Pierre de Villiers > wrote: >> >> On 21/08/11 02:40pm, Vladimir Nikishkin wrote: >> > However, if I keep "with tls", the requests to port 81 are going >> > encrypted, and are failing with the following message in relayd logs: >> > `SSL routines:ST_CONNECT:tlsv1 alert protocol version`, >> > `TLS handshake error: handshake failed:`. >> >> What you're currently attemting is referred to as TLS inspection in >> relayd.conf(5). This is when one combines client and server modes. >> >> In order for TLS inspection to function properly the protocol options >> "ca cert" and "ca key" both need to be set. Further details found in >> the "TLS Relays" and "Protocols" sections of relayd.conf(5). >> >> Regards, >> JP > > > I don't think you can mix separate http and https backends like that in the same relay. You probably need a more flexible reverse proxy (haproxy, nginx, apache httpd, varnish, etc) to split up the requests how you're trying to do them. -- Please keep replies on the mailing list.
Re: (bug?) relayd forward to directives interfering
On 21/08/11 04:34pm, Vladimir Nikishkin wrote: > I do not think my setup is related to "TLS Inspection". Apologies, my misunderstanding. I always forget I divert traffic to to localhost in my setup. Anyway, > There is no problem connecting to the TLS-enabled backend. The problem > appears when connecting to the HTTP backend, when, _at the same time_, > in the same relay there is another redirect to the TLS backend. Did you make sure to use the https scheme in your curl request? Something like: $ curl https://domain.example/http The listener is still a TLS listener even if the backend uses only plain http. Sorry for the confusion. Regards, JP
Re: (bug?) relayd forward to directives interfering
I do not think my setup is related to "TLS Inspection". There is no problem connecting to the TLS-enabled backend. The problem appears when connecting to the HTTP backend, when, _at the same time_, in the same relay there is another redirect to the TLS backend. On Wed, 11 Aug 2021 at 16:15, Jean-Pierre de Villiers wrote: > > On 21/08/11 02:40pm, Vladimir Nikishkin wrote: > > However, if I keep "with tls", the requests to port 81 are going > > encrypted, and are failing with the following message in relayd logs: > > `SSL routines:ST_CONNECT:tlsv1 alert protocol version`, > > `TLS handshake error: handshake failed:`. > > What you're currently attemting is referred to as TLS inspection in > relayd.conf(5). This is when one combines client and server modes. > > In order for TLS inspection to function properly the protocol options > "ca cert" and "ca key" both need to be set. Further details found in > the "TLS Relays" and "Protocols" sections of relayd.conf(5). > > Regards, > JP -- Yours sincerely, Vladimir Nikishkin (Sent from GMail web interface.)
Re: (bug?) relayd forward to directives interfering
On 21/08/11 02:40pm, Vladimir Nikishkin wrote: > However, if I keep "with tls", the requests to port 81 are going > encrypted, and are failing with the following message in relayd logs: > `SSL routines:ST_CONNECT:tlsv1 alert protocol version`, > `TLS handshake error: handshake failed:`. What you're currently attemting is referred to as TLS inspection in relayd.conf(5). This is when one combines client and server modes. In order for TLS inspection to function properly the protocol options "ca cert" and "ca key" both need to be set. Further details found in the "TLS Relays" and "Protocols" sections of relayd.conf(5). Regards, JP
Re: Transferring ownership of SSH connection from process A to B, letting A quit nicely?
On Tue, 10 Aug 2021, mid wrote:
len = recvmsg(socket, &msg, 0);
if(len <= 0) {
return -1;
}
Check msg.msg_flags here. I think you will receive a hint.
--
Monty Brandenberg
