similar to: Debian DomU with physdev access init kernel crash ....

Hi! Someone asked me in private if I had found a solution to my problem with forwarding in DomUs. [1] In fact I did and I've just filled a new bug report [2] and will try to work it out. Just dropping this here in case someone else is interested. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571634#10 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592780 -- Sebasti?n Cruz

tags 571634 +fixed-upstream thanks A fix was committed to xen-unstable: http://xenbits.xensource.com/xen-unstable.hg?rev/b0fe8260cefa Anders

When using v2 we would modify the saved /var/lib/shorewall/restore file to modify logging so we had separate counts by the physical device the packets (actually, NEW connections, not total packet counts), such as: -A LogStuff -j LOG etc -A LogStuff -m physdev --physdev-in eth1 -j DROP -A LogStuff -m physdev --physdev-in eth2 -j DROP which gave us an idea where dropped traffic cam from

Package: xen-utils-common Version: 3.4.2-3 Followup-For: Bug #571634 I can confirm that this bug not only exists in the current version but that it makes a DomU which forwards packets unusable. Other "simpler" DomUs which do not forward work perfectly. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (1000, 'stable'), (100, 'testing')

Package: xen-utils-common Version: 3.4.2-3 --- Please enter the report below this line. --- After several tests and many hours of investigation I found out that this is not a bug. The iptables rules that triggers the message is found in /etc/xen/scripts/vif-common.sh [1], but as the syslog message clearly indicates this rule works perfectly when the traffic is bridged. Moreover, those rules are

https://bugzilla.netfilter.org/show_bug.cgi?id=1143 Bug ID: 1143 Summary: physdev extension not working Product: iptables Version: 1.4.x Hardware: x86_64 OS: Debian GNU/Linux Status: NEW Severity: normal Priority: P5 Component: iptables Assignee: netfilter-buglog at

Package: xen-utils-common Version: 3.4.2-2 Severity: important The network setup uses not longer supported iptables operations: | physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic is not supported anymore. -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate

Hi, I''m running RH9 Linux and I''m having a slight problem with shorewall, i originally set it up as a two card configuration, but i have now bridged the connections in an attempt to get my WiFi network communicating with the wired network (eth0 and wlan0). I have followed the instructions for bridging from http://www.shorewall.net/bridge.html but when I activate shorewall i get

Hello, i''m using the latest Xen 4.0 testing from the mercurial repository and i want to passthrough my Intel Core gpu. But somehow it has a weird IRQ of 1251. So i cant start the vm if i set pci=[''00:02.0'']. The device is bound to the pciback driver correctly. The interesting part of xm dmesg (appears when i start the vm): (XEN) [VT-D]iommu.c:1484: d0:PCI: unmap bdf =

Hello, i''m using the latest Xen 4.0 testing from the mercurial repository and i want to passthrough my Intel Core gpu. But somehow it has a weird IRQ of 1251. So i cant start the vm if i set pci=[''00:02.0'']. The device is bound to the pciback driver correctly. The interesting part of xm dmesg (appears when i start the vm): (XEN) [VT-D]iommu.c:1484: d0:PCI: unmap bdf =

I recently encountered this in the logs of a new Debian Xen Dom0, and having now spent the better part of a day researching and testing, I've come to the conclusion that this is not a bug in xen-utils-common or even iptables; it's merely the consequence of structural changes to the core netfilter code starting in the 2.6.20 kernel. This is rather long, but the issue is complicated. Please

Currently using physdev on a bridge to try and isolate certain paths across and to the bridge. It all works except when trying to stop the flow in one direction on the FORWARD chain?? Can someone please help?? Below is the testing done so far. eth1 <---> BRIDGE <---> eth0 # Block (eth0 ---> eth1) - blocks both directions and not just one?? iptables -A FORWARD -m physdev