Yes, it looks the same. Although somehow for the last couple of days it stays on I don't have to ping anything from the laptop out (and it is indeed that one has to ping the machine one wants to ssh from - the Internet connection of the laptop with iwn appears to be working.
(the '? xci' seen is just the next prompt after the DOMU shutdown I was refering to). Chavdar On Mon, 21 Aug 2017 at 11:32 Patrick Welche <[email protected]> wrote: > Possibly an instance of PR kern/52106 ? > > On Sat, Aug 19, 2017 at 12:45:02PM +0000, Chavdar Ivanov wrote: > > 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). > > >> > > >> >
