Re: troubles with IPv6 routing to VMD guests

[Max Parmer]

On Sat, Mar 17, 2018 at 05:21:53PM -0700, Max Parmer wrote:
> I've been having a good time running some VMD guests on 6.2 and assigning them
> external IPs which are binat'd to them by the VM host. Recently I learned my
> hosting provider delegates a /64 to it's dedicated boxes and thought this 
> might
> be an interesting scenario to improve, and possibly simplify, by routing IPv6
> directly to my guests.
> 
> To start, I ensured that IPv6 was properly functional on the host:
> > # cat /etc/hostname.em0
> > inet6 autoconf
> > inet6 2607:53xx:6x:7a3b:: 64 eui64
> > inet xxx.xxx.211.59 255.255.255.0
> > inet alias xxx.xxx.219.108 255.255.255.0
> > inet alias xxx.xx.248.240 255.255.255.0
> > inet alias xxx.xx.248.241 255.255.255.0
> > inet alias xxx.xx.248.242 255.255.255.0
> > inet alias xxx.xx.248.243 255.255.255.0
> > # cat /etc/mygate
> > xxx.xxx.211.254
> > fe80::205:73ff:fea0:1%em0
> > # ifconfig em0
> > em0: flags=208843 mtu 1500
> > lladdr 0c:c4:7a:45:37:34
> > index 1 priority 0 llprio 3
> > groups: egress
> > media: Ethernet autoselect (1000baseT full-duplex,master,rxpause)
> > status: active
> > inet6 fe80::ec4:7aff:fe45:3734%em0 prefixlen 64 scopeid 0x1
> > inet6 2607:53xx:6x:7a3b:ec4:7aff:fe45:3734 prefixlen 64
> > inet xxx.xxx.211.59 netmask 0xff00 broadcast xxx.xxx.211.255
> > inet xxx.xxx.219.108 netmask 0xff00 broadcast xxx.xxx.219.255
> > inet xxx.xx.248.240 netmask 0xff00 broadcast xxx.xx.248.255
> > inet xxx.xx.248.241 netmask 0xff00 broadcast xxx.xx.248.255
> > inet xxx.xx.248.242 netmask 0xff00 broadcast xxx.xx.248.255
> > inet xxx.xx.248.243 netmask 0xff00 broadcast xxx.xx.248.255
> > # ifconfig vether0
> > vether0: flags=8943 mtu 1500
> > lladdr 00:00:d3:00:d0:0d
> > index 5 priority 0 llprio 3
> > groups: vether
> > media: Ethernet autoselect
> > status: active
> > inet6 fe80::200:d3ff:fe00:d00d%vether0 prefixlen 64 scopeid 0x5
> > inet 10.0.23.1 netmask 0xff00 broadcast 10.0.23.255
> > # ifconfig bridge0
> > bridge0: flags=41
> > description: switch1-local
> > index 6 llprio 3
> > groups: bridge
> > priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
> > designated: id 00:00:00:00:00:00 priority 0
> > vether0 flags=3
> > port 5 ifpriority 0 ifcost 0
> > tap0 flags=3
> > port 8 ifpriority 0 ifcost 0
> > Addresses (max cache: 100, timeout: 240):
> > 00:00:d3:00:12:00 tap0 1 flags=0<>
> > # slaacctl show interface em0
> > em0:
> >  index:   1 running: yes privacy: yes
> > lladdr: 0c:c4:7a:45:37:34
> >  inet6: fe80::ec4:7aff:fe45:3734%em0
> > Router Advertisement from fe80::205:73ff:fea0:1%em0
> > received: 2018-03-17 20:01:39; 143s ago
> > Cur Hop Limit:  64, M: 0, O: 0, Router Lifetime:  1800s
> > Default Router Preference: Medium
> > Reachable Time: 0ms, Retrans Timer: 0ms
> > prefix: 2607:53xx:6x:7aff:ff:ff:ff:ff/56
> > On-link: 1, Autonomous address-configuration: 1
> > vltime:2592000, pltime: 604800
> > Default router proposals
> > id:1, state:  CONFIGURED
> > router: fe80::205:73ff:fea0:1%em0
> > router lifetime:   1800
> > Preference: Medium
> > updated: 2018-03-17 20:01:39; 143s ago, timeout:   1642s
> > # route -nv show -inet6
> > Routing tables
> > 
> > Internet6:
> > DestinationGatewayFlags   
> > Refs  Use   Mtu  Prio Iface Label
> > defaultfe80::205:73ff:fea0:1%em0  UGS   
> >  04 -56 em0   "slaacd"
> > ::/96  ::1UGRS  
> >  00 32768 8 lo0
> > ::/104 ::1UGRS  
> >  00 32768 8 lo0
> > ::1::1UHhl  
> > 14   28 32768 1 lo0
> > ::127.0.0.0/104::1UGRS  
> >  00 32768 8 lo0
> > ::224.0.0.0/100::1UGRS  
> >  00 32768 8 lo0
> > ::255.0.0.0/104::1UGRS  
> >  00 32768 8 lo0
> > :::0.0.0.0/96  ::1UGRS  
> >  00 32768 8 lo0
> > 2002::/24  ::1UGRS  
> >  00 32768 8 lo0
> > 2002:7f00::/24 ::1UGRS  
> >  00 32768 8 lo0
> > 2002:e000::/20 ::1UGRS  
> >  00 32768 8 lo0
> > 2002:ff00::/24 ::1

troubles with IPv6 routing to VMD guests

[Max Parmer]

I've been having a good time running some VMD guests on 6.2 and assigning them
external IPs which are binat'd to them by the VM host. Recently I learned my
hosting provider delegates a /64 to it's dedicated boxes and thought this might
be an interesting scenario to improve, and possibly simplify, by routing IPv6
directly to my guests.

To start, I ensured that IPv6 was properly functional on the host:
> # cat /etc/hostname.em0
> inet6 autoconf
> inet6 2607:53xx:6x:7a3b:: 64 eui64
> inet xxx.xxx.211.59 255.255.255.0
> inet alias xxx.xxx.219.108 255.255.255.0
> inet alias xxx.xx.248.240 255.255.255.0
> inet alias xxx.xx.248.241 255.255.255.0
> inet alias xxx.xx.248.242 255.255.255.0
> inet alias xxx.xx.248.243 255.255.255.0
> # cat /etc/mygate
> xxx.xxx.211.254
> fe80::205:73ff:fea0:1%em0
> # ifconfig em0
> em0: flags=208843 mtu 1500
>   lladdr 0c:c4:7a:45:37:34
>   index 1 priority 0 llprio 3
>   groups: egress
>   media: Ethernet autoselect (1000baseT full-duplex,master,rxpause)
>   status: active
>   inet6 fe80::ec4:7aff:fe45:3734%em0 prefixlen 64 scopeid 0x1
>   inet6 2607:53xx:6x:7a3b:ec4:7aff:fe45:3734 prefixlen 64
>   inet xxx.xxx.211.59 netmask 0xff00 broadcast xxx.xxx.211.255
>   inet xxx.xxx.219.108 netmask 0xff00 broadcast xxx.xxx.219.255
>   inet xxx.xx.248.240 netmask 0xff00 broadcast xxx.xx.248.255
>   inet xxx.xx.248.241 netmask 0xff00 broadcast xxx.xx.248.255
>   inet xxx.xx.248.242 netmask 0xff00 broadcast xxx.xx.248.255
>   inet xxx.xx.248.243 netmask 0xff00 broadcast xxx.xx.248.255
> # ifconfig vether0
> vether0: flags=8943 mtu 1500
>   lladdr 00:00:d3:00:d0:0d
>   index 5 priority 0 llprio 3
>   groups: vether
>   media: Ethernet autoselect
>   status: active
>   inet6 fe80::200:d3ff:fe00:d00d%vether0 prefixlen 64 scopeid 0x5
>   inet 10.0.23.1 netmask 0xff00 broadcast 10.0.23.255
> # ifconfig bridge0
> bridge0: flags=41
>   description: switch1-local
>   index 6 llprio 3
>   groups: bridge
>   priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp
>   designated: id 00:00:00:00:00:00 priority 0
>   vether0 flags=3
>   port 5 ifpriority 0 ifcost 0
>   tap0 flags=3
>   port 8 ifpriority 0 ifcost 0
>   Addresses (max cache: 100, timeout: 240):
>   00:00:d3:00:12:00 tap0 1 flags=0<>
> # slaacctl show interface em0
> em0:
>index:   1 running: yes privacy: yes
>   lladdr: 0c:c4:7a:45:37:34
>inet6: fe80::ec4:7aff:fe45:3734%em0
>   Router Advertisement from fe80::205:73ff:fea0:1%em0
>   received: 2018-03-17 20:01:39; 143s ago
>   Cur Hop Limit:  64, M: 0, O: 0, Router Lifetime:  1800s
>   Default Router Preference: Medium
>   Reachable Time: 0ms, Retrans Timer: 0ms
>   prefix: 2607:53xx:6x:7aff:ff:ff:ff:ff/56
>   On-link: 1, Autonomous address-configuration: 1
>   vltime:2592000, pltime: 604800
>   Default router proposals
>   id:1, state:  CONFIGURED
>   router: fe80::205:73ff:fea0:1%em0
>   router lifetime:   1800
>   Preference: Medium
>   updated: 2018-03-17 20:01:39; 143s ago, timeout:   1642s
> # route -nv show -inet6
> Routing tables
> 
> Internet6:
> DestinationGatewayFlags   
> Refs  Use   Mtu  Prio Iface Label
> defaultfe80::205:73ff:fea0:1%em0  UGS
> 04 -56 em0   "slaacd"
> ::/96  ::1UGRS   
> 00 32768 8 lo0
> ::/104 ::1UGRS   
> 00 32768 8 lo0
> ::1::1UHhl  
> 14   28 32768 1 lo0
> ::127.0.0.0/104::1UGRS   
> 00 32768 8 lo0
> ::224.0.0.0/100::1UGRS   
> 00 32768 8 lo0
> ::255.0.0.0/104::1UGRS   
> 00 32768 8 lo0
> :::0.0.0.0/96  ::1UGRS   
> 00 32768 8 lo0
> 2002::/24  ::1UGRS   
> 00 32768 8 lo0
> 2002:7f00::/24 ::1UGRS   
> 00 32768 8 lo0
> 2002:e000::/20 ::1UGRS   
> 00 32768 8 lo0
> 2002:ff00::/24 ::1UGRS   
> 00 32768 8 lo0
> 2607:53xx:6x:7a3b::/64 2607:53xx:6x:7a3b:ec4:7aff:fe45:3734 UCn   
>  00 - 4 em0
> 2607:

Re: X server keeps crashing in current/amd64

[Jonathan Gray]

On Sat, Mar 17, 2018 at 10:40:55PM +0100, Robert wrote:
> Hi,
> 
> Since about two weeks the X server keeps crashing (segfault) most of the
> time when I start it (through xenodm).
> I have to restart it (rcctl restart xenodm) about 5-10 times
> until I get an (xfce) session that stays stable. 
> 
> I reinstalled today with the latest current/amd64, and now this issue became
> worse: In addition, even when I get a stable session, it crashes as
> soon as I do some actions, such as moving the mouse for a couple of
> seconds or starting Firefox.
> 
> Xorg.log says (from various such occurences):
> (EE) Segmentation fault at address 0x64bfcd81018
> (EE) Segmentation fault at address 0x17e082969018
> (EE) Segmentation fault at address 0x78e6159b000
> 
> Any ideas / recommendations on how to debug or fix this?
> (dmesg / xorg log below)

I see you have multiple screens in your Xorg log.

I've just committed an update to xf86-video-ati 18.0.1 which
mentions fixing a crash with multiple screens.

https://lists.x.org/archives/xorg-announce/2018-March/002884.html

* The Xorg process could crash when multiple primary screens are
  configured in xorg.conf.

Index: configure
===
RCS file: /cvs/xenocara/driver/xf86-video-ati/configure,v
retrieving revision 1.23
diff -u -p -r1.23 configure
--- configure   13 Mar 2018 06:13:13 -  1.23
+++ configure   17 Mar 2018 23:25:41 -
@@ -1,6 +1,6 @@
 #! /bin/sh
 # Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.69 for xf86-video-ati 18.0.0.
+# Generated by GNU Autoconf 2.69 for xf86-video-ati 18.0.1.
 #
 # Report bugs to 
.
 #
@@ -591,8 +591,8 @@ MAKEFLAGS=
 # Identity of this package.
 PACKAGE_NAME='xf86-video-ati'
 PACKAGE_TARNAME='xf86-video-ati'
-PACKAGE_VERSION='18.0.0'
-PACKAGE_STRING='xf86-video-ati 18.0.0'
+PACKAGE_VERSION='18.0.1'
+PACKAGE_STRING='xf86-video-ati 18.0.1'
 
PACKAGE_BUGREPORT='https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/Radeon'
 PACKAGE_URL=''
 
@@ -1390,7 +1390,7 @@ if test "$ac_init_help" = "long"; then
   # Omit some internal or obsolete options to make the list less imposing.
   # This message is too long to be a string in the A/UX 3.1 sh.
   cat <<_ACEOF
-\`configure' configures xf86-video-ati 18.0.0 to adapt to many kinds of 
systems.
+\`configure' configures xf86-video-ati 18.0.1 to adapt to many kinds of 
systems.
 
 Usage: $0 [OPTION]... [VAR=VALUE]...
 
@@ -1460,7 +1460,7 @@ fi
 
 if test -n "$ac_init_help"; then
   case $ac_init_help in
- short | recursive ) echo "Configuration of xf86-video-ati 18.0.0:";;
+ short | recursive ) echo "Configuration of xf86-video-ati 18.0.1:";;
esac
   cat <<\_ACEOF
 
@@ -1616,7 +1616,7 @@ fi
 test -n "$ac_init_help" && exit $ac_status
 if $ac_init_version; then
   cat <<\_ACEOF
-xf86-video-ati configure 18.0.0
+xf86-video-ati configure 18.0.1
 generated by GNU Autoconf 2.69
 
 Copyright (C) 2012 Free Software Foundation, Inc.
@@ -2031,7 +2031,7 @@ cat >config.log <<_ACEOF
 This file contains any messages produced by compilers while
 running configure, to aid debugging if configure makes a mistake.
 
-It was created by xf86-video-ati $as_me 18.0.0, which was
+It was created by xf86-video-ati $as_me 18.0.1, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   $ $0 $@
@@ -2862,7 +2862,7 @@ fi
 
 # Define the identity of the package.
  PACKAGE='xf86-video-ati'
- VERSION='18.0.0'
+ VERSION='18.0.1'
 
 
 cat >>confdefs.h <<_ACEOF
@@ -19881,7 +19881,7 @@ cat >>$CONFIG_STATUS <<\_ACEOF || ac_wri
 # report actual input values of CONFIG_FILES etc. instead of their
 # values after options handling.
 ac_log="
-This file was extended by xf86-video-ati $as_me 18.0.0, which was
+This file was extended by xf86-video-ati $as_me 18.0.1, which was
 generated by GNU Autoconf 2.69.  Invocation command line was
 
   CONFIG_FILES= $CONFIG_FILES
@@ -19947,7 +19947,7 @@ _ACEOF
 cat >>$CONFIG_STATUS <<_ACEOF || ac_write_fail=1
 ac_cs_config="`$as_echo "$ac_configure_args" | sed 's/^ //; 
s/[\\""\`\$]/&/g'`"
 ac_cs_version="\\
-xf86-video-ati config.status 18.0.0
+xf86-video-ati config.status 18.0.1
 configured by $0, generated by GNU Autoconf 2.69,
   with options \\"\$ac_cs_config\\"
 
Index: configure.ac
===
RCS file: /cvs/xenocara/driver/xf86-video-ati/configure.ac,v
retrieving revision 1.16
diff -u -p -r1.16 configure.ac
--- configure.ac13 Mar 2018 06:13:13 -  1.16
+++ configure.ac17 Mar 2018 23:25:17 -
@@ -23,7 +23,7 @@
 # Initialize Autoconf
 AC_PREREQ([2.60])
 AC_INIT([xf86-video-ati],
-[18.0.0],
+[18.0.1],
 
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg&component=Driver/Radeon],
 [xf86-video-ati])
 
Index: src/drmmode_display.c

X server keeps crashing in current/amd64

[Robert]

Hi,

Since about two weeks the X server keeps crashing (segfault) most of the
time when I start it (through xenodm).
I have to restart it (rcctl restart xenodm) about 5-10 times
until I get an (xfce) session that stays stable. 

I reinstalled today with the latest current/amd64, and now this issue became
worse: In addition, even when I get a stable session, it crashes as
soon as I do some actions, such as moving the mouse for a couple of
seconds or starting Firefox.

Xorg.log says (from various such occurences):
(EE) Segmentation fault at address 0x64bfcd81018
(EE) Segmentation fault at address 0x17e082969018
(EE) Segmentation fault at address 0x78e6159b000

Any ideas / recommendations on how to debug or fix this?
(dmesg / xorg log below)

Installing 6.2/amd64 removes the issue, so I don't think it's a hardware 
problem.

If it is relevant, this is an AMD Verde GPU, where the driver uses
software rendering. Also, I disabled xhci in the kernel (using config) due to 
https://marc.info/?l=openbsd-misc&m=143442925331480 .

regards,
Robert


dmesg (current
OpenBSD 6.3 (GENERIC.MP) #68: Fri Mar 16 01:24:47 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 17113550848 (16320MB)
avail mem = 16587821056 (15819MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec380 (81 entries)
bios0: vendor Dell Inc. version "A15" date 02/15/2017
bios0: Dell Inc. OptiPlex 3020
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC SSDT SSDT SSDT HPET SSDT MCFG SSDT
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) PXSX(S4) PXSX(S4) RP04(S4) 
PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S0) 
EHC2(S0) XHC_(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-4590 CPU @ 3.30GHz, 3492.35 MHz
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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
acpitimer0: recalibrated TSC frequency 3292383348 Hz
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.2.4, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz, 3491.93 MHz
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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,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) i5-4590 CPU @ 3.30GHz, 3491.93 MHz
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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,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) i5-4590 CPU @ 3.30GHz, 3491.93 MHz
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,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,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,SENSOR,ARAT,MELTDOWN
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 0, core 3, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpihpet0 at acpi0: 14318179 Hz
acpihpet0: recalibrated TSC frequency 3292372366 Hz
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (RP01)
acpiprt2 at acpi0: bus 3 (RP04)
acpiprt3 at acpi0: bus 4 (RP05)
acpiprt4 at acpi0: bus 5 (RP06)
acpiprt5 at acpi0: bus 1 (PEG0)
acpiprt6 at acpi0: bus -1 (PEG1)
acpiprt7 at acpi0: bus -1 (PEG2)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS
acpicpu3

With the latest snapshot there are some issues in Xfce, please help!

[Zsolt Kantor]

Hello to all.
I installed the latest snapshot with Xfce. But there are some issues whit Xfce. 
I found 3 problems.

1. The terminal size is very expanded, it is not 80x..., its 145x..., but if I 
check the terminal properties the width setting is 80. Very strange.

2. There are some dependency problems when I try to install chromium or 
firefox. For instance the colord package can not be found in the snapshot 
packages repository, and other package dependency problems are also displayed. 
So I can't install Chromium or Firefox.

3. My synaptic touchpad is not fully functional. In Xfce the touchpad tab is 
missing from the mouse and touchpad configuration window. This is not the case 
of 6.2. In OpenBSD 6.2 it was there.

Will these issues corrected until the release? Or should I send an e-mail to 
the bug's mailing list?

Thanks!

monkeying around with pf (why scrub twice?)

[Peter J. Philipp]

Hi,

I wrote a patch to program a very simple steganographic buffer into the pf
firewalling system.  However I'm running into a problem.  It turns out at
least to me, that pf's scrub gets called twice on output.  Why is this?

I'm making my patch available and the program to program the buffer into
pf.  It's ugly but I don't see a need to commit this ever, it's a small
personal project of mine...

When you see the code you'll see that when ip_stegid() gets called it 
increments the buffer offset by two, I'm missing data.  When I program
the buffer with '11223344556677889900AABBCCDDEEFF', in a tcpdump I see this:

20:33:13.120728 192.168.65.2 > 192.168.179.1: icmp: echo request (id:7195 
seq:7) [icmp cksum ok] (ttl 255, id 12593, len 84)
  : 4500 0054 3131  ff01 1523 c0a8 4102  E..T11.#..A.
  0010: c0a8 b301 0800 a4e7 7195 0007 2994 298a  q...).).
20:33:14.120730 192.168.65.2 > 192.168.179.1: icmp: echo request (id:7195 
seq:8) [icmp cksum ok] (ttl 255, id 13107, len 84)
  : 4500 0054   ff01 1321 c0a8 4102  E..T33.!..A.
  0010: c0a8 b301 0800 7b05 7195 0008 2994 298a  ..{.q...).).
20:33:15.120732 192.168.65.2 > 192.168.179.1: icmp: echo request (id:7195 
seq:9) [icmp cksum ok] (ttl 255, id 13621, len 84)
  : 4500 0054 3535  ff01 111f c0a8 4102  E..T55A.
  0010: c0a8 b301 0800 c128 7195 0009 2994 298a  ...(q...).).
20:33:16.120737 192.168.65.2 > 192.168.179.1: icmp: echo request (id:7195 
seq:10) [icmp cksum ok] (ttl 255, id 14135, len 84)
  : 4500 0054 3737  ff01 0f1d c0a8 4102  E..T77A.
  0010: c0a8 b301 0800 9580 7195 000a 2994 298a  q...).).
20:33:17.120736 192.168.65.2 > 192.168.179.1: icmp: echo request (id:7195 
seq:11) [icmp cksum ok] (ttl 255, id 14649, len 84)
  : 4500 0054 3939  ff01 0d1b c0a8 4102  E..T99A.
  0010: c0a8 b301 0800 0a73 7195 000b 2994 298a  ...sq...).).

So 11, 33, 55, 77, 99... exactly every 2nd value gets skipped.

For steganography this would suck as I'm trying to relay a message from one
computer to another and if only half arrives and it can't reassemble it it's
no good.  I'm not saying it has to be like TCP but some reliability would be
nice.  I'm guessing it's because ip_stegid() gets called twice per packet that
is outgoing.  Here is my rule btw for this:

beta# pfctl -srules|grep steg
pass out on vxlan0 inet proto icmp from any to 192.168.179.1 scrub (steg-id)

There was only 1 pinger on 192.168.179.1, I'm the only user on this box and
I should have seen this in the tcpdump.

Anyhow before I confuse everyone I'll just dump the code.  The patches to the
OS first and then the small program to ioctl the buffer into the kernel.

Regards,
-peter


Index: sbin/pfctl/parse.y
===
RCS file: /cvs/src/sbin/pfctl/parse.y,v
retrieving revision 1.670
diff -u -p -u -r1.670 parse.y
--- sbin/pfctl/parse.y  8 Feb 2018 09:15:46 -   1.670
+++ sbin/pfctl/parse.y  17 Mar 2018 19:45:13 -
@@ -273,6 +273,7 @@ struct filter_opts {
int  settos;
int  randomid;
int  max_mss;
+   int  stegid;
 
/* route opts */
struct {
@@ -302,6 +303,7 @@ struct scrub_opts {
int settos;
int randomid;
int reassemble_tcp;
+   int stegid;
 } scrub_opts;
 
 struct node_sc {
@@ -472,7 +474,7 @@ int parseport(char *, struct range *r, i
 %token NOROUTE URPFFAILED FRAGMENT USER GROUP MAXMSS MAXIMUM TTL TOS DROP TABLE
 %token REASSEMBLE ANCHOR SYNCOOKIES
 %token SET OPTIMIZATION TIMEOUT LIMIT LOGINTERFACE BLOCKPOLICY RANDOMID
-%token SYNPROXY FINGERPRINTS NOSYNC DEBUG SKIP HOSTID
+%token SYNPROXY FINGERPRINTS NOSYNC DEBUG SKIP HOSTID 
 %token ANTISPOOF FOR INCLUDE MATCHES
 %token BITMASK RANDOM SOURCEHASH ROUNDROBIN LEASTSTATES STATICPORT PROBABILITY
 %token WEIGHT BANDWIDTH FLOWS QUANTUM
@@ -482,6 +484,7 @@ int parseport(char *, struct range *r, i
 %token MAXSRCCONN MAXSRCCONNRATE OVERLOAD FLUSH SLOPPY PFLOW MAXPKTRATE
 %token TAGGED TAG IFBOUND FLOATING STATEPOLICY STATEDEFAULTS ROUTE
 %token DIVERTTO DIVERTREPLY DIVERTPACKET NATTO AFTO RDRTO RECEIVEDON NE LE GE
+%token STEGID
 %token   STRING
 %token   NUMBER
 %tokenPORTBINARY
@@ -1085,6 +1088,13 @@ scrub_opt: NODF  {
}
scrub_opts.randomid = 1;
}
+   | STEGID {
+   if (scrub_opts.stegid) {
+   yyerror("steg-id cannot be respecified");
+   YYERROR;
+   }
+   scrub_opts.stegid = 1;
+   }
;
 
 antispoof  : ANTISPOOF logquick antispoof_ifspc af antispoof_opts {
@@ -1588,6 +1598,8 @@ pfrule: 

re: obligatory leaving letter

[leo_tck]

Haai,

I just read the responses of Ingo & Espie, among others. Yes, just now,
in the archives, since for some mysterious reason, they weren't cc'd to
me (despite that I clearly stated that I had left).

Y'know, I could go on a long rant again (I'm rather prone to them, ain't
I?), but I won't bother you with that. What I will bother you with is my
response to the two fellows named above (accompanied by a hearthy laugh):

You g{irl,uy,whatever}s are incorrigible. But that's kind of okay. You
see, well, since you didn't appear to get the hint before, I'll spell it
out to you: the reason I left really is that I don't want to be in the
way.

Keep up the good work everyone, really. Our goals may differ, our
methods may differ, our entire mindset may differ, but that's okay to
me, even if (going by Ingo & Espie's responses) it might not be to you.

Then there's the emerging "who got pissed off first and thus had the
right to be an ass" contest. I think I'll pass: my goal is not to
create (or sustain) drama. To the measure that I fail in that goal, I
apologize.

I hope this finally closes the matter of my departure.

Good day everyone,

Baai,

--zeurkous.

-- 
Friggin' Machines!

what is UNIX about? (was: Re: obligatory leaving letter)

[leo_tck]

Since I don't want to be guilty of spreading unfounded information, I'll
still respond, if tersely, to Rod{erick,rigo}, who doesn't appear to
have cc'd me either.

I'll quote [0]:
> What we wanted to preserve was not just a good environment in which to
> do programming, but a system around which a fellowship could form. We
> knew from experience that the essence of communal computing, as
> supplied by remote-access, time-shared machines, is not just to type
> programs into a terminal instead of a keypunch, but to encourage close
> communication.

dmr also (somewhat awkwardly) read that up from his tty in a promotional
video once. Thinking about the atmosphere depicted in the video, perhaps
'fellowship' is a more appropriate term than 'family', indeed.

Not that Rod{erick,rigo} was that much off: he simply looked at it from
a different angle.

--zeurkous.

[0] https://www.bell-labs.com/usr/dmr/www/hist.html

-- 
Friggin' Machines!

Re: Installing a snapshot to a USB key using bsd.rd

[Chris Bennett]

On Sat, Mar 17, 2018 at 03:59:01AM +, Rodney Polkinghorne wrote:
> Hi
> 
> This is my first post here, I appreciate how much work you all do, please
> be gentle. :-)
> 
> Could someone please tell me how to install the latest snapshot, or point
> me at some instructions that work?  I tried the following:
> 
> 1. Download bsd.rd and SHA256.sig from
> http://mirror.aarnet.edu.au/pub/OpenBSD/snapshots/
> 
> 2. Fail to verify the 6.3 signatures, because I'm running 6.1.  (It would
> be nice if the signify man page had instructions to download and verify
> openbsd--base.pub.)
> 
> 3. Reboot, with boot> boot sd0a:/root/bsd.rd
> 
> 4. Choose to install to sd1 (a USB key), default options, location of sets
> is http, HTTP server is mirror.aarnet.edu.au.
> 
> 5. The default server directory is pub/OpenBSD/6.3/i386, override that with
> snapshots instead of 6.3
> 
> 6. Leave all sets selected, and say done
> 
> At this point, the installer reported that SHA256.sig had downloaded and
> verified, and that bsd downloaded but failed its checksum test.
> 
> Possibly the answer is to ignore the checksums, but I want to ask first.
> 
> Rodney Polkinghorne

You need to be sure to use the bsd.rd from the snapshot!
You say install, which is very different from upgrade.
Even with a fresh install, if you want to keep something like the
existing /home directory, just don't include it in the new disklabel.
But be sure to be able to correctly include the correct mount
directories for the existing partitions which will come up if you pick a
custom disklabel. For example typing 'n a' will let you enter / as the
partition mount point. I wouldn't try upgrading if you want a snapshot
since so much changes. Note that you can put the files on the directory
that you don't want to get newfs to run on, but be sure NOT to add it in
the disklabel until you are done with the install.
Also, using ! will get you into the shell if you get confused.

I recommend backing up the partition you want to keep, /etc and the
list of packages you will need to re-install. Sometimes packages you
were using have been dropped, so be prepared to deal with that.

If you have another USB, install the OS and play around with it until
you get a good idea of what's going on. It's kind of cool once you see
all the tricks you can do. Just be sure to play around after you have
OpenBSD installed so that you will find that the original disklabel
shows up during an install under the custom option, just without the
mount points showing up.

Also, watch where the mount points start and end. You can growfs a
partition if and only if you are using the partition that follows it.
Which means that you should add partitions in the order that let's you
sacrifice the next one if you find something like /usr/local too small.
/usr/local followed by /var would be a bad idea since messing with /var
is possible but a real pain to do.

Have some fun. umount a partition that isn't essential and run fsck, not
fsck -fp on it and see what gets done.

Enjoy!
Chris Bennett

Re: IPsec/ISAKMP-trouble after Upgrade 6.0 --> 6.1 --> 6.2 amd64 : ISAKMPD: got AES_CBC, expected 3DES_CBC

[Andre Ruppert]

Fri, 16 Mar 2018 13:25:49 +0100
Janne Johansson :

> 2018-03-16 12:26 GMT+01:00 Andre Ruppert :
> 
> > Hello @misc,
> >
> > after a nightly release upgrade of our VPN-Gateway(s) from 6.0 via
> > 6.1 to 6.2 (amd64) I noticed some trouble with my VPN connections.
> >  
> 
> Almost always when you get "expected 3DES" it means "the confs are not
> matching so obsd chose some default thing which includes 3DES
> which is not what the other side is running".
> 
> Things like mixing up "from NetA to NetB" and the other side not
> having the exact opposite is a decent way to get that exact error.
> 
> I don't know what part changed so that it is no longer matching for
> you, but something makes the negotiations not think
> the remote proposal is what it expects, so it goes into some default
> mode from which it will never make a connection.
> 

I agree with you in principle, but the question is: why drop these
connections (with untouched configurations) sporadically with 6.2
and _not_ with 6.0?

Some of these connections drop several times in 24h.

No problems at all with 6.0.

And it's always the same behavior: 
first drops the esp tunnel and the esp flows remain active.
And its not possible to stop them with 'ipsecctl -d -f  '

Is it only possible to stop zombie-type flows with fifo commands?

Best regards
Andre

Re: scsi_xfer pool exhausted

[Jeremie Courreges-Anglas]

On Wed, Mar 14 2018, Tor Houghton  wrote:
> On Wed, Mar 14, 2018 at 05:56:19PM +0100, Tor Houghton wrote:
>> On Tue, Mar 13, 2018 at 11:23:12PM -0700, Peter van Oord v/d Vlies wrote:
>> > Hello Martijn,
>> > 
>> > Did you ever found an solution ?
>> > I have the same at a customer system.
>> > 
>> 
>> I'd like to chip in with a "me too" here. It's "suddenly" started happening
>> to my apu2c2 device.
>> 
>> I say "suddenly" because it started happening after I did syspatch on a
>> default 6.2 amd64 install.
>> 
>
> I finally had time to babysit the host, and it appears that the root cause
> for my issue was a cron job (ftp client) that didn't gracefully handle error
> situations (remote host not responding properly to https://, resulting in
> far too many ftp processes..). Assumptions lead to poor error handling and ..
> causation, correlation - yeah. 
>
> (I am sure someone will know why this would trigger a scsi message.)

A possible chain of events would be: too many processes -> low ram ->
try to use swap -> the scsi subsystem beneath the swap device lacks ram
and panics.  Just a guess...

-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Re: OT strange nsd behavior

[Ivo Chutkin]

On 17.3.2018 г. 09:20 ч., Peter J. Philipp wrote:

On Fri, Mar 16, 2018 at 10:40:37PM +0200, Ivo Chutkin wrote:

It should be, here is the result:

~ # nsd-checkzone proprevod.com /var/nsd/zones/master/clients/proprevod.com
zone proprevod.com is ok

and nsd-checkconf does not return errors.

I am lost here...


Make sure you don't deviate from the spelling of the zone.  Ie. a
"propervod.com" in the zone conf declaration and vs. a "proprevod.com" in
the zonefile itself.  There is a log that you provided that has both
spelling.  I believe that would be it.  If not show me your config file as
well.

Also try not to combine the A for proprevod.com. that you have in your zone
file with the @, otherwise it's confusing for any reader.

Regards,

-peter



Thanks a lot Peter,

It was this typing mistake I could not see.

Everything works now.

Have a nice weekend!


On 16.3.2018 ??. 21:35 ??., Stephane HUC "PengouinBSD" wrote:

Are you sure your zonefile is really good?

Have you tested with nsd-checkzone tool?
idem for your nsd config with nsd-checkconf tool?

Le 03/16/18 ?? 18:55, Ivo Chutkin a ??crit :

Hi to all there,

I am running authoritative dns servers on 5.9 and nsd.

I add new domain but I got these errors:

Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:9: SOA
record with invalid domain name
Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:11: out of
zone data
Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:12: out of
zone data
Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:14: out of
zone data
Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:16: out of
zone data
Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:17: out of
zone data
Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:18: out of
zone data
Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:19: zone
configured as 'propervod.com' has no SOA record.
Mar 16 19:29:16 dns11 nsd[7480]: zone propervod.com file
master/clients/proprevod.com read with 8 errors

Domain is valid, dns records point to my dns servers (dns11.bg1.eu and
dns12.bg1.eu).

The zone file looks like this:

/var/nsd/zones/master # cat ./clients/proprevod.com

$ORIGIN proprevod.com.
$TTL 86400

@   3600SOA dns11.bg1.eu. support.bg1.eu. (
  2018031601  ; serial
  1800; refresh
  7200; retry
  1209600 ; expire
  3600 )  ; negative

  NS  dns11.bg1.eu.
  NS  dns12.bg1.eu.

  MX  0 mail.dih.bg.

www A   91.235.248.25
proprevod.com.  A   91.235.248.25
mailCNAME   mail.dih.bg.

What could be wrong here?

Exactly the same zone but with different TLD loads and work as it should.

The only problem I could imagine is that I added this zone before my
servers were authoritative for this domain.

I will appreciate your help.

Thanks,
Ivo

Re: odd ARP problem - arp requests not being made when I expect them

[Otto Moerbeek]

On Sat, Mar 17, 2018 at 02:34:09PM +1100, Cameron Simpson wrote:

> I'm running OpenBSD 6.0 i386 on a Soekris as my local firewall. We had/have
> a problem with network dropouts on our NBN satellite connection which I
> believe I've traced to the firewall's ARP entry for the upstream gateway
> expiring.
> 
> The problem appears to be that once the ARP entry expires, the firewall does
> not issue an ARP who-was request to renew the entry. As a consequence
> packets can't be forwarded to the gateway and it looks like an ISP outage.
> This state persists for periods of up to 10 minutes.
> 
> During the "outage" DHCP on the ISP link works (presumably because that
> doesn't involve the arp table) but pings to the gateway do not, and nor does
> any other normal IP traffic which requires using the gateway.
> 
> I left a tcpdump running for the gateway host IP and noticed this morning
> that immediately after an ARP request occurred and was answered
> (immediately) that traffic commenced working again, which led to to pursuing
> this.
> 
> I don't understand why, since the gateway address doesn't have a current ARP
> entry, the firewall does not imemdiately issue an ARP request for it. Even a
> ping directly from the firewall to the gateway address does not cause an ARP
> request.
> 
> In case it is relevant, all the through traffic is directed via PF nat-to
> rules, but I suspect this isn't related because direct ping traffic from the
> firewall also doesn't work. On the other hand, there's a secondary interface
> to a 3G modem which doesn't do this, and traffic through that interface is
> not NATed because the 3G modem does it.
> 
> Finally, I've done the following to verify the issue:
> 
> Waited for the ARP entry to expire, and saw throughput cease and direct
> pings of the gateway from the firewall fail:
> 
>  ping 172.16.20.254
>  PING 172.16.20.254 (172.16.20.254): 56 data bytes
>  ping: sendto: Host is down
>  ping: wrote 172.16.20.254 64 chars, ret=-1
>  ping: sendto: Host is down
>  ping: wrote 172.16.20.254 64 chars, ret=-1
> 
> I added the ARP entry by hand with the arp command and throughput and pings
> resumed immediately.
> 
> I've manually removed the ARP entry and seem identical symptoms, and I've
> manually added a static ARP entry for the gateway and the connection has
> been solid for several hours now. Versus "outages" every hour, if not more
> frequently.
> 
> I would like to understand this behaviour and to know if it is, as it
> appears, a bug.
> 
> Cheers,
> Cameron Simpson 

1. OpenBSD 6.0 is not suppored anymore. Upgrade, it's easy almost always.

2. You really should add details about your network config. Otherwise,
we can only guess.

-Otto

odd ARP problem - arp requests not being made when I expect them

[Cameron Simpson]

I'm running OpenBSD 6.0 i386 on a Soekris as my local firewall. We had/have a 
problem with network dropouts on our NBN satellite connection which I believe 
I've traced to the firewall's ARP entry for the upstream gateway expiring.


The problem appears to be that once the ARP entry expires, the firewall does 
not issue an ARP who-was request to renew the entry. As a consequence packets 
can't be forwarded to the gateway and it looks like an ISP outage. This state 
persists for periods of up to 10 minutes.


During the "outage" DHCP on the ISP link works (presumably because that doesn't 
involve the arp table) but pings to the gateway do not, and nor does any other 
normal IP traffic which requires using the gateway.


I left a tcpdump running for the gateway host IP and noticed this morning that 
immediately after an ARP request occurred and was answered (immediately) that 
traffic commenced working again, which led to to pursuing this.


I don't understand why, since the gateway address doesn't have a current ARP 
entry, the firewall does not imemdiately issue an ARP request for it. Even a 
ping directly from the firewall to the gateway address does not cause an ARP 
request.


In case it is relevant, all the through traffic is directed via PF nat-to 
rules, but I suspect this isn't related because direct ping traffic from the 
firewall also doesn't work. On the other hand, there's a secondary interface to 
a 3G modem which doesn't do this, and traffic through that interface is not 
NATed because the 3G modem does it.


Finally, I've done the following to verify the issue:

Waited for the ARP entry to expire, and saw throughput cease and direct pings 
of the gateway from the firewall fail:


 ping 172.16.20.254
 PING 172.16.20.254 (172.16.20.254): 56 data bytes
 ping: sendto: Host is down
 ping: wrote 172.16.20.254 64 chars, ret=-1
 ping: sendto: Host is down
 ping: wrote 172.16.20.254 64 chars, ret=-1

I added the ARP entry by hand with the arp command and throughput and pings 
resumed immediately.


I've manually removed the ARP entry and seem identical symptoms, and I've 
manually added a static ARP entry for the gateway and the connection has been 
solid for several hours now. Versus "outages" every hour, if not more 
frequently.


I would like to understand this behaviour and to know if it is, as it appears, 
a bug.


Cheers,
Cameron Simpson 

Re: Installing a snapshot to a USB key using bsd.rd

[Oliver Marugg]

On 17 Mar 2018, at 4:59, Rodney Polkinghorne wrote:


Hi

This is my first post here, I appreciate how much work you all do, 
please

be gentle. :-)

Could someone please tell me how to install the latest snapshot, or 
point

me at some instructions that work?  I tried the following:

1. Download bsd.rd and SHA256.sig from
http://mirror.aarnet.edu.au/pub/OpenBSD/snapshots/

2. Fail to verify the 6.3 signatures, because I'm running 6.1.  (It 
would
be nice if the signify man page had instructions to download and 
verify

openbsd--base.pub.)

3. Reboot, with boot> boot sd0a:/root/bsd.rd

4. Choose to install to sd1 (a USB key), default options, location of 
sets

is http, HTTP server is mirror.aarnet.edu.au.

5. The default server directory is pub/OpenBSD/6.3/i386, override that 
with

snapshots instead of 6.3

6. Leave all sets selected, and say done

At this point, the installer reported that SHA256.sig had downloaded 
and

verified, and that bsd downloaded but failed its checksum test.

Possibly the answer is to ignore the checksums, but I want to ask 
first.


Rodney Polkinghorne



AFAIK You can only upgrade from one major release to another. Check 
upgrade guide https://www.openbsd.org/faq/upgrade62.html
At the moment snapshots are already 6.3-beta, which will be the release 
following 6.2 according to upgrade guide, and the snapshots are/will be 
prepared for upcoming 6.3 (installurl and path, path to packages etc.). 
I guess its better the whole system will be correctly updated to 
6.2-release first. Then switch from a freshly updated 
6.2-release->6.2-current (eq 6.3-beta).

Re: OT strange nsd behavior

[Peter J. Philipp]

On Fri, Mar 16, 2018 at 10:40:37PM +0200, Ivo Chutkin wrote:
> It should be, here is the result:
> 
> ~ # nsd-checkzone proprevod.com /var/nsd/zones/master/clients/proprevod.com
> zone proprevod.com is ok
> 
> and nsd-checkconf does not return errors.
> 
> I am lost here...

Make sure you don't deviate from the spelling of the zone.  Ie. a 
"propervod.com" in the zone conf declaration and vs. a "proprevod.com" in
the zonefile itself.  There is a log that you provided that has both
spelling.  I believe that would be it.  If not show me your config file as
well.

Also try not to combine the A for proprevod.com. that you have in your zone
file with the @, otherwise it's confusing for any reader.

Regards,

-peter


> On 16.3.2018 ??. 21:35 ??., Stephane HUC "PengouinBSD" wrote:
> > Are you sure your zonefile is really good?
> > 
> > Have you tested with nsd-checkzone tool?
> > idem for your nsd config with nsd-checkconf tool?
> > 
> > Le 03/16/18 ?? 18:55, Ivo Chutkin a ??crit :
> > > Hi to all there,
> > > 
> > > I am running authoritative dns servers on 5.9 and nsd.
> > > 
> > > I add new domain but I got these errors:
> > > 
> > > Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:9: SOA
> > > record with invalid domain name
> > > Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:11: out of
> > > zone data
> > > Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:12: out of
> > > zone data
> > > Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:14: out of
> > > zone data
> > > Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:16: out of
> > > zone data
> > > Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:17: out of
> > > zone data
> > > Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:18: out of
> > > zone data
> > > Mar 16 19:29:16 dns11 nsd[7480]: master/clients/proprevod.com:19: zone
> > > configured as 'propervod.com' has no SOA record.
> > > Mar 16 19:29:16 dns11 nsd[7480]: zone propervod.com file
> > > master/clients/proprevod.com read with 8 errors
> > > 
> > > Domain is valid, dns records point to my dns servers (dns11.bg1.eu and
> > > dns12.bg1.eu).
> > > 
> > > The zone file looks like this:
> > > 
> > > /var/nsd/zones/master # cat ./clients/proprevod.com
> > > 
> > > $ORIGIN proprevod.com.
> > > $TTL 86400
> > > 
> > > @   3600SOA dns11.bg1.eu. support.bg1.eu. (
> > >  2018031601  ; serial
> > >  1800; refresh
> > >  7200; retry
> > >  1209600 ; expire
> > >  3600 )  ; negative
> > > 
> > >  NS  dns11.bg1.eu.
> > >  NS  dns12.bg1.eu.
> > > 
> > >  MX  0 mail.dih.bg.
> > > 
> > > www A   91.235.248.25
> > > proprevod.com.  A   91.235.248.25
> > > mailCNAME   mail.dih.bg.
> > > 
> > > What could be wrong here?
> > > 
> > > Exactly the same zone but with different TLD loads and work as it should.
> > > 
> > > The only problem I could imagine is that I added this zone before my
> > > servers were authoritative for this domain.
> > > 
> > > I will appreciate your help.
> > > 
> > > Thanks,
> > > Ivo
> > > 
> > > 
> >