Re: Filesystem corruption on OpenBSD routers after power outage?
On 19:30 Tue 04 Jun, Mogens Jensen wrote: > I'm going to build a router for use in a remote location, and I have > chosen OpenBSD 6.5 for the task. Unfortunately, it's not possible to > protect the router with an UPS, so it will have to be resilient enough > to survive sudden power outages and still boot without manual > intervention. > > In the past I have built a few Linux based routers and they were > configured to run from RAM. I have made some research to see if this is > also possible on OpenBSD and found that, while there are solutions to > have / read-only, none of this is officially supported. > > Can anyone with experience running OpenBSD routers without UPS, tell if > filesystem corruption is going to be a problem after power outages, or > if there are any officially supported ways to make the system resilient > enough to not break after a power outage? > > I'm using an mSATA disk with MLC flash in the router. > > Thanks in advance. I've had a couple of issues with my APU2-based router on 6.4. After the power outage the newly linked kernel was corrupted, and some files ended up in lost+found.
Re: chrome pledge "", syscall 289
Cord wrotes: > > Hi, > I have found the following errors on the log: > > /bsd: chrome[18585]: pledge "", syscall 289 > > they appear everytime I start chrome.. they are about 4 or 5, what means? > It's the first time, yesterday and in the past there aren't any. > > thx cord > It might be related: https://marc.info/?l=openbsd-tech&m=155899373514678&w=2
"ucode too large"
I've just replaced my home gateway with a brandless machine with an i5-7200U. While preparing, I noticed the message "ucode too large" scrolling by on the serial console, just before the kernel starts. The dmesg shows cpu0 as mode 06-8e-09: cpu0: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2395.19 MHz, 06-8e-09 While /etc/firmware/intel/06-8e-09 is the biggest file in that directory (at 193kB), so this probably has something to do with that and the MDS "fun". Machine works fine as far as I can tell (typing this mail over an SSH session through it). Cheers, Paul 'WEiRD' de Weerd OpenBSD 6.5-current (GENERIC.MP) #6: Tue Jun 4 15:05:10 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34263703552 (32676MB) avail mem = 33215164416 (31676MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8d717000 (86 entries) bios0: vendor American Megatrends Inc. version "5.12" date 05/28/2018 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SSDT HPET SSDT SSDT UEFI SSDT LPIT WSMT SSDT SSDT SSDT SSDT DBGP DBG2 SPCR DMAR ASF! acpi0: wakeup devices PS2K(S0) PS2M(S0) PXSX(S0) RP09(S0) PXSX(S0) RP10(S0) PXSX(S0) RP11(S0) PXSX(S0) RP12(S0) PXSX(S0) RP13(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) [...] 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) i5-7200U CPU @ 2.50GHz, 2395.19 MHz, 06-8e-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,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2394.44 MHz, 06-8e-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,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus -1 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus 1 (RP01) acpiprt10 at acpi0: bus 2 (RP02) acpiprt11 at acpi0: bus 3 (RP03) acpiprt12 at acpi0: bus 4 (RP04) acpiprt13 at acpi0: bus 5 (RP05) acpiprt14 at acpi0: bus 6 (RP06) acpiprt15 at acpi0: bus -1 (RP07) acpiprt16 at acpi0: bus -1 (RP08) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at acpi0: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1 (RP21) acpiprt22 at acpi0: bus -1 (RP22) acpiprt23 at acpi0: bus -1 (RP23) acpiprt24 at acpi0: bus -1 (RP24) acpiprt25 at acpi0: bus -1 (RP14) acpiprt26 at acpi0: bus -1 (RP15) acpiprt27 at acpi0: bus -1 (RP16) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: WRST acpipwrres1 at acpi0: WRST acpipwrres2 at acpi0: WRST acpipwrres3 at acpi0: WRST acpipwrres4 at acpi0: WRST acpipwrres5 at acpi0: WRST acpipwrres6 at acpi0: WRST acpipwrres7 at acpi0: WRST acpipwrres8 at acpi0: WRST acpipwrres9 at acpi0: WRST acpipwrres10 at acpi0: WRST acpipwrres11 at acpi0: WRST acpipwrres12 at acpi0: WRST acpipwrres13 at acpi0: WRST acpipwrres14 at acpi0: WRST acpipwrres15 at acpi0: WRST acpipwrres16 at acpi0: WRST acpipwrres17 at acpi0: WRST acpipwrres18 at acpi0: WRST acpipwrres19 at acpi0: WRST acpipwrres20 at acpi0: FN00, resource for FAN0 acpipwrres21 at acpi0: FN01, resource for FAN1 acpipwrres22 at acpi0: FN02, resource for FAN2 acpipwrres23 at acpi0: FN03, resource for FAN3 acpipwrres24 at acpi0: FN04, resource for
Re: "ucode too large"
On Fri, Jun 07, 2019 at 03:43:39PM +0200, Paul de Weerd wrote:
> I've just replaced my home gateway with a brandless machine with an
> i5-7200U. While preparing, I noticed the message "ucode too large"
> scrolling by on the serial console, just before the kernel starts.
>
> The dmesg shows cpu0 as mode 06-8e-09:
>
> cpu0: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2395.19 MHz, 06-8e-09
>
> While /etc/firmware/intel/06-8e-09 is the biggest file in that
> directory (at 193kB), so this probably has something to do with that
> and the MDS "fun".
>
> Machine works fine as far as I can tell (typing this mail over an SSH
> session through it).
>
This should work if you are using a -current EFI boot(9) or try the
following diff for the BIOS boot(9). In both cases make sure you
installboot the new code.
--
:wq Claudio
Index: arch/amd64/stand/libsa/exec_i386.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/exec_i386.c,v
retrieving revision 1.31
diff -u -p -r1.31 exec_i386.c
--- arch/amd64/stand/libsa/exec_i386.c 28 May 2019 17:38:02 - 1.31
+++ arch/amd64/stand/libsa/exec_i386.c 7 Jun 2019 13:58:05 -
@@ -226,7 +226,7 @@ ucode_load(void)
return;
buflen = sb.st_size;
- if (buflen > 128*1024) {
+ if (buflen > 256*1024) {
printf("ucode too large\n");
return;
}
Re: "ucode too large"
On Fri, Jun 07, 2019 at 03:43:39PM +0200, Paul de Weerd wrote:
> I've just replaced my home gateway with a brandless machine with an
> i5-7200U. While preparing, I noticed the message "ucode too large"
> scrolling by on the serial console, just before the kernel starts.
>
> The dmesg shows cpu0 as mode 06-8e-09:
>
> cpu0: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2395.19 MHz, 06-8e-09
>
> While /etc/firmware/intel/06-8e-09 is the biggest file in that
> directory (at 193kB), so this probably has something to do with that
> and the MDS "fun".
>
> Machine works fine as far as I can tell (typing this mail over an SSH
> session through it).
The limit was raised only for efiboot.
https://marc.info/?l=openbsd-cvs&m=155853966111794&w=2
For non-efi it is still 128KB. The region of memory it uses starts
at 1MB. I think you should be able to raise the 'too large' check
to 256KB without problem but have not tested this.
You'll need to run installboot after installing. Wouldn't hurt
to have a miniroot on removable media to recover if needed.
Index: arch/amd64/stand/boot/conf.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/boot/conf.c,v
retrieving revision 1.46
diff -u -p -r1.46 conf.c
--- arch/amd64/stand/boot/conf.c15 May 2019 06:52:33 - 1.46
+++ arch/amd64/stand/boot/conf.c7 Jun 2019 14:05:58 -
@@ -40,7 +40,7 @@
#include
#include
-const char version[] = "3.44";
+const char version[] = "3.45";
intdebug = 1;
Index: arch/amd64/stand/libsa/exec_i386.c
===
RCS file: /cvs/src/sys/arch/amd64/stand/libsa/exec_i386.c,v
retrieving revision 1.31
diff -u -p -r1.31 exec_i386.c
--- arch/amd64/stand/libsa/exec_i386.c 28 May 2019 17:38:02 - 1.31
+++ arch/amd64/stand/libsa/exec_i386.c 7 Jun 2019 14:04:19 -
@@ -226,7 +226,7 @@ ucode_load(void)
return;
buflen = sb.st_size;
- if (buflen > 128*1024) {
+ if (buflen > 256*1024) {
printf("ucode too large\n");
return;
}
Re: "ucode too large"
Hi Claudio, Jonathan, Thank you both for the diff - it has fixed the 'ucode too large' problem (this machine uses biosboot, not UEFI), and has made a difference in dmesg: cpu[01] both gained flags MD_CLEAR,TSXFA,L1DF,SSBD And a further down this changed: -cpu0: using Skylake AVX MDS workaround +cpu0: using VERW MDS workaround (except on vmm entry) -vmm0 at mainbus0: VMX/EPT (using slow L1TF mitigation) +vmm0 at mainbus0: VMX/EPT Full dmesg below. Thanks! Paul OpenBSD 6.5-current (GENERIC.MP) #6: Tue Jun 4 15:05:10 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34263703552 (32676MB) avail mem = 33215160320 (31676MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x8d717000 (86 entries) bios0: vendor American Megatrends Inc. version "5.12" date 05/28/2018 acpi0 at bios0: rev 2 acpi0: sleep states S0 S5 acpi0: tables DSDT FACP APIC FPDT MCFG SSDT FIDT SSDT HPET SSDT SSDT UEFI SSDT LPIT WSMT SSDT SSDT SSDT SSDT DBGP DBG2 SPCR DMAR ASF! acpi0: wakeup devices PS2K(S0) PS2M(S0) PXSX(S0) RP09(S0) PXSX(S0) RP10(S0) PXSX(S0) RP11(S0) PXSX(S0) RP12(S0) PXSX(S0) RP13(S0) PXSX(S0) RP01(S0) PXSX(S0) RP02(S0) [...] 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) i5-7200U CPU @ 2.50GHz, 2395.13 MHz, 06-8e-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,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,MD_CLEAR,TSXFA,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 24MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz, 2394.43 MHz, 06-8e-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,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,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,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 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus -1 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus -1 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus 1 (RP01) acpiprt10 at acpi0: bus 2 (RP02) acpiprt11 at acpi0: bus 3 (RP03) acpiprt12 at acpi0: bus 4 (RP04) acpiprt13 at acpi0: bus 5 (RP05) acpiprt14 at acpi0: bus 6 (RP06) acpiprt15 at acpi0: bus -1 (RP07) acpiprt16 at acpi0: bus -1 (RP08) acpiprt17 at acpi0: bus -1 (RP17) acpiprt18 at acpi0: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1 (RP21) acpiprt22 at acpi0: bus -1 (RP22) acpiprt23 at acpi0: bus -1 (RP23) acpiprt24 at acpi0: bus -1 (RP24) acpiprt25 at acpi0: bus -1 (RP14) acpiprt26 at acpi0: bus -1 (RP15) acpiprt27 at acpi0: bus -1 (RP16) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: WRST acpipwrres1 at acpi0: WRST acpipwrres2 at acpi0: WRST acpipwrres3 at acpi0: WRST acpipwrres4 at acpi0: WRST acpipwrres5 at acpi0: WRST acpipwrres6 at acpi0: WRST acpipwrres7 at acpi0: WRST acpipwrres8 at acpi0: WRST acpipwrres9 at acpi0: WRST acpipwrres10 at acpi0: WRST acpipwrres11 at acpi0: WRST acpipwrres12 at acpi0: WRST acpipwrres13 at acpi0: WRST acpipwrres14 at acpi0: WRST acpipwrres15 at acpi0: WRST acpipwrres16 at acpi0: WRST acpipwrres17 at acpi0: WRST acpipwrres18 at acpi0: WRST acpipwrres19 at acpi0: WRST acpipwrres20 at acpi0: FN00, resource for FAN0 acpipwrres21 at acpi0: FN01, resource for FAN1 acpipwrres22 at acpi0: FN02, resource for FAN2 acpipwrres23 at acpi0: FN03, resource for FAN3 acpipwrres24 at acpi0: FN04, resource for FAN4 acpitz0 at acpi0: critical temperature is 119 degC acpitz1 at
bad-ip-version 6
Hi list, Doing tcpdump(8) on a wireguard tunnel yields: # tcpdump -n -i tun0 icmp6 tcpdump: listening on tun0, link-type LOOP 18:44:34.742106 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo request [flowlabel 0xb6f77] 18:44:34.754246 bad-ip-version 6 18:44:35.802498 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo request [flowlabel 0xb6f77] 18:44:35.814841 bad-ip-version 6 18:44:36.860380 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo request [flowlabel 0xb6f77] 18:44:36.872536 bad-ip-version 6 18:44:37.917605 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo request [flowlabel 0xb6f77] 18:44:37.929694 bad-ip-version 6 — Huh? I thought that 6 is the current version? ;-) Also, the echo replies are not shown, although I know they exist. Is there a known problem with tcpdump(8) on wireguard tunnels? # uname -a OpenBSD wg.rebehn.net 6.5 GENERIC#2 amd64 dmesg|grep GENERIC OpenBSD 6.5-current (GENERIC) #2: Sun Jun 2 00:21:42 MDT 2019 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Running under VMware ESXI 6.7 Manpage and mailing list did not give any hints. Cheers, Heinrich
Re: SSL_ERROR_DECODE_ERROR_ALERT in Fedora 30 Firefox when connecting to some OpenBSD servers
On 2019-06-06, kasak wrote: > > Excuse me, can this issue also break dovecot and latest thunderbird? > With the latest thunderbird 60.7.0 (on fedora) my dovecot (and > opensmtpd) suddenly refuse to log me in. > Dovecot shows something like this in logs: > > TLS handshaking: SSL_accept() failed: error:140270E3:SSL > routines:ACCEPT_SR_CLNT_HELLO_C:parse tlsext Yes I am pretty much certain this has the same cause. Fixes: - move the server to current where this has been fixed already - the fix has been committed to -stable today so you can update libssl from there; if you already have a checkout you can do this cd /usr/src/lib/libssl cvs up -r OPENBSD_6_5 -Pd make obj make make install (and restart the relevant services) - an errata/syspatch is planned for this issue; should show up in the next few days (possibly Monday) - update crypto-policies from the Fedora testing repository, see links in comments 10/11 on https://bugzilla.redhat.com/show_bug.cgi?id=1713777 > I found workarond for this, by switching from "STARTTLS" to SLL/TLS for > imap. But OpenSMTPD still not working. > As I said, this behavior appeared in latest thunderbird 60.7.0. Older > versions of thunderbird work. btw, where possible it's usually a good idea to use a port which just uses plain TLS rather than starting as text and switching with STARTTLS, this avoids the risk of a cleartext connection being intercepted and modified to disable the STARTTLS. (of course if a client is configured to never send cleartext credentials then it doesn't matter, but that's not always done)
Re: bad-ip-version 6
On 2019-06-07, Heinrich Rebehn wrote: > Hi list, > > Doing tcpdump(8) on a wireguard tunnel yields: > > > # tcpdump -n -i tun0 icmp6 > tcpdump: listening on tun0, link-type LOOP > 18:44:34.742106 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo > request [flowlabel 0xb6f77] > 18:44:34.754246 bad-ip-version 6 > 18:44:35.802498 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo > request [flowlabel 0xb6f77] > 18:44:35.814841 bad-ip-version 6 > 18:44:36.860380 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo > request [flowlabel 0xb6f77] > 18:44:36.872536 bad-ip-version 6 > 18:44:37.917605 2001:470:7653:5::11 > 2001:638:60f:110::1:2: icmp6: echo > request [flowlabel 0xb6f77] > 18:44:37.929694 bad-ip-version 6 > > Huh? I thought that 6 is the current version? ;-) But v4+NAT/CGNAT is the will of the people! > Also, the echo replies are not shown, although I know they exist. Is there a > known problem with tcpdump(8) on wireguard tunnels? The replies are clearly the packets ~120ms after the echo requests that are shown as 'bad-ip-version-6'. It might be something wrong with the parser in tcpdump, or it might be something wrong with wg. Can you put a pcap online somewhere? (tcpdump -itun0 -s2000 -w /tmp/wg.pcap)
