Xen networking problems in -current with xn driver?

[Julian Elischer]

I upgraded my VPS machine to today's current, and on reboot I couldn't
get into it by network.

A quick switch to the VNC console showed that it was up but that it
couldn't get out.


The xn interfaces said they were UP but attempts to get out were met
with "network is down".

if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again.

tcpdump saw packets, and in fact ipfw saw some packets coming in even
before that but it was not possible to send.


Has anyone seen similar?

some relevant parts of the dmesg output.:


T(vga): text 80x25
XEN: Hypervisor version 3.4 detected.
CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz
686-class CPU)
Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2
Features=0x1781fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT>
Features2=0x80982201<SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,HV>
AMD Features=0x20100000<NX,LM>
AMD Features2=0x1<LAHF>
Hypervisor: Origin = "XenVMMXenVMM"
real memory = 536870912 (512 MB)
avail memory = 503783424 (480 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <Xen HVM>
WARNING: L1 data cache covers less APIC IDs than a core
0 < 1
WARNING: L2 data cache covers less APIC IDs than a core
0 < 1
WARNING: L3 data cache covers less APIC IDs than a core
0 < 1

ipfw2 (+ipv6) initialized, divert loadable, nat enabled, default to
deny, logging disabled
xs_dev0: <Xenstore user-space device> on xenstore0
xenbusb_front0: <Xen Frontend Devices> on xenstore0
xn0: <Virtual Network Interface> at device/vif/0 on xenbusb_front0
xn0: Ethernet address: 00:16:3e:01:99:54
xn1: <Virtual Network Interface> at device/vif/1 on xenbusb_front0
xn1: Ethernet address: 00:16:3e:01:9a:54
xenbusb_back0: <Xen Backend Devices> on xenstore0
xenballoon0: <Xen Balloon Device> on xenstore0
xctrl0: <Xen Control Device> on xenstore0
xn0: backend features: feature-sg feature-gso-tcp4
xn1: backend features: feature-sg feature-gso-tcp4
xbd0: 20480MB <Virtual Block Device> at device/vbd/768 on xenbusb_front0
xbd0: attaching as ada0
xbd0: features: write_barrier
xbd0: synchronize cache commands enabled.

_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Kevin Oberman]

On Tue, Aug 2, 2016 at 11:12 AM, Julian Elischer <jul...@freebsd.org> wrote:

> I upgraded my VPS machine to today's current, and on reboot I couldn't get
> into it by network.
>
> A quick switch to the VNC console showed that it was up but that it
> couldn't get out.
>
>
> The xn interfaces said they were UP but attempts to get out were met with
> "network is down".
>
> if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again.
>
> tcpdump saw packets, and in fact ipfw saw some packets coming in even
> before that but it was not possible to send.
>
>
> Has anyone seen similar?
>
> some relevant parts of the dmesg output.:
>

> [...]

A bit of a guess, but the obvious thing that I see is that when you start
tcpdump you are placing the interface in promiscuous mode. Looks like the
"device" fails to properly see packet addressed to it.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkob...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

[Roger Pau Monné]

On Wed, Aug 03, 2016 at 02:12:33AM +0800, Julian Elischer wrote:
> I upgraded my VPS machine to today's current, and on reboot I couldn't get
> into it by network.
>
> A quick switch to the VNC console showed that it was up but that it couldn't
> get out.
>
>
> The xn interfaces said they were UP but attempts to get out were met with
> "network is down".
>
> if I did 'tcpdump -n -i xn0' (and xn1) hten all was fine again.
>
> tcpdump saw packets, and in fact ipfw saw some packets coming in even before
> that but it was not possible to send.
>
>
> Has anyone seen similar?

Hello,

I've tested current less than one week ago and didn't find any issues, I'm
currently updating to see if it's something that has been introduced in the
last few days. There have also been reports of it working fine on the
freebsd-xen mailing list, but I guess there's something different with your
setup:

https://lists.freebsd.org/pipermail/freebsd-xen/2016-July/002779.html

> some relevant parts of the dmesg output.:
>
>

> T(vga): text 80x25
> XEN: Hypervisor version 3.4 detected.
> CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2400.05-MHz 686-class
> CPU)
> Origin="GenuineIntel" Id=0x206c2 Family=0x6 Model=0x2c Stepping=2
> Features=0x1781fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT>
> Features2=0x80982201<SSE3,SSSE3,CX16,SSE4.1,SSE4.2,POPCNT,HV>
> AMD Features=0x20100000<NX,LM>
> AMD Features2=0x1<LAHF>
> Hypervisor: Origin = "XenVMMXenVMM"
> real memory = 536870912 (512 MB)
> avail memory = 503783424 (480 MB)
> Event timer "LAPIC" quality 400
> ACPI APIC Table: <Xen HVM>
> WARNING: L1 data cache covers less APIC IDs than a core
> 0 < 1
> WARNING: L2 data cache covers less APIC IDs than a core
> 0 < 1
> WARNING: L3 data cache covers less APIC IDs than a core
> 0 < 1
>
> ipfw2 (+ipv6) initialized, divert loadable, nat enabled, default to deny,

You seem to be using ipfw, I guess you have firewall_enable="YES" on you
rc.conf, are you also using IPv6? Anything else net related on your rc.conf?

Roger.

[Roger Pau Monné]

FWIW, I've added:

firewall_enable="YES"
firewall_type="open"

To my rc.conf and I'm still not able to reproduce, this is all with IPv4.