Re: vxlan(4) cannot set custom port
Ignore this report. My tree was out of sync. > On Feb 28, 2022, at 8:59 AM, Brian Brombacher wrote: >
vxlan(4) cannot set custom port
Good morning, The between 2/5 and 2/27 snapshots, some changes were introduced for vxlan. I am unable to use a custom port by specifying the port on the end of the destination tunnel. ifconfig vxlan0 tunnel 1.2.3.4 5.6.7.8:12345 The packets originating from my host are addressed to port 4789, the default. Cheers, Brian
Re: [PATCH] relayd client certificate validation again
Hi, sorry for being a moron.
I realize it’s already optional by not specifying client ca… sorry about the
noise!
> On Dec 16, 2021, at 9:35 PM, Brian Brombacher wrote:
>
> Hi, not to interrupt development …
>
> Can you make this completely optional from the servers perspective? I don’t
> want my endpoints validating anonymous client certificates when I run a
> public endpoint.
>
> I’ll just hack it out otherwise, but I think this opens a vector that should
> be completely optional from a relay service.
>
>
>> On Dec 16, 2021, at 4:25 PM, rivo nurges wrote:
>>
>> Hi!
>>
>> Here comes the support for relayd client certificate validation.
>> Full certificate chain, subject and issuer can be passed over in http
>> headers.
>> It supports mandatory validation and optional validation(if client chooses to
>> provide certificate it will be validated).
>>
>> Part of my sample config.
>>
>> http protocol test {
>> match header set "CS_SUBJECT" value "$CLIENT_CERT_SUBJECT"
>> match header set "CS_ISSUER" value "$CLIENT_CERT_ISSUER"
>> match header set "CS_CERT" value "$CLIENT_CERT_CHAIN"
>> pass
>> tls {client ca "/tmp/easyrsa3/pki/ca.crt" optional }
>> }
>>
>> This uses code from the patches submitted by Ashe Connor.
>>
>> Rivo
>>
>> diff refs/heads/master refs/heads/relay-clc3
>> blob - a2f1c130d6b45e3082048218c11537dca485998a
>> blob + 5070a7d48f58403f53d818231e1676db749aa9d7
>> --- usr.sbin/relayd/config.c
>> +++ usr.sbin/relayd/config.c
>> @@ -954,6 +954,15 @@ config_setrelay(struct relayd *env, struct relay *rlay
>> rlay->rl_conf.name);
>> return (-1);
>> }
>> +if (rlay->rl_tls_client_ca_fd != -1 &&
>> +config_setrelayfd(ps, id, n, 0,
>> +rlay->rl_conf.id, RELAY_FD_CLIENTCACERT,
>> +rlay->rl_tls_client_ca_fd) == -1) {
>> +log_warn("%s: fd passing failed for "
>> +"`%s'", __func__,
>> +rlay->rl_conf.name);
>> +return (-1);
>> +}
>> /* Prevent fd exhaustion in the parent. */
>> if (proc_flush_imsg(ps, id, n) == -1) {
>> log_warn("%s: failed to flush "
>> @@ -987,6 +996,10 @@ config_setrelay(struct relayd *env, struct relay *rlay
>> close(rlay->rl_s);
>> rlay->rl_s = -1;
>> }
>> +if (rlay->rl_tls_client_ca_fd != -1) {
>> +close(rlay->rl_tls_client_ca_fd);
>> +rlay->rl_tls_client_ca_fd = -1;
>> +}
>> if (rlay->rl_tls_cacert_fd != -1) {
>> close(rlay->rl_tls_cacert_fd);
>> rlay->rl_tls_cacert_fd = -1;
>> @@ -1012,6 +1025,10 @@ config_setrelay(struct relayd *env, struct relay *rlay
>> cert->cert_ocsp_fd = -1;
>> }
>> }
>> +if (rlay->rl_tls_client_ca_fd != -1) {
>> +close(rlay->rl_tls_client_ca_fd);
>> +rlay->rl_tls_client_ca_fd = -1;
>> +}
>> return (0);
>> }
>> @@ -1034,6 +1051,7 @@ config_getrelay(struct relayd *env, struct imsg *imsg)
>> rlay->rl_s = imsg->fd;
>> rlay->rl_tls_ca_fd = -1;
>> rlay->rl_tls_cacert_fd = -1;
>> +rlay->rl_tls_client_ca_fd = -1;
>> if (ps->ps_what[privsep_process] & CONFIG_PROTOS) {
>> if (rlay->rl_conf.proto == EMPTY_ID)
>> @@ -1163,6 +1181,9 @@ config_getrelayfd(struct relayd *env, struct imsg *ims
>> case RELAY_FD_CAFILE:
>> rlay->rl_tls_cacert_fd = imsg->fd;
>> break;
>> +case RELAY_FD_CLIENTCACERT:
>> +rlay->rl_tls_client_ca_fd = imsg->fd;
>> +break;
>> }
>> DPRINTF("%s: %s %d received relay fd %d type %d for relay %s", __func__,
>> blob - 22beb857229a16e5b2c17a25a2944231d41e7e08
>> blob + fe5e8ff4dfed10e8f09e3226bdfe33f8bc031c8e
>> --- usr.sbin/relayd/parse.y
>> +++ usr.sbin/relayd/parse.y
>> @@ -172,14 +172,14 @@ typedef struct {
>> %tokenCODE COOKIE DEMOTE DIGEST DISABLE ERROR EXPECT PASS BLOCK EXTERNAL
>> %tokenFILENAME FORWARD FROM HASH HEADER HEADERLEN HOST HTTP ICMP INCLUDE
>> INET
>> %tokenINET6 INTERFACE INTERVAL IP KEYPAIR LABEL LISTEN VALUE LOADBALANCE
>> LOG
>> -%tokenLOOKUP METHOD MODE NAT NO DESTINATION NODEL
Re: [PATCH] relayd client certificate validation again
Hi, not to interrupt development …
Can you make this completely optional from the servers perspective? I don’t
want my endpoints validating anonymous client certificates when I run a public
endpoint.
I’ll just hack it out otherwise, but I think this opens a vector that should be
completely optional from a relay service.
> On Dec 16, 2021, at 4:25 PM, rivo nurges wrote:
>
> Hi!
>
> Here comes the support for relayd client certificate validation.
> Full certificate chain, subject and issuer can be passed over in http headers.
> It supports mandatory validation and optional validation(if client chooses to
> provide certificate it will be validated).
>
> Part of my sample config.
>
> http protocol test {
> match header set "CS_SUBJECT" value "$CLIENT_CERT_SUBJECT"
> match header set "CS_ISSUER" value "$CLIENT_CERT_ISSUER"
> match header set "CS_CERT" value "$CLIENT_CERT_CHAIN"
> pass
> tls {client ca "/tmp/easyrsa3/pki/ca.crt" optional }
> }
>
> This uses code from the patches submitted by Ashe Connor.
>
> Rivo
>
> diff refs/heads/master refs/heads/relay-clc3
> blob - a2f1c130d6b45e3082048218c11537dca485998a
> blob + 5070a7d48f58403f53d818231e1676db749aa9d7
> --- usr.sbin/relayd/config.c
> +++ usr.sbin/relayd/config.c
> @@ -954,6 +954,15 @@ config_setrelay(struct relayd *env, struct relay *rlay
>rlay->rl_conf.name);
>return (-1);
>}
> +if (rlay->rl_tls_client_ca_fd != -1 &&
> +config_setrelayfd(ps, id, n, 0,
> +rlay->rl_conf.id, RELAY_FD_CLIENTCACERT,
> +rlay->rl_tls_client_ca_fd) == -1) {
> +log_warn("%s: fd passing failed for "
> +"`%s'", __func__,
> +rlay->rl_conf.name);
> +return (-1);
> +}
>/* Prevent fd exhaustion in the parent. */
>if (proc_flush_imsg(ps, id, n) == -1) {
>log_warn("%s: failed to flush "
> @@ -987,6 +996,10 @@ config_setrelay(struct relayd *env, struct relay *rlay
>close(rlay->rl_s);
>rlay->rl_s = -1;
>}
> +if (rlay->rl_tls_client_ca_fd != -1) {
> +close(rlay->rl_tls_client_ca_fd);
> +rlay->rl_tls_client_ca_fd = -1;
> +}
>if (rlay->rl_tls_cacert_fd != -1) {
>close(rlay->rl_tls_cacert_fd);
>rlay->rl_tls_cacert_fd = -1;
> @@ -1012,6 +1025,10 @@ config_setrelay(struct relayd *env, struct relay *rlay
>cert->cert_ocsp_fd = -1;
>}
>}
> +if (rlay->rl_tls_client_ca_fd != -1) {
> +close(rlay->rl_tls_client_ca_fd);
> +rlay->rl_tls_client_ca_fd = -1;
> +}
> return (0);
> }
> @@ -1034,6 +1051,7 @@ config_getrelay(struct relayd *env, struct imsg *imsg)
>rlay->rl_s = imsg->fd;
>rlay->rl_tls_ca_fd = -1;
>rlay->rl_tls_cacert_fd = -1;
> +rlay->rl_tls_client_ca_fd = -1;
> if (ps->ps_what[privsep_process] & CONFIG_PROTOS) {
>if (rlay->rl_conf.proto == EMPTY_ID)
> @@ -1163,6 +1181,9 @@ config_getrelayfd(struct relayd *env, struct imsg *ims
>case RELAY_FD_CAFILE:
>rlay->rl_tls_cacert_fd = imsg->fd;
>break;
> +case RELAY_FD_CLIENTCACERT:
> +rlay->rl_tls_client_ca_fd = imsg->fd;
> +break;
>}
> DPRINTF("%s: %s %d received relay fd %d type %d for relay %s", __func__,
> blob - 22beb857229a16e5b2c17a25a2944231d41e7e08
> blob + fe5e8ff4dfed10e8f09e3226bdfe33f8bc031c8e
> --- usr.sbin/relayd/parse.y
> +++ usr.sbin/relayd/parse.y
> @@ -172,14 +172,14 @@ typedef struct {
> %tokenCODE COOKIE DEMOTE DIGEST DISABLE ERROR EXPECT PASS BLOCK EXTERNAL
> %tokenFILENAME FORWARD FROM HASH HEADER HEADERLEN HOST HTTP ICMP INCLUDE
> INET
> %tokenINET6 INTERFACE INTERVAL IP KEYPAIR LABEL LISTEN VALUE LOADBALANCE
> LOG
> -%tokenLOOKUP METHOD MODE NAT NO DESTINATION NODELAY NOTHING ON PARENT
> PATH
> +%tokenLOOKUP METHOD MODE NAT NO DESTINATION NODELAY NOTHING ON OPTIONAL
> PARENT PATH
> %tokenPFTAG PORT PREFORK PRIORITY PROTO QUERYSTR REAL REDIRECT RELAY
> REMOVE
> %tokenREQUEST RESPONSE RETRY QUICK RETURN ROUNDROBIN ROUTE SACK SCRIPT
> SEND
> %tokenSESSION SOCKET SPLICE SSL STICKYADDR STRIP STYLE TABLE TAG TAGGED
> TCP
> %tokenTIMEOUT TLS TO ROUTER RTLABEL TRANSPARENT URL WITH TTL RTABLE
> %tokenMATCH PARAMS RANDOM LEASTSTATES SRCHASH KEY CERTIFICATE PASSWORD
> ECDHE
> %tokenEDH TICKETS CONNECTION CONNECTIONS CONTEXT ERRORS STATE CHANGES
> CHECKS
> -%tokenWEBSOCKETS
> +%tokenWEBSOCKETS CLIENT
> %tokenSTRING
> %token NUMBER
> %typecontext hostname interface table value path
> @@ -188,6 +188,7 @@ typedef struct {
> %typeopttls opttlsclient
> %typeredirect_proto relay_proto match
> %typeaction ruleaf key_option
> +%typeclientcaopt
> %typeport
> %typehost
> %typeaddress rulesrc ruledst addrprefix
> @@
Re: hostctl does not work on Xen
I can see from the Ubuntu dmesg that it’s Xen 4.11.4. What mode are you running the OpenBSD vm in (PVH or HVM)? Provide your config file for the vm to help answer that. > On Oct 8, 2021, at 12:41 AM, Masato Asou wrote: > > Attached obsd69-dmesg.txt and ubuntu-dmesg.txt. > > regards. > -- > ASOU Masato > > From: Brian Brombacher > Date: Thu, 7 Oct 2021 23:21:59 -0400 > >>>> On Oct 7, 2021, at 9:46 PM, Masato Asou wrote: >>> >>> How can I use the hostctl command on Xen virtual machine? >>> >>> The hostctl command doesn't work on my Ubuntu (bear metal PC) + Xen + >>> OpenBSD 6.9 release as follows: >>> $ hostctl device >>> hostctl: open: /dev/pvbus0: Operation not supported by device >>> $ doas hostctl device >>> doas (a...@obsd69.my.domain) password: >>> hostctl: open: /dev/pvbus0: Operation not supported by device >>> $ ls -l /dev/pvbus0 >>> crw-r- 1 root wheel 95, 0 Oct 7 04:21 /dev/pvbus0 >>> $ >>> >>> Could not found pvbus as follows: >>> $ dmesg | grep pvbus >>> $ >>> >>> >>> On the other hand, hostctl command works correctly for OpenBSD 6.9 >>> release on ESXi and Hyper-V. >>> >>> On ESXi as follows: >>> $ hostctl guestinfo.ip >>> 192.168.10.113 >>> $ dmesg | egrep '(pvbus|vmt)' >>> pvbus0 at mainbus0: VMware >>> vmt0 at pvbus0 >>> $ >>> >>> On Hyper-V as follows: >>> $ hostctl GUest/Parameters/HostName >>> DESKTOP-4AL1JIR >>> $ dmesg | egrep '(pvbus|hyperv)' >>> pvbus0 at mainbus0: Hyper-V 10.0 >>> hyperv0 at pvbus0: protocol 4.0, features 0x2e7f >>> hyperv0: heartbeat, kvp, shutdown, timesync >>> hvs0 at hyperv0 channel 2: ide, protocol 6.2 >>> hvs1 at hyperv0 channel 15: scsi, protocol 6.2 >>> hvn0 at hyperv0 channel 14: NVS 5.0 NDIS 6.30, address >>> 00:15:5d:0a:80:00 >>> $ >>> -- >>> ASOU Masato >>> >> >> Provide a dmesg >> > > 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 = 4278026240 (4079MB) > avail mem = 4132995072 (3941MB) > random: good seed from bootblocks > mpath0 at root > scsibus0 at mpath0: 256 targets > mainbus0 at root > bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xbd80 (13 entries) > bios0: vendor SeaBIOS version "1.13.0-1ubuntu1.1" date 04/01/2014 > bios0: QEMU Standard PC (i440FX + PIIX, 1996) > acpi0 at bios0: ACPI 1.0 > acpi0: sleep states S5 > acpi0: tables DSDT FACP APIC > acpi0: wakeup devices > acpitimer0 at acpi0: 3579545 Hz, 24 bits > acpimadt0 at acpi0 addr 0xfee0: PC-AT compat > cpu0 at mainbus0: apid 0 (boot processor) > cpu0: AMD EPYC Processor, 3194.29 MHz, 17-01-02 > cpu0: > FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,RDRAND,HV,NXE,MMXX,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,SVM,AMCR8,ABM,SSE4A,FSGSBASE,BMI1,SMEP,BMI2,ERMS,MPX,ADX,SMAP,PCOMMIT,CLFLUSHOPT,CLWB,PKU,XSAVEOPT,XGETBV1 > cpu0: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu0: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu0: smt 0, core 0, package 0 > mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges > cpu0: apic clock running at 999MHz > cpu0: mwait min=0, max=0, IBE (bogus) > cpu1 at mainbus0: apid 1 (application processor) > cpu1: AMD EPYC Processor, 3194.40 MHz, 17-01-02 > cpu1: > FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,RDRAND,HV,NXE,MMXX,PAGE1GB,RDTSCP,LONG,3DNOW2,3DNOW,LAHF,SVM,AMCR8,ABM,SSE4A,FSGSBASE,BMI1,SMEP,BMI2,ERMS,MPX,ADX,SMAP,PCOMMIT,CLFLUSHOPT,CLWB,PKU,XSAVEOPT,XGETBV1 > cpu1: 64KB 64b/line 4-way I-cache, 32KB 64b/line 8-way D-cache, 512KB > 64b/line 8-way L2 cache > cpu1: ITLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu1: DTLB 255 4KB entries direct-mapped, 255 4MB entries direct-mapped > cpu1: disabling user TSC (skew=-23997) > cpu1: smt 0, core 0, package 1 > cpu2 at mainbus0: apid 2 (application processor) > cpu2: AMD EPYC Processor, 3192.81 MHz, 17-01-02 > cpu2: > FPU,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,
Re: hostctl does not work on Xen
> On Oct 7, 2021, at 9:46 PM, Masato Asou wrote: > > How can I use the hostctl command on Xen virtual machine? > > The hostctl command doesn't work on my Ubuntu (bear metal PC) + Xen + > OpenBSD 6.9 release as follows: > $ hostctl device > hostctl: open: /dev/pvbus0: Operation not supported by device > $ doas hostctl device > doas (a...@obsd69.my.domain) password: > hostctl: open: /dev/pvbus0: Operation not supported by device > $ ls -l /dev/pvbus0 > crw-r- 1 root wheel 95, 0 Oct 7 04:21 /dev/pvbus0 > $ > > Could not found pvbus as follows: > $ dmesg | grep pvbus > $ > > > On the other hand, hostctl command works correctly for OpenBSD 6.9 > release on ESXi and Hyper-V. > > On ESXi as follows: > $ hostctl guestinfo.ip > 192.168.10.113 > $ dmesg | egrep '(pvbus|vmt)' > pvbus0 at mainbus0: VMware > vmt0 at pvbus0 > $ > > On Hyper-V as follows: > $ hostctl GUest/Parameters/HostName > DESKTOP-4AL1JIR > $ dmesg | egrep '(pvbus|hyperv)' > pvbus0 at mainbus0: Hyper-V 10.0 > hyperv0 at pvbus0: protocol 4.0, features 0x2e7f > hyperv0: heartbeat, kvp, shutdown, timesync > hvs0 at hyperv0 channel 2: ide, protocol 6.2 > hvs1 at hyperv0 channel 15: scsi, protocol 6.2 > hvn0 at hyperv0 channel 14: NVS 5.0 NDIS 6.30, address > 00:15:5d:0a:80:00 > $ > -- > ASOU Masato > Provide a dmesg
Re: Unwind + NSD usage question
> On Sep 27, 2021, at 8:52 PM, abyx...@mnetic.ch wrote:
>
> Hello, trying to set up unwind with nsd on the same machine serving a
> internal domain (home.arpa) with all my machines being part of that domain,
> eg router.home.arpa. If I point dig at my nsd instance (dig @127.0.0.1 -p
> 10053 router.home.arpa. A) I see my subdomains in the zone all being returned
> (router.home.arpa. -> 10.0.0.1). If I set nsd as a forwarder in unwind.conf
> (forwarder 127.0.0.1 port 10053) though, things get weird. My ISP doesn't
> return any results for home.arpa but some other servers (quad9 and
> cloudfare?) return a blackhole address pointing to prisoner.iana.org. If I
> limit unwind to preference {forwarder recursor} I now get my local nsd
> results for my domains as expected. If I comment out the preference line,
> unwind eventually learns a server that will answer to home.arpa with the
> blackhole prisoner.iana.org address (at least a minute in, sometimes longer,
> makes testing difficult). The use of force forwarder {home.arpa} and force
> accept bogus forwarder {home.arpa} don't appear to have any effect at all.
> (Full configs and dmesg below).
>
> I dug through the code a bit, if I'm following it correctly in
> sbin/unwind/resolver.c:check_resolver_done, nsd seems to be returning a
> SERVFAIL and being marked dead (as confirmed with unwindctl status. I am not
> sure I followed the code correctly at this point, but being set to DEAD
> and/or returning a SERVFAIL seems to preempt the use of force accept bogus. I
> am not sure what test unwind/libunbound are doing to check the health status
> of the different resolvers but I have yet to see my nsd forwarder not marked
> as "dead" in unwindctl status. Any ideas on how to debug this? This happens
> on both 6.9 and -current. The -current dmesg is posted below.
>
>
>
> ---
> router# cat /etc/unwind.conf
>
> forwarder {
>127.0.0.1 port 10053
> }
>
> force accept bogus forwarder { home.arpa }
> #force autoconf { home.arpa }
> preference { forwarder recursor }
Shouldn’t this be:
preference { recursor forwarder }
The force forwarder is good enough for home.arpa to “prefer” (force) the use of
the forwarder.
This way your recursor will find results via the internet while home.arpa will
go to NSD.
I have not tested this, and I use unbound as others have described to forward
local domains to my NSD.
> #preference { recursor DoT forwarder }
> ---
>
>
> ---
> router# cat /var/nsd/etc/nsd.conf
>
> # $OpenBSD: nsd.conf,v 1.13 2018/08/16 17:59:12 florian Exp $
>
> server:
>hide-version: yes
>verbosity: 1
>database: "" # disable database
>
> ## bind to a specific address/port
>ip-address: 127.0.0.1@10053
>
> ## make packets as small as possible, on by default
> # minimal-responses: yes
>
> ## respond with truncation for ANY queries over UDP and allow ANY over TCP,
> ## on by default
> # refuse-any: yes
>
> remote-control:
>control-enable: yes
>control-interface: /var/run/nsd.sock
>
> zone:
>name: "home.arpa."
>zonefile: "master/home.arpa"
> ---
>
>
> ---
> router# unwindctl status
>
> 1. recursorvalidating, 30ms 2. forwarder dead, 15ms
>
> histograms: lifetime[ms], decaying[ms]
> <10 <20 <40 <60 <80 <100 <200 <400 <600 <800 <1000 >
> rec 1634 1008 1014 619 292 339 973 667 15626 7 1
> 1614 8 6 1 3 6 5 0 0 0 0
> forw 223886 0 0 0 0 0 0 0 0 0 0
> 19 0 0 0 0 0 0 0 0 0 0 0
> ---
>
>
> ---
> router# dig @127.0.0.1 home.arpa. A
>
> ; <<>> dig 9.10.8-P1 <<>> @127.0.0.1 home.arpa. A
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41102
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;home.arpa. IN A
>
> ;; ANSWER SECTION:
> home.arpa. 413 IN A 10.0.0.1
>
> ;; Query time: 62 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Sep 27 20:46:38 EDT 2021
> ;; MSG SIZE rcvd: 43
> ---
>
>
> ---
> router# dig @9.9.9.9 home.arpa. A
>
> ; <<>> dig 9.10.8-P1 <<>> @9.9.9.9 home.arpa. A
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53702
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;home.arpa. IN A
>
> ;; AUTHORITY SECTION:
> home.arpa. 3600IN SOA
Re: RFC: kern.video.record
> On Sep 19, 2020, at 10:39 AM, Chris Bennett > wrote: > > On Sat, Sep 19, 2020 at 10:14:55AM +0100, Laurence Tratt wrote: >> >> I agree that it would simplify the code. The reason that I didn't merge them >> is because I know that sometimes people want to record audio but not video (I >> doubt that many people record video without audio). Now, admittedly, this >> isn't necessarily a super-common use case, so it might not be worth having >> two knobs for it, but it might be worth considering. Personally I'm >> completely comfortable with whatever the general consensus is for >> merging/not-merging! > > There are legal reasons for recording video only. Depends on local laws. > I forget the exact details, but Texas laws regarding informing others if > they are being recorded are more permissive than other states as far as > needing to inform. I've only been following this thread lightly, but it > seems relevant to at least throw that information in. > > Chris Bennett > > Admittedly, I have not used audio or video recording on OpenBSD; however, the minimal code duplication is avoidable in other ways. Having two switches to control two separate modalities, as you described, provides more flexibility with respect to truly preventing an application (poorly designed, malicious, etc) from “snooping” on your audio or video. Again, I’m not a user of the recording functionality, so this is me throwing my two cents out there. -Brian
Re: TCP congestion control progression
>> On Aug 9, 2020, at 6:29 PM, Chris Cappuccio wrote: > Brian Brombacher [br...@planetunix.net] wrote: >> >> I am wondering what approach the project is planning to use to modernize >> the congestion control algorithms. I'm interested in assisting the project >> with development effort in this area. I've spent time making modifications >> for my own purposes and would prefer to understand the projects goals before >> continuing, if possible. > > Various improvements have been made over the years for dynamic window size, > also further tweaks for higher bandwidth over high latency connections. I'd > recommend sharing your current modifications here to get feedback. > > Chris Hi Chris, The modifications I’ve made are around parameters related to the slow start threshold logic, ENOBUF behavior on interface write, and each Reno congestion control logic segment has also received some changes. The majority of the changes are implementing sysctl tunables to experiment with varying degrees of network behavior I’ve been witnessing on my infrastructure. I’ve been evaluating potential patterns to allow optimal maintenance and addition of future CC algorithms. Cheers, Brian
TCP congestion control progression
Hello, I've been spending some time hacking on the TCP stack, specifically congestion control. I've also spent time evaluating the NetBSD, FreeBSD, Darwin, and Linux TCP stacks to varying degrees. I am wondering what approach the project is planning to use to modernize the congestion control algorithms. I'm interested in assisting the project with development effort in this area. I've spent time making modifications for my own purposes and would prefer to understand the projects goals before continuing, if possible. Thanks, Brian
Re: softraid/bioctl cant find device /dev/bio
> On Aug 3, 2020, at 9:54 AM, sven falempin wrote: > > Hello > > I saw a similar issue in the mailing list around decembre 2019, > following an electrical problem softraid doesn't bring devices ups > > > # ls /dev/sd?? > /dev/sd0a /dev/sd0g /dev/sd0m /dev/sd1c /dev/sd1i /dev/sd1o /dev/sd2e > /dev/sd2k > /dev/sd0b /dev/sd0h /dev/sd0n /dev/sd1d /dev/sd1j /dev/sd1p /dev/sd2f > /dev/sd2l > /dev/sd0c /dev/sd0i /dev/sd0o /dev/sd1e /dev/sd1k /dev/sd2a /dev/sd2g > /dev/sd2m > /dev/sd0d /dev/sd0j /dev/sd0p /dev/sd1f /dev/sd1l /dev/sd2b /dev/sd2h > /dev/sd2n > /dev/sd0e /dev/sd0k /dev/sd1a /dev/sd1g /dev/sd1m /dev/sd2c /dev/sd2i > /dev/sd2o > /dev/sd0f /dev/sd0l /dev/sd1b /dev/sd1h /dev/sd1n /dev/sd2d /dev/sd2j > /dev/sd2p > # dmesg | grep 6.7 > OpenBSD 6.7 (RAMDISK_CD) #177: Thu May 7 11:19:02 MDT 2020 > # dmesg | grep sd >dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/RAMDISK_CD > wsdisplay1 at vga1 mux 1: console (80x25, vt100 emulation) > sd0 at scsibus1 targ 0 lun 0: > t10.ATA_QEMU_HARDDISK_Q > M5_ > sd0: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin > sd1 at scsibus1 targ 1 lun 0: > t10.ATA_QEMU_HARDDISK_Q > M7_ > sd1: 1907729MB, 512 bytes/sector, 3907029168 sectors, thin > wskbd0 at pckbd0: console keyboard, using wsdisplay1 > softraid0: trying to bring up sd2 degraded > softraid0: sd2 was not shutdown properly > softraid0: sd2 is offline, will not be brought online > # bioctl -d sd2 > bioctl: Can't locate sd2 device via /dev/bio > # > > I suspect a missing devices in /dev ( but it seems i have the required one ) > and MAKEDEV all of course did a `uid 0 on /: out of inodes` > > I have backups but i ' d like to fix the issue ! Hi Sven, The device sd2 wasn’t attached by softraid, your /dev/bio is fine. This can happen if softraid fails to find all component disks or the metadata on one or more components does not match expectations (newer metadata seen on other disks). Make sure all of the component disks are working. If that is not the issue, you may need to re-run the command that you used to create the array and include -C force. Be very careful doing this, I suggest running the command once without -C force to ensure it found all the components and fails to bring the array up due to the same error message you got (attempt to bring up degraded). If you’re not careful, you can blow out the whole array. -Brian > > -- > -- > - > Knowing is not enough; we must apply. Willing is not enough; we must do
Re: ftpd: ignore -l in LIST path
> On Jul 18, 2020, at 8:16 PM, Brian Brombacher wrote:
>
> Hello,
>
> Below is a patch that repairs ftpd LIST operation for at least Chrome browser.
> Discard the patch if the intention is to make clients change behavior. A bug
> report has already been filed with the browser. Edge browser works fine.
> Other browsers untested.
>
> Symptom in raw output in Chrome 83:
>
> ftpd: -l: No such file or directory
>
> Reproduce using Chrome 83:
>
> ftp:///?raw
>
> Cheers,
> Brian
>
>
> Index: popen.c
> ===
> RCS file: /home/brian/cvs/src/libexec/ftpd/popen.c,v
> retrieving revision 1.29
> diff -u -r1.29 popen.c
> --- popen.c15 Jan 2020 22:06:59 -1.29
> +++ popen.c18 Jul 2020 23:52:49 -
> @@ -76,7 +76,7 @@
>argv[argc++] = "--";
>
>/* glob that path */
> -if (path != NULL) {
> +if (path != NULL && strcmp(path, "-l") != 0) {
>glob_t gl;
>
>memset(, 0, sizeof(gl));
>
Update from Chromium team, looks like it’s a non-issue for this browser going
forward.
Updates:
Status: WontFix
Comment #4 on issue 1107143 by asa...@chromium.org: OpenBSD ftpd LIST
incompatible
https://bugs.chromium.org/p/chromium/issues/detail?id=1107143#c4
Thank you for the report. We are in the process of deprecating and removing FTP
support as described in https://www.chromestatus.com/features/6246151319715840 .
Cheers,
Brian
ftpd: ignore -l in LIST path
Hello,
Below is a patch that repairs ftpd LIST operation for at least Chrome browser.
Discard the patch if the intention is to make clients change behavior. A bug
report has already been filed with the browser. Edge browser works fine.
Other browsers untested.
Symptom in raw output in Chrome 83:
ftpd: -l: No such file or directory
Reproduce using Chrome 83:
ftp:///?raw
Cheers,
Brian
Index: popen.c
===
RCS file: /home/brian/cvs/src/libexec/ftpd/popen.c,v
retrieving revision 1.29
diff -u -r1.29 popen.c
--- popen.c 15 Jan 2020 22:06:59 - 1.29
+++ popen.c 18 Jul 2020 23:52:49 -
@@ -76,7 +76,7 @@
argv[argc++] = "--";
/* glob that path */
- if (path != NULL) {
+ if (path != NULL && strcmp(path, "-l") != 0) {
glob_t gl;
memset(, 0, sizeof(gl));
TCP congestion window pinned by integer arithmetic
Hi,
RFC 5681 Section 3.1 has an Implementation Note that covers the bug fixed by
the following patch. I ran into this bug testing on a high latency link. My
congestion window was pinned to a specific value and could not open further,
causing a lack of bandwidth utilization.
I chose if/assign rather than max(9) for clarity with the RFC; however, both
work fine.
Cheers,
Brian
Index: tcp_input.c
===
RCS file: /home/brian/cvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.364
diff -u -r1.364 tcp_input.c
--- tcp_input.c 6 Dec 2019 14:43:14 - 1.364
+++ tcp_input.c 1 Jun 2020 21:16:26 -
@@ -1707,8 +1707,11 @@
u_int cw = tp->snd_cwnd;
u_int incr = tp->t_maxseg;
- if (cw > tp->snd_ssthresh)
+ if (cw > tp->snd_ssthresh) {
incr = incr * incr / cw;
+ if (incr == 0)
+ incr = 1;
+ }
if (tp->t_dupacks < tcprexmtthresh)
tp->snd_cwnd = ulmin(cw + incr,
TCP_MAXWIN << tp->snd_scale);
