similar to: Bug#571634: xen-utils-common - using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for non-bridged traffic

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! 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

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

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

retitle 571634 xen-utils-common vif-common.sh still using --physdev-out, --state found 571634 4.0.0-1 thanks Hi, That link to upstream patch in the last message is apparently broken, a working one is: http://xenbits.xen.org/hg/xen-unstable.hg/rev/b0fe8260cefa but also more importantly for the current stable package: http://xenbits.xen.org/hg/xen-4.0-testing.hg/rev/af7110f4f803 Because the

Package: xen-utils-common Version: 4.0.0-1 Hello guys, Ik running Debian stable (squeeze). This appeared in the messages when i started and stopped a DomU: root at dom0:~# cat messages Aug 31 22:04:52 dom0 kernel: [ 775.569937] device vif6.0 entered promiscuous mode Aug 31 22:04:52 dom0 kernel: [ 775.575993] br_lan: port 2(vif6.0) entering forwarding state Aug 31 22:04:52 dom0 kernel: [

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

Hi, I'm not sure but I think I suffer under the same problem with a bit different setup with squeeze testing and xen 4.0rc5. In fact I'm using bridges in the dom0 and the connections to the domU get lost sporadically. In don't see where's a solution to the problem... Is it now a bug? When it's an iptables bug, where's the corresponding bug in the iptables bugtracker

Package: xen-utils-common Version: 3.0.3-0-2 Severity: normal I'm not an expert in networking but I think that the current setup when using network-nat for domains is insecure. I've configured : (network-script 'network-nat netdev=eth1') (vif-script vif-nat) So when only domain 0 is started, I get the following : # iptables -L -n Chain INPUT (policy ACCEPT) target prot

Here is a patch to the Debian xen-3 3.4.0-1 package that reenables ioemu. I have been using it for the last four weeks. (I understand there are reasons this cannot go into Debian yet, but hopefully it will be useful to people that depend on running HVMs today.) Anders -------------- next part -------------- --- xen-3/debian/changelog +++ xen-3/debian/changelog @@ -1,3 +1,10 @@ +xen-3

Processing commands for control at bugs.debian.org: > forcemerge 571634 639942 Bug #571634 [xen-utils-common] xen-utils-common vif-common.sh still using --physdev-out, --state Bug #639942 [xen-utils-common] Xen "non-bridged traffic is not supported anymore" with bridges Severity set to 'serious' from 'normal' Marked as found in versions xen-common/3.4.2-2 and

Processing commands for control at bugs.debian.org: > fixed 571634 4.1.0~rc6-1 Bug #571634 {Done: Bastian Blank <waldi at debian.org>} [xen-utils-common] xen-utils-common vif-common.sh still using --physdev-out, --state Bug #639942 {Done: Bastian Blank <waldi at debian.org>} [xen-utils-common] Xen "non-bridged traffic is not supported anymore" with bridges Marked as fixed

Packets going to a 2.6 kernel IPSEC tunnel do not seem to pass the POSTROUTING chain. Is that correct? R. -- ___________________________________________________________________ It''s so simple to be wise. Just think of something stupid to say and say the opposite. +------------------------------------------------------------------+ | Richard Lucassen, Utrecht

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

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.0.3-0-2 Severity: normal I cannot find a use the network-nat and vif-nat provided in the general case, where I'd like to NAT between vifx.0 and ethx interfaces. I have setup the following in /etc/xen/xend-config.sxp : ## Use the following if network traffic is routed with NAT, as an alternative # to the settings for bridged networking given above.

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

Hi Folks, I saw some references to the same problem in mailing list but no solution. I am running a DomU with PHYSDEV access. With fedora core 4, I just changed the inittab file to not start getty''s on tty1-6, and it worked (only ttyS0 is enabled). However, same trick didn''t do it for debian. I can boot into a shell if I put init=/bin/bash on kernel command line. However,

Hi Folks, I saw some references to the same problem in mailing list but no solution. I am running a DomU with PHYSDEV access. With fedora core 4, I just changed the inittab file to not start getty''s on tty1-6, and it worked (only ttyS0 is enabled). However, same trick didn''t do it for debian. I can boot into a shell if I put init=/bin/bash on kernel command line. However,