Hi, I went through my configuration with a fine comb, comparing it with a multitude of setups one can easily find on the net - and with the fine manuals, of course. I could not find anything apparently wrong. For the sake of the test I added another DOMU, this time 64 bit, with the same results - the DOMUs communicate fine with the DOM0 and between themselves, but they see only arp traffic from the rest of the wireless network (and the rest of the network also can see their arp requests).
Today it came to me that it might be a peculiarity of the wireless router ( a Virgin SuperHub 3 ) or with the driver wireless interface - iwn - so I switched to wired interface (wm), connected to the same SuperHub 3. The guest networking through the bridge now works as expected, but I am none the wiser as to where the problem is with the wireless interface (I'd rather keep it wireless, don't like CAT5 cables across the room...). One weird peculiarity of the iwn interface on this laptop is that - while it is kept running all the time and (almost) never loses network connection, the other hosts lose connection to it after they are restarted or came from sleep, the only way of restoring the connection from them to the NetBSD machine is to do a ping from the NetBSD machine to the others... Go figure. The (almost) above refers to the occasional firmware error this interface gives, perhaps once a week, which is resolved by downing and upping it. So the question (finally) is: should we expect bridging to work when using a wireless device (especially a iwn driver). Chavdar Ivanov On Mon, 31 Jul 2017 at 11:47 Chavdar Ivanov <[email protected]> wrote: > One more hang shutting down the DOMU, happens with 'xl shutdown foo' in > the DOMU console: > > --- > foo# xenbus_shutdown_handler: xenbus_rm 13 > > *** FINAL System shutdown message from root@foo *** > System going down IMMEDIATELY > > power button pressed > > Jul 31 10:43:13 foo shutdown: poweroff by root: power button pressed > Jul 31 10:43:21 foo syslogd[189]: Exiting on signal 15 > syncing disks... done > xenbus: can't get state for device/suspend/event-channel (2) > ➜ xci > ---- > > From this moment onward the system responds to ping and the CR is echoed, > but that is all. Only hard reset clears it. > > On Mon, 31 Jul 2017 at 09:28 Chavdar Ivanov <[email protected]> wrote: > >> Hi, >> >> After I managed - with the help of few - to get my old Thinkpad T61p to >> work fine under -current (with two separate downgrades) I decided - >> following a recent discussion about hypervisors here - to try again Xen >> with NetBDSD-current amd64 as DOM0, largely following the Howto document >> (which is in need of an update - at least to mention that Xen48 is now in >> pkgsrc). Apart from a few minor problems (i.e. incorrect placement of the >> ocaml output files in the work tree during compilation, I just copied them >> where they were expected) all went as expected. I am running now a >> NetBSD-i386 DOMU which is able to communicate with the DOM0, but for the >> helll of it I can't figure out how to configure the bridge to pass IP >> traffic. Bridge(4) says: >> ... >> Transparent filtering for IP and IPv6 packets can be added with the >> kernel configuration option options BRIDGE_IPF. >> >> When filtering is enabled, bridged packets will pass through the filter >> inbound on the originating interface and outbound on the appropriate >> interfaces. ARP and REVARP packets are forwarded without being filtered >> and others that are not IP nor IPv6 packets are not forwarded when >> filtering is enabled. >> --- >> >> So with the original netbsd-XEN3PAE_DOMU kernel I can see ARP traffic >> coming and going (i.e. when an external host tries to ping the DOMU I cn >> see the arp packet coming into the DOMU, when the DOMU tries to ping an >> external host I can see its arp packet on that host interface - with >> tcpdump). As I said earlier, the networking between the DOM0 and DOMU works >> fine. Then I modified the XEN3PAE kernel to include BRIDGE_IPF and also the >> options for pf - but I could not get any third party packets to or from the >> DOMU. >> >> The ifconfig.bridge0 is as follows: >> >> create >> up >> !brconfig bridge0 add iwn0 >> >> I don't know if it is significant that the interface in this case is >> wireless. >> >> Besides that, I got one panic apparently ACPI related of the DOM0: >> >> --- >> crash crash -M netbsd.1.core -N netbsd.1 >> Crash version 8.99.1, image version 8.99.1. >> System panicked: trap >> Backtrace from time of crash is available. >> crash> bt >> _KERNEL_OPT_NARCNET() at 0 >> _KERNEL_OPT_ACPI_SCANPCI() at _KERNEL_OPT_ACPI_SCANPCI+0x5 >> vpanic() at vpanic+0x149 >> snprintf() at snprintf >> trap() at trap+0xc6b >> --- trap (number 6) --- >> ahci_intr_port() at ahci_intr_port+0x1e >> ahci_intr() at ahci_intr+0xa5 >> intr_biglock_wrapper() at intr_biglock_wrapper+0x1d >> Xintr_ioapic_level3() at Xintr_ioapic_level3+0xf2 >> --- interrupt --- >> x86_mwait() at x86_mwait+0xd >> acpicpu_cstate_idle_enter() at acpicpu_cstate_idle_enter+0xdb >> acpicpu_cstate_idle() at acpicpu_cstate_idle+0xb6 >> idle_loop() at idle_loop+0x18c >> ---- >> There are a lot of ACPI error messages in the DOM0 dmesg, so I wasn't too >> bothered with it, and it happened only once, I have since been able to do a >> full sysbuild under the DOM0 kernel). There were also a couple of hangs of >> the DOM0, apparently taking place when the DOMU is being shut down or >> poweroff-ed, resulting in a system responding to pings, but otherwise >> unable to do anything - just echoing the CR (I've interrupted this and took >> a screenshot of the trace here - http://bit.ly/2tVxnvX ). >> >> Any ideas? >> >> Chavdar Ivanov >> >> (I don't know if current-users is the best list to post this, but as both >> domains are >> >> NetBSD nt61p 8.99.1 NetBSD 8.99.1 (MYXEN) #0: Sun Jul 30 23:46:27 UTC >> 2017 root@nt61p:/usr/src/sys/arch/amd64/compile/MYXEN amd64 >> >> and >> >> NetBSD foo 8.99.1 NetBSD 8.99.1 (XEN3PAE_DOMU) #1: Tue Jul 25 17:56:26 >> UTC 2017 >> sysbuild@nt61p:/home/sysbuild/i386/obj/home/sysbuild/src/sys/arch/i386/compile/XEN3PAE_DOMU >> i386 >> >> it probably is). >> >>
