httpd - bypass tls misconfig different ciphers, ecdhe
I'm on -current, httpd throws tls misconfig error when different
cipher or ecdhe used but it's bypassed by listen statment.
server "domain.tld" {
listen on * tls port 443
log style combined
hsts
{
subdomains
}
root "/htdocs/domain.tld/"
tls {
certificate "/etc/ssl/domain.tld.fullchain.pem"
key "/etc/ssl/private/domain.tld.key"
ciphers "HIGH:!AES128:!kRSA:!aNULL"
ecdhe "P-384,P-256,X25519"
}
location "/pub/*" {
directory auto index
}
location "/.well-known/mta-sts.txt" {
root "/mta-sts"
request strip 1
pass
}
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
}
server "sub.domain.tld" {
# listen on port
# note: adding before tls
# listen on 0.0.0.0 port 8080
listen on * tls port 443
root "/htdocs/sub.domain.tld"
tls {
certificate "/etc/ssl/domain.tld.fullchain.pem"
key "/etc/ssl/private/domain.tld.key"
}
hsts {
max-age 15768000
preload
subdomains
}
connection max request body 104857600
location "/*" {
fastcgi {
param SCRIPT_FILENAME "/cgi-bin/scm"
param SCRIPT_NAME " "
}
}
location "/.well-known/acme-challenge/*" {
root "/acme"
request strip 2
}
}
$ doas httpd -nv
server "sub.domain.tld": tls configuration mismatch on same address/port
instead of defining same cipher and ecdhe, uncommenting
"listen on 0.0.0.0 port 8080"
bypasses this error
I'm unsure what causes this, can someone shed some light?
Re: httpd - bypass tls misconfig different ciphers, ecdhe
On Sat, August 15, 2020 7:13 pm, hisacro wrote:
> I'm on -current, httpd throws tls misconfig error when different
> cipher or ecdhe used but it's bypassed by listen statment.
>
> server "domain.tld" {
> listen on * tls port 443
> log style combined
> hsts
> {
> subdomains
> }
> root "/htdocs/domain.tld/"
> tls {
> certificate "/etc/ssl/domain.tld.fullchain.pem"
> key "/etc/ssl/private/domain.tld.key"
> ciphers "HIGH:!AES128:!kRSA:!aNULL"
> ecdhe "P-384,P-256,X25519"
> }
>
>
> server "sub.domain.tld" {
> # listen on port
> # note: adding before tls
> # listen on 0.0.0.0 port 8080
> listen on * tls port 443
> root "/htdocs/sub.domain.tld"
> tls {
> certificate "/etc/ssl/domain.tld.fullchain.pem"
> key "/etc/ssl/private/domain.tld.key"
> }
>
> $ doas httpd -nv
> server "sub.domain.tld": tls configuration mismatch on same address/port
>
> instead of defining same cipher and ecdhe, uncommenting
> "listen on 0.0.0.0 port 8080"
> bypasses this error
>
> I'm unsure what causes this, can someone shed some light?
>
It's what the error says. You're listening twice on the same ip and port
but with different tls blocks.
Re: USB speakers
Can you post your /etc/rc.conf.local ? -- Patrick Harper paia...@fastmail.com On Fri, 14 Aug 2020, at 17:21, Justin Muir wrote: > Wondering whether anyone has experience with Logitech USB speakers? > > Plugged in mine, did the rcctl rsnd/0 thingi from multimedia FAQ: > # rcctl set sndiod flags -f rsnd/0 -F rsnd/1 > # rcctl restart sndiod > > It doesn't work. As a matter of fact, the speaker light doesn't even come > on now. > > Any suggestions? > > > tia! > > J > > Dmesg output below: > > uaudio0 at uhub4 port 2 configuration 1 interface 1 "Logitech Logitech USB > Speaker" rev 1.10/0.07 addr 3 > uaudio0: class v1, full-speed, sync, channels: 2 play, 0 rec, 7 ctls > audio1 at uaudio0 > uhidev2 at uhub4 port 2 configuration 1 interface 2 "Logitech Logitech USB > Speaker" rev 1.10/0.07 addr 3 > uhidev2: iclass 3/0 > uhid3 at uhidev2: input=2, output=0, feature=0 >
question about IPsec
Hello there nice people. It's possible have in the same machine IKEv2 and IKEv1 running? How can I open IKEv2 socket only on an IP or an interface? Perhaps with different routing tables? Nice regards -- Name: Riccardo Giuntoli Email: tag...@gmail.com Location: sant Pere de Ribes, BCN, Spain PGP Key: 0x67123739 PGP Fingerprint: CE75 16B5 D855 842FAB54 FB5C DDC6 4640 6712 3739 Key server: hkp://wwwkeys.eu.pgp.net
Re: Recommendations for USB Barcode Scanner and Thermal Receipt Printer
For the record, I came into a chep USB barcode scanner that works wonders. An Inateck BCST-31 according to the label. I also ran into a cheap chinesse ticket printer, a Terow. Sadly, it crashes the kernel - looks like a bad kernel bug. It works well when it is not crashing. Stuart Henderson wrote: > On 2020-07-29, Rubén Llorente wrote: >> Thank you for the advice. I will search for those ones and see what I can >> find. >> >> I still need to solve the printer issue. So far it looks like receipt >> printers use very simple interfaces. Somebody engineered ppd files for Zjian >> printers for Linux, but I don't know if the OpenBSD kernel would interface >> with them. They are certainly not in the USB Product/Vendor database of the >> kernel. Maybe they would show as Unknown Printers? > > For standard device types, USB typically uses "class drivers", there are > specifications for e.g. mass storage, USB-attached SCSI, human interface > devices (mouse/keyboard/etc), etc, including printers. If the device > follows one of these it doesn't need a specific driver or information > about the particular device in the kernel (the kernel product/vendors > are used when the device doesn't use a class driver or needs some > special quirks, or as a fallback if the device doesn't report a > human-readable vendor/product name). > > Really unless you can find someone with a particular device you'll need > to take a gamble, or buy something that you can return if incompatible. > > ppd files can be used on OpenBSD. > > > -- OpenPGP Key Fingerprint: BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA
Re: smtpd returns 'TempFail' and 'No route to destination' when using localhost as source behind NAT
On Sat, Aug 15, 2020 at 07:49:28AM +, Martin wrote:
> It is worth to mention smtpd works absolutely fine for outgoing/incoming mail
> if local machine has static IP address when:
> ...
> table sources {1.2.3.4} equivalent to
> table helonames {1.2.3.4 = smtp.domain.tld}
> ...
>
> And yes, I have exactly the same action in /etc/mail/smtpd.conf
>
> ...
> table sources {127.0.0.1}
> table helonames {1.2.3.4 = smtp.domain.tld}
Your helonames table does not have an entry for 127.0.0.1, that is why it
cannot find helo string for it.
new
0 C Brazil P Ceará T FORTALEZA Z 60410442 O MDFSoftware I Oliveira Filho, D. A. A 355 Eduardo Girão, Jardim América M supo...@mdfsoftware.com.br U http://www.mdfsoftware.com.br/ B +55-85-9-89739017 X +55-85-9-96110010 N Commercial support for Unix/Linux. Full remote installation on demand. Security services, setup and integration. Experienced in OpenBSD, including Internet gateways, clustered firewalls, intrusion detection systems and VPNs.
Re: Problems with iwn wireless networking
On Sat, 15 Aug 2020 11:09:59 +0200 Stefan Sperling wrote: > On Sat, Aug 15, 2020 at 09:14:48AM +0100, Julian Smith wrote: > > I'm seeing fairly frequent (e.g. more than daily) failures from an > > iwn0 wireless network device, on a Lenovo X230. > > > > dmesg|grep iwn shows: > > > > iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev > > 0x34: msi, MIMO 2T2R, MoW, address a4:4e:31:43:f1:60 iwn0: fatal > > firmware error iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: device timeout > > iwn0: device timeout > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > iwn0: device timeout > > iwn0: fatal firmware error > > iwn0: fatal firmware error > > > > Uptime is 6 days, so this is several failures per day on average. > > > > iwn(4) DIAGNOSTICS says that these two types of error 'should not > > happen'. > > > > Is here anything i can do about this? The machine is a Lenovo X230. > > > > Or is there alternative wireless hardware that i install instead > > that is known to be reliable? > > > > Full dmesg is below. My kernel has a patch from visa@ to reduce gdb > > uninterruptible wait problem (see 'gdb in uninterruptible wait' > > thread on misc), but is otherwise vanilla 6.7. > > Could you try -current to see if the issue is still present there? Ok i'll try building a current kernel in the next few days. (Do you know of any changes that could affect iwn?) > > On 6.7, does forcing 11a or 11g mode work around this? For example: > ifconfig iwn0 mode 11g 'mode 11g' doesn't appear to make any difference. 'mode 11a' results in no connection at all. Thanks, - Jules -- http://op59.net
Re: Confused by adjfreq(2)
On Sat, Aug 15, 2020 at 09:10:26AM +0100, Julian Smith wrote: > On Mon, 10 Aug 2020 09:53:10 +0200 > Otto Moerbeek wrote: > > > On Sun, Aug 09, 2020 at 09:46:00PM +0100, Julian Smith wrote: > > > > > I've just used adjfreq() directly to correct my hardware clock, > > > which was running an hour ahead of UTC (due to my hardware > > > previously running Windows). > > > > > > But i've struggled to understand the adjfreq(2) man page, so ended > > > up finding a value for by trial and error. > > > > > > I ended up with this code: > > > > > > double x = 1.5; > > > int64_t newfreq = ((1ll << 32) * 1e9) * x; > > > adjfreq(newfreq, NULL); > > > > This does not look like actual code, first arg should be a pointer. > > Ah yes, apologies for this, i foolishly hand-wrote the code above in > the post. The actual code i used did pass a pointer: > > e = adjfreq(, ); > > > > > > > > > In this table, the second column is the increment in the time as > > > shown by running date(1) twice, over a 10 second period as measured > > > using my phone as a timer, for different values of x: > > > > > > x 10s > > > - > > > 0 10 > > > 0.112 > > > 0.25 13 > > > 0.515 > > > 0.75 17 > > > 0.819 > > > 0.919 > > > 1.021 > > > 1.1 1 > > > 1.25: 3 > > > 1.5:6 > > > 1.75: 8 > > > 2: 10 > > > 2.25: 10 > > > 2.5: 10 > > > > The only user of adjfreq(2) in base is ntpd(8), which caps it's > > adjustments between +/-MAX_FREQUENCY_ADJUST = 128e-5. > > > > It is very well possible the calculations in the kernel go wrong with > > large(r) values. The API exists for gradual adjustments, not for > > anything big. Scott Cheloha has been working > > on the kernel side of things, he might know more, so I Cc'ed him, > > don't know if her reads misc@. > > Thanks for doing this. > > Using a big adjustment was very convenient for fixing my problem, so it > might be of general use/interest. I guess alternatives would be to get > control early in boot and fix it up; or i think one can tell the OS that > the hardware clock is set to a particular offset from UTC (can't find > the man page for this right now, but i'm sure i came across it when > investigating adjfreq). ntpd fixes the clock very early in the boot using both htpps and ntp time sources, but is conservative: it does not do backward adjustments. There is utc_offset in src/conf/param.c. -Otto
Re: smtpd returns 'TempFail' and 'No route to destination' when using localhost as source behind NAT
It is worth to mention smtpd works absolutely fine for outgoing/incoming mail
if local machine has static IP address when:
...
table sources {1.2.3.4} equivalent to
table helonames {1.2.3.4 = smtp.domain.tld}
...
And yes, I have exactly the same action in /etc/mail/smtpd.conf
...
table sources {127.0.0.1}
table helonames {1.2.3.4 = smtp.domain.tld}
...
action "outbound" relay src helo-src
...
It looks like a bug or misconfiguration.
Martin
‐‐‐ Original Message ‐‐‐
On Thursday, August 13, 2020 1:28 PM, Kastus wrote:
> On Thu, Aug 13, 2020 at 10:35:32AM +, Martin wrote:
>
> > OpenSMTPd 6.7.0 OpenBSD 6.7-current on local machine. All machine's traffic
> > redirected trough iked IPsec VPN to remote gateway machine and uses PF NAT
> > rule first:
> > match out log on enc0 from 0.0.0.0/0 to 0.0.0.0/0 nat-to 10.100.0.2
> > where 10.100.0.2 is virtual IP to NAT all local machine's traffic right
> > into IPsec VPN tunnel.
> > Other local machine's services successfully connect to their destinations
> > using NAT from local machine's localhost by IPsec VPN.
> > Logically, smtpd should bind on 127.0.0.1 local machine and expose its
> > external remote gateway machine's IP in heloname as configured:
> >
> > cat /etc/mail/smtpd.conf
> >
> > =
> >
> > ...
> > table sources {127.0.0.1}
> > table helonames {1.2.3.4 = smtp.domain.tld}
> > ...
>
> You don't show how you use these tables in action definitions in your config.
>
> You need to have something like
>
> action dxxx relay src helo-src
Re: Problems with iwn wireless networking
On Sat, Aug 15, 2020 at 09:14:48AM +0100, Julian Smith wrote: > I'm seeing fairly frequent (e.g. more than daily) failures from an iwn0 > wireless network device, on a Lenovo X230. > > dmesg|grep iwn shows: > > iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, > MIMO 2T2R, MoW, address a4:4e:31:43:f1:60 > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: device timeout > iwn0: device timeout > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: fatal firmware error > iwn0: device timeout > iwn0: fatal firmware error > iwn0: fatal firmware error > > Uptime is 6 days, so this is several failures per day on average. > > iwn(4) DIAGNOSTICS says that these two types of error 'should not > happen'. > > Is here anything i can do about this? The machine is a Lenovo X230. > > Or is there alternative wireless hardware that i install instead that > is known to be reliable? > > Full dmesg is below. My kernel has a patch from visa@ to reduce gdb > uninterruptible wait problem (see 'gdb in uninterruptible wait' thread > on misc), but is otherwise vanilla 6.7. Could you try -current to see if the issue is still present there? On 6.7, does forcing 11a or 11g mode work around this? For example: ifconfig iwn0 mode 11g
Problems with iwn wireless networking
I'm seeing fairly frequent (e.g. more than daily) failures from an iwn0 wireless network device, on a Lenovo X230. dmesg|grep iwn shows: iwn0 at pci2 dev 0 function 0 "Intel Centrino Advanced-N 6205" rev 0x34: msi, MIMO 2T2R, MoW, address a4:4e:31:43:f1:60 iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: device timeout iwn0: device timeout iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: fatal firmware error iwn0: device timeout iwn0: fatal firmware error iwn0: fatal firmware error Uptime is 6 days, so this is several failures per day on average. iwn(4) DIAGNOSTICS says that these two types of error 'should not happen'. Is here anything i can do about this? The machine is a Lenovo X230. Or is there alternative wireless hardware that i install instead that is known to be reliable? Full dmesg is below. My kernel has a patch from visa@ to reduce gdb uninterruptible wait problem (see 'gdb in uninterruptible wait' thread on misc), but is otherwise vanilla 6.7. Thanks, - Jules OpenBSD 6.7 (GENERIC.MP) #1: Tue Jul 21 09:27:57 BST 2020 jules@jules-obsd:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 16972566528 (16186MB) avail mem = 16445550592 (15683MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdae9c000 (69 entries) bios0: vendor LENOVO version "G2ETA7WW (2.67 )" date 09/09/2016 bios0: LENOVO 232577G acpi0 at bios0: ACPI 5.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC TCPA SSDT SSDT SSDT HPET APIC MCFG ECDT FPDT ASF! UEFI UEFI MSDM SSDT SSDT DMAR UEFI DBG2 acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP3(S4) XHCI(S3) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.94 MHz, 06-3a-09 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,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 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz, 2893.43 MHz, 06-3a-09 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 4 (EXP3) acpicpu0 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(350@80 mwait.1@0x20), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(350@80
Re: Confused by adjfreq(2)
On Mon, 10 Aug 2020 09:53:10 +0200 Otto Moerbeek wrote: > On Sun, Aug 09, 2020 at 09:46:00PM +0100, Julian Smith wrote: > > > I've just used adjfreq() directly to correct my hardware clock, > > which was running an hour ahead of UTC (due to my hardware > > previously running Windows). > > > > But i've struggled to understand the adjfreq(2) man page, so ended > > up finding a value for by trial and error. > > > > I ended up with this code: > > > > double x = 1.5; > > int64_t newfreq = ((1ll << 32) * 1e9) * x; > > adjfreq(newfreq, NULL); > > This does not look like actual code, first arg should be a pointer. Ah yes, apologies for this, i foolishly hand-wrote the code above in the post. The actual code i used did pass a pointer: e = adjfreq(, ); > > > > > In this table, the second column is the increment in the time as > > shown by running date(1) twice, over a 10 second period as measured > > using my phone as a timer, for different values of x: > > > > x 10s > > - > > 0 10 > > 0.112 > > 0.25 13 > > 0.515 > > 0.75 17 > > 0.819 > > 0.919 > > 1.021 > > 1.1 1 > > 1.25: 3 > > 1.5:6 > > 1.75: 8 > > 2: 10 > > 2.25: 10 > > 2.5: 10 > > The only user of adjfreq(2) in base is ntpd(8), which caps it's > adjustments between +/-MAX_FREQUENCY_ADJUST = 128e-5. > > It is very well possible the calculations in the kernel go wrong with > large(r) values. The API exists for gradual adjustments, not for > anything big. Scott Cheloha has been working > on the kernel side of things, he might know more, so I Cc'ed him, > don't know if her reads misc@. Thanks for doing this. Using a big adjustment was very convenient for fixing my problem, so it might be of general use/interest. I guess alternatives would be to get control early in boot and fix it up; or i think one can tell the OS that the hardware clock is set to a particular offset from UTC (can't find the man page for this right now, but i'm sure i came across it when investigating adjfreq). Thanks, - Jules -- http://op59.net
Re: aggr(4) not working with Intel XXV710 SFP28 on a Supermicro X11DPi-N(T)
On 15.8.2020. 0:48, Hrvoje Popovski wrote: > On 12.8.2020. 15:18, Winfred Harrelson wrote: >> On Tue, Aug 11, 2020 at 07:52:10PM +0100, Tom Smyth wrote: >>> Hi Winfred, >>> the intel 710 is a complex card, I would suggest that you try updating the >>> firmware on the card, available from intel.com or your card vendor, >>> you may have to boot to a live linux cd to apply the firmware update, >>> >>> but I had some issues with the Intel XL710 cards and I had to update the >>> firmware to get it working stable, >>> >>> I hope this helps >>> Tom Smyth >> >> Adding misc@openbsd.org back to the CC for the record. >> >> Thanks for the quick reply. I didn't reply back yesterday because I >> was having trouble getting the firmware updated from a Linux boot disk. >> I ended up having to try from a Windows boot disk. Unfortunately, I >> am getting the same thing again: >> >> >> wharrels@styx2:/home/wharrels# dmesg | grep ^ixl >> ixl0 at pci5 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW >> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:28 >> ixl1 at pci5 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW >> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:ed:b7:29 >> ixl2 at pci8 dev 0 function 0 "Intel XXV710 SFP28" rev 0x02: port 0, FW >> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b0 >> ixl3 at pci8 dev 0 function 1 "Intel XXV710 SFP28" rev 0x02: port 1, FW >> 8.0.61820 API 1.11, msix, 8 queues, address 3c:fd:fe:eb:19:b1 >> ixl4 at pci12 dev 0 function 0 "Intel X722 10GBASE-T" rev 0x09: port 0, FW >> 3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f2 >> ixl5 at pci12 dev 0 function 1 "Intel X722 10GBASE-T" rev 0x09: port 1, FW >> 3.1.57069 API 1.5, msix, 8 queues, address 3c:ec:ef:1a:df:f3 >> >> Yup, all the XXV710 cards have been updated to newest firmware. >> >> Now for the (failed) attempt: >> >> wharrels@styx2:/etc# ifconfig ixl0 >> ixl0: flags=8843 mtu 1500 >> lladdr 3c:fd:fe:ed:b7:28 >> index 1 priority 0 llprio 3 >> media: Ethernet autoselect (25GbaseSR full-duplex) >> status: active >> wharrels@styx2:/etc# ifconfig ixl2 >> ixl2: flags=8843 mtu 1500 >> lladdr 3c:fd:fe:eb:19:b0 >> index 3 priority 0 llprio 3 >> media: Ethernet autoselect (25GbaseSR full-duplex) >> status: active >> wharrels@styx2:/etc# ifconfig aggr1 create >> wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl0 >> wharrels@styx2:/etc# ifconfig aggr1 trunkport ixl2 >> wharrels@styx2:/etc# ifconfig aggr1 up >> wharrels@styx2:/etc# ifconfig aggr1 >> aggr1: flags=8843 mtu 1500 >> lladdr fe:e1:ba:d0:7c:e9 >> index 11 priority 0 llprio 7 >> trunk: trunkproto lacp >> trunk id: [(8000,fe:e1:ba:d0:7c:e9,000B,,), >> (,00:00:00:00:00:00,,,)] >> ixl0 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9, key >> 0xb, port pri 0x8000 number 0x1 >> ixl0 lacp actor state activity,aggregation,defaulted >> ixl0 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key >> 0x0, port pri 0x0 number 0x0 >> ixl0 lacp partner state activity,aggregation,sync >> ixl0 port >> ixl2 lacp actor system pri 0x8000 mac fe:e1:ba:d0:7c:e9, key >> 0xb, port pri 0x8000 number 0x3 >> ixl2 lacp actor state activity,aggregation,defaulted >> ixl2 lacp partner system pri 0x0 mac 00:00:00:00:00:00, key >> 0x0, port pri 0x0 number 0x0 >> ixl2 lacp partner state activity,aggregation,sync >> ixl2 port >> groups: aggr >> media: Ethernet autoselect >> status: no carrier >> >> >> >> I tried doing another sysupgrade this morning just in case something >> had changed overnight but no luck. Any other ideas? >> >> Winfred >> > > Hi, > > could you try install snapshot from http://ftp.hostserver.de/archive/ > that is older than Thu Jun 25 06:41:38 2020 UTC ... > > maybe this commit broke xxv710 > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/pci/if_ixl.c?rev=1.56=text/x-cvsweb-markup > > i have vlans over aggr over x710-da2 with latest snapshot and it's > working as expected .. > > ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 0, FW > 7.3.60988 API 1.10, msix, 8 queues > ixl1 at pci1 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 1, FW > 7.3.60988 API 1.10, msix, 8 queues > with new firmware aggr is working ixl0 at pci1 dev 0 function 0 "Intel X710 SFP+" rev 0x02: port 0, FW 8.0.61820 API 1.11, msix, 8 queues ixl1 at pci1 dev 0 function 1 "Intel X710 SFP+" rev 0x02: port 1, FW 8.0.61820 API 1.11, msix, 8 queues
