regression using vncviewer (net/ssvnc) on inteldrm
Yesterday I upgraded my workstation to a current snapshot and noticed a big performance decrease in vncviewer. I have a session to a machine running macOS at 1920x1080 (my setup consists of 2x 1920x1080 monitors, vncviewer is run in full screen on one of the two screens). When vncviewer is on my active desktop, my mouse becomes sluggish on the screen that doesn't show the vncviewer window. Moving my mouse on the vncviewer window is basically unworkable: the cursor is trailing behind movements by about half a second (it varies a bit). When the screen is updated, you see it redrawing the full screen. Changing workspaces on the remote machine (causing a full screen redraw) takes ~15 seconds. During all this, Xorg consumes ~12% CPU when the window is not active but in view (nothing updating on the remote screen, expect the clock every minute). Constantly moving my mouse in the vncviewer window, Xorg eats 100% CPU, with ~25% system time and ~75% interrupt. Network connectivity to the remote machine is gigabit ethernet (all local traffic). Note that vncviewer was never really blazing fast, but at least it was workable. Obviously, vncviewer is doing something weird because other programs don't seem affected by whatever changed (I'm guessing it's the switch to using the modesetting driver on my hardware). /var/run/dmesg.boot and /var/log/Xorg.0.log included below. Cheers, Paul --- /var/run/dmesg.boot -- OpenBSD 6.1-current (GENERIC.MP) #94: Mon Jul 10 18:20:35 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34243919872 (32657MB) avail mem = 33200308224 (31662MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec410 (88 entries) bios0: vendor Dell Inc. version "A12" date 05/06/2015 bios0: Dell Inc. OptiPlex 9020 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! DMAR acpi0: wakeup devices UAR1(S3) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(S4) PEG0(S4) PEGP(S4) PEG1(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.85 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 cpu0: 256KB 64b/line 8-way L2 cache cpu0: TSC frequency 3392845010 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) i7-4770 CPU @ 3.40GHz, 3392.14 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 cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 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 cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 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 cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 cpu4 at mainbus0: apid 1 (application processor) cpu4: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz, 3392.14 MHz cpu4:
multicast reception fails for certain groups on interfaces with TI ThunderLAN chip
>Synopsis: multicast reception fails for certain groups on interfaces with
>TI ThunderLAN chip
>Category: system
>Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC) #4: Tue Jul 11 21:35:56 PDT
2017
briggs@pigeon:/usr/obj/sys/arch/i386/compile/GENERIC
Architecture: OpenBSD.i386
Machine : i386
>Description:
Applications running on a system with a TI ThunderLAN ethernet
controller chip,
for example the "Compaq Netelligent 10/100TX", that receive multicast packets
may find
that no packets are received for certain multicast hardware addresses.
>How-To-Repeat:
On problem system: with openmdns-0.7 package installed and running on a
"tl" interface
# tcpdump -p -w -i tl0 multicast
check whether any multicast DNS packets are seen to destination
01:00:5e:00:00:fb
(generate traffic from, for example "ping problemhost.local" from an
mdns aware system on the local network)
if NO IPv4 multicast packets to 224.0.0.251 are observed the problem
has been replicated.
if packets such as
22:28:45.774775 00:25:00:3e:ae:2d 01:00:5e:00:00:fb ip 77: 192.168.42.64.mdns >
224.0.0.251.mdns: 0 A (QU)? problemhost.local. (35)
are reported the problem is fixed.
>Fix:
The code in if_tl.c, tl_calchash() is wrong in that it doesn't
compensate for signed char type so that the XOR operations to generate the
multicast hash index are polluted by sign extension if the MSbit of the 1st and
4th or 2nd and 5th bytes of the multicast destination ethernet address are not
equal. This is the patch for that problem:
Index: if_tl.c
===
RCS file: /cvs/src/sys/dev/pci/if_tl.c,v
retrieving revision 1.70
diff -u -p -r1.70 if_tl.c
--- if_tl.c 22 Jan 2017 10:17:38 - 1.70
+++ if_tl.c 12 Jul 2017 05:08:46 -
@@ -751,8 +751,8 @@ tl_calchash(caddr_t addr)
{
int t;
- t = (addr[0] ^ addr[3]) << 16 | (addr[1] ^ addr[4]) << 8 |
- (addr[2] ^ addr[5]);
+ t = (addr[0] ^ addr[3]) << 16 | (0xff & (addr[1] ^ addr[4])) << 8 |
+ (0xff & (addr[2] ^ addr[5]));
return ((t >> 18) ^ (t >> 12) ^ (t >> 6) ^ t) & 0x3f;
}
dmesg:
(this kernel has had the above patch applied and now functions correctly)
OpenBSD 6.1-current (GENERIC) #4: Tue Jul 11 21:35:56 PDT 2017
briggs@pigeon:/usr/obj/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 300 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX,PERF
real mem = 402145280 (383MB)
avail mem = 381214720 (363MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 05/12/99, BIOS32 rev. 0 @ 0xed000
apm0 at bios0: Power Management spec V1.2
pcibios0 at bios0: rev 2.1 @ 0xed000/0x3000
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xf6fa0/160 (8 entries)
pcibios0: PCI Interrupt Router at 000:20:0 ("Intel 82371AB PIIX4 ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc/0x8000 0xc8000/0x3800
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443LX AGP" rev 0x03
intelagp0 at pchb0
agp0 at intelagp0: aperture at 0x4400, size 0x400
ppb0 at pci0 dev 1 function 0 "Intel 82443LX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "Matrox MGA Millennium II 2164WA-B AGP" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ahc0 at pci0 dev 15 function 0 "Adaptec AIC-7860" rev 0x03: irq 10
ahc0: Host Adapter Bios disabled. Using default SCSI device parameters
scsibus1 at ahc0: 8 targets, initiator 7
tl0 at pci0 dev 16 function 0 "Compaq Embedded Netelligent 10/100TX" rev 0x10:
irq 11 address 00:80:5f:bd:53:49
lxtphy0 at tl0 phy 1: LXT970 10/100 PHY, rev. 0
tlphy0 at tl0 phy 31: ThunderLAN 10baseT PHY, rev. 6
piixpcib0 at pci0 dev 20 function 0 "Intel 82371AB PIIX4 ISA" rev 0x01
pciide0 at pci0 dev 20 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel 0
wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA48, 38146MB, 78125000 sectors
wd1 at pciide0 channel 0 drive 1:
wd1: 16-sector PIO, LBA48, 152627MB, 312581808 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
wd1(pciide0:0:1): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus2 at atapiscsi0: 2 targets
cd0 at scsibus2 targ 0 lun 0: ATAPI 5/cdrom removable
cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 1
uhci0 at pci0 dev 20 function 2 "Intel 82371AB USB" rev 0x01: irq 11
piixpm0 at pci0 dev 20 function 3 "Intel 82371AB Power" rev 0x01: SMI
iic0 at piixpm0
spdmem0 at iic0 addr
static PIE & corrupted trace
Binaries linked with '-static -pie' produce unusable core dumps at least
on amd64. This is a real problem to debug isakmpd(8)/iked(8) crashing on
production machines.
With the diff below, I trigger a NULL-dereference in ntpd(8). When
compiled with '-static -pie' I obtain the following trace:
# gdb /sbin/ntpd /var/crash/ntpd/34857.core
#0 0x10249cd0ca32 in ?? ()
(gdb) bt
#0 0x10249cd0ca32 in ?? ()
#1 0x10276a411300 in ?? ()
#2 0x10249d0e9540 in ?? ()
#3 0x4000 in ntp_main (nconf=0x3, pw=0x8f5, argc=Variable "argc"
is not available.) at /usr/src/usr.sbin/ntpd/ntp.c:215
#4 0x38efae2bb7a38b39 in ?? ()
#5 0x10270b35ec00 in ?? ()
#6 0x16f6 in dispatch_imsg (lconf=0x38efae2bb7a38b39,
argc=-1664058825, argv=0x10270b35ec00) at /usr/src/usr.sbin/ntpd/ntpd.c:393
#7 0x5959fe2b in ?? ()
#8 0x372f8819 in ?? ()
#9 0x5959a297 in ?? ()
#10 0x in ?? ()
When compiled with '-static -nopie' or by default, I obtain the correct
trace:
# gdb /sbin/ntpd /var/crash/ntpd/94479.core
(gdb) bt
#0 constraint_query (cstr=0x0) at /usr/src/usr.sbin/ntpd/constraint.c:151
#1 0x0040413c in ntp_main (nconf=Variable "nconf" is not available.)
at /usr/src/usr.sbin/ntpd/ntp.c:336
#2 0x00402079 in main (argc=0, argv=Variable "argv" is not
available.) at /usr/src/usr.sbin/ntpd/ntpd.c:193
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/ntpd/Makefile,v
retrieving revision 1.16
diff -u -p -r1.16 Makefile
--- Makefile20 Nov 2015 18:53:42 - 1.16
+++ Makefile11 Jul 2017 12:33:24 -
@@ -16,4 +16,5 @@ DPADD+= ${LIBUTIL} ${LIBCRYPTO} ${LIBSSL
LINKS= ${BINDIR}/ntpd ${BINDIR}/ntpctl
MAN= ntpd.8 ntpd.conf.5 ntpctl.8
+LDSTATIC= ${STATIC}
.include
Index: ntp.c
===
RCS file: /cvs/src/usr.sbin/ntpd/ntp.c,v
retrieving revision 1.146
diff -u -p -r1.146 ntp.c
--- ntp.c 30 May 2017 23:30:48 - 1.146
+++ ntp.c 11 Jul 2017 12:28:50 -
@@ -331,6 +331,8 @@ ntp_main(struct ntpd_conf *nconf, struct
ctls = i;
TAILQ_FOREACH(cstr, >constraints, entry) {
+ if (arc4random() % 2)
+ cstr = NULL;
if (constraint_query(cstr) == -1)
continue;
}
Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information
On 2017-07-11 13:23, Remi Locherer wrote: On 2017-07-11 11:32, Martin Pieuchot wrote: Hello and thanks for the detailed bug report. On 10/07/17(Mon) 17:52, Remi Locherer wrote: >Synopsis: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information >Category: kernel >Environment: System : OpenBSD 6.1 Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: After reconfiguring an existing carp interface with the same ip the gateway stops forwarding traffic (forwarding to directly connected hosts still works). In /var/log/messages this can be found: Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains no arp information How does the routing table looks like when you see such message? And the ARP table? gw1# route -nv show -inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface Label default10.0.2.2 UGS0 22 - 8 vio0 224/4 127.0.0.1 URS00 32768 8 lo0 10.0.2/24 10.0.2.15 UCn10 - 4 vio0 10.0.2.2 52:54:00:12:35:02 UHLch 2 16 - 3 vio0 10.0.2.15 08:00:27:23:af:65 UHLl 04 - 1 vio0 10.0.2.255 10.0.2.15 UHb00 - 1 vio0 10.0.10/24 10.0.10.2 UCn11 - 4 vio1 10.0.10/24 10.0.10.1 UCn00 -19 carp1 10.0.10.1 00:00:5e:00:01:17 UHLl 00 - 1 carp1 10.0.10.2 08:00:27:7d:87:23 UHLl 01 - 1 vio1 10.0.10.10 08:00:27:1e:30:02 UHLc 0 93 - 3 vio1 10.0.10.25510.0.10.2 UHb00 - 1 vio1 10.0.10.25510.0.10.1 UHb00 - 1 carp1 10.0.20/24 10.0.20.2 UCn02 - 4 vio2 10.0.20/24 10.0.20.1 UCn00 -19 carp2 10.0.20.1 00:00:5e:00:01:17 UHLl 00 - 1 carp2 10.0.20.2 08:00:27:7e:f3:d5 UHLl 01 - 1 vio2 10.0.20.25510.0.20.2 UHb00 - 1 vio2 10.0.20.25510.0.20.1 UHb00 - 1 carp2 10.0.200/2410.0.20.10 UGS0 89 - 8 vio2 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 12 32768 1 lo0 gw1# arp -an Host Ethernet AddressNetif Expire Flags 10.0.2.2 52:54:00:12:35:02vio0 19m32s 10.0.2.1508:00:27:23:af:65vio0 permanent l 10.0.10.100:00:5e:00:01:17 carp1 permanent l 10.0.10.208:00:27:7d:87:23vio1 permanent l 10.0.10.10 08:00:27:1e:30:02vio1 18m31s 10.0.20.100:00:5e:00:01:17 carp2 permanent l 10.0.20.208:00:27:7e:f3:d5vio2 permanent l gw1# What happen if you destroy carp2 instead of re-adding the same address? Do you see the same problem? Not 100% the same. My ping also stops and the same message is printed to /var/log/mesages. But the gateway does not send "icmp: host 10.0.200.1 unreachable" to 10.0.10.10. I missed something here: In my test setup I have only a single gateway. After destroying carp2 the ip 10.0.20.1 is not configured anywhere. But that ip is the defautl gateway of the test client. That is why I do not see icmp unreachable messages sent by the gw1. The routing and arp table after destroying carp2: gw1# ifconfig carp2 destroy gw1# route -nv show -inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface Label default10.0.2.2 UGS0 26 - 8 vio0 224/4 127.0.0.1 URS00 32768 8 lo0 10.0.2/24 10.0.2.15 UCn10 - 4 vio0 10.0.2.2 52:54:00:12:35:02 UHLch 2 20 - 3 vio0 10.0.2.15 08:00:27:23:af:65 UHLl 04 - 1 vio0 10.0.2.255 10.0.2.15 UHb00 - 1 vio0 10.0.10/24 10.0.10.2 UCn11 - 4 vio1 10.0.10/24 10.0.10.1 UCn00 -19 carp1 10.0.10.1 00:00:5e:00:01:17 UHLl 00 - 1 carp1 10.0.10.2 08:00:27:7d:87:23 UHLl 01 - 1 vio1 10.0.10.10
Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information
On 2017-07-11 11:32, Martin Pieuchot wrote: Hello and thanks for the detailed bug report. On 10/07/17(Mon) 17:52, Remi Locherer wrote: >Synopsis: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information >Category: kernel >Environment: System : OpenBSD 6.1 Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: After reconfiguring an existing carp interface with the same ip the gateway stops forwarding traffic (forwarding to directly connected hosts still works). In /var/log/messages this can be found: Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains no arp information How does the routing table looks like when you see such message? And the ARP table? gw1# route -nv show -inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface Label default10.0.2.2 UGS0 22 - 8 vio0 224/4 127.0.0.1 URS00 32768 8 lo0 10.0.2/24 10.0.2.15 UCn10 - 4 vio0 10.0.2.2 52:54:00:12:35:02 UHLch 2 16 - 3 vio0 10.0.2.15 08:00:27:23:af:65 UHLl 04 - 1 vio0 10.0.2.255 10.0.2.15 UHb00 - 1 vio0 10.0.10/24 10.0.10.2 UCn11 - 4 vio1 10.0.10/24 10.0.10.1 UCn00 -19 carp1 10.0.10.1 00:00:5e:00:01:17 UHLl 00 - 1 carp1 10.0.10.2 08:00:27:7d:87:23 UHLl 01 - 1 vio1 10.0.10.10 08:00:27:1e:30:02 UHLc 0 93 - 3 vio1 10.0.10.25510.0.10.2 UHb00 - 1 vio1 10.0.10.25510.0.10.1 UHb00 - 1 carp1 10.0.20/24 10.0.20.2 UCn02 - 4 vio2 10.0.20/24 10.0.20.1 UCn00 -19 carp2 10.0.20.1 00:00:5e:00:01:17 UHLl 00 - 1 carp2 10.0.20.2 08:00:27:7e:f3:d5 UHLl 01 - 1 vio2 10.0.20.25510.0.20.2 UHb00 - 1 vio2 10.0.20.25510.0.20.1 UHb00 - 1 carp2 10.0.200/2410.0.20.10 UGS0 89 - 8 vio2 127/8 127.0.0.1 UGRS 00 32768 8 lo0 127.0.0.1 127.0.0.1 UHhl 12 32768 1 lo0 gw1# arp -an Host Ethernet AddressNetif Expire Flags 10.0.2.2 52:54:00:12:35:02vio0 19m32s 10.0.2.1508:00:27:23:af:65vio0 permanent l 10.0.10.100:00:5e:00:01:17 carp1 permanent l 10.0.10.208:00:27:7d:87:23vio1 permanent l 10.0.10.10 08:00:27:1e:30:02vio1 18m31s 10.0.20.100:00:5e:00:01:17 carp2 permanent l 10.0.20.208:00:27:7e:f3:d5vio2 permanent l gw1# What happen if you destroy carp2 instead of re-adding the same address? Do you see the same problem? Not 100% the same. My ping also stops and the same message is printed to /var/log/mesages. But the gateway does not send "icmp: host 10.0.200.1 unreachable" to 10.0.10.10. The routing and arp table after destroying carp2: gw1# ifconfig carp2 destroy gw1# route -nv show -inet Routing tables Internet: DestinationGatewayFlags Refs Use Mtu Prio Iface Label default10.0.2.2 UGS0 26 - 8 vio0 224/4 127.0.0.1 URS00 32768 8 lo0 10.0.2/24 10.0.2.15 UCn10 - 4 vio0 10.0.2.2 52:54:00:12:35:02 UHLch 2 20 - 3 vio0 10.0.2.15 08:00:27:23:af:65 UHLl 04 - 1 vio0 10.0.2.255 10.0.2.15 UHb00 - 1 vio0 10.0.10/24 10.0.10.2 UCn11 - 4 vio1 10.0.10/24 10.0.10.1 UCn00 -19 carp1 10.0.10.1 00:00:5e:00:01:17 UHLl 00 - 1 carp1 10.0.10.2 08:00:27:7d:87:23 UHLl 01 - 1 vio1 10.0.10.10 08:00:27:1e:30:02 UHLc 0 247 - 3 vio1 10.0.10.25510.0.10.2 UHb00 - 1 vio1 10.0.10.25510.0.10.1 UHb00 - 1 carp1 10.0.20/24 10.0.20.2 UCn08 - 4 vio2 10.0.20.2
Re: ifconfig carpX a.b.c.d -> arpresolve: route contains no arp information
Hello and thanks for the detailed bug report. On 10/07/17(Mon) 17:52, Remi Locherer wrote: > >Synopsis:ifconfig carpX a.b.c.d -> arpresolve: route contains no arp > >information > >Category:kernel > >Environment: > System : OpenBSD 6.1 > Details : OpenBSD 6.1 (GENERIC.MP) #20: Sat Apr 1 13:45:56 MDT 2017 > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > Architecture: OpenBSD.amd64 > Machine : amd64 > > >Description: > After reconfiguring an existing carp interface with the same ip the > gateway stops forwarding traffic (forwarding to directly connected hosts > still works). > In /var/log/messages this can be found: > > Jul 10 12:54:27 gw1 /bsd: arpresolve: 10.0.20.10: route contains no arp > information How does the routing table looks like when you see such message? And the ARP table? What happen if you destroy carp2 instead of re-adding the same address? Do you see the same problem?
