similar to: Bug#571634: bridge loosing connection

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

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

Hi, I have a Centos5 machine running xen 3.0.3-41 with two NICs each on its own subnet: 192.168.1.x and 192.168.0.x. All DomUs can talk to each other OK through two xen bridges. There are 3 DomUs: Dom0, Dom1 and Dom2 The scenario: I''m trying to capture packets on Dom2 on 192.168.0.x from external devices that are sending SIP stuff to Dom1, but fail to capture any packets. I

I built a CentOS 6 machine to host several CentOS 6 guest servers. As all guests will be Internet facing I set up the host with two bridged NICs and assigned an Internet facing IP address to br0 and a local IP address to br1. Each guest was installed using br0 and br1 with virtio drivers. On each I assigned an Internet facing IP address to eth0 and a local IP address on eth1. So far so good. I

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=570 kaber@trash.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID ------- Additional Comments From kaber@trash.net 2007-05-26

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

Package: xen-utils-common Version: 4.8.3+comet2+shim4.10.0+comet3-1+deb9u5 Severity: important Tags: patch security -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-6-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),

Problem still not solved, or any idea whats wrong. here are some msgs: device vif1.0 entered promiscuous mode alloc irq_desc for 1246 on node 0 alloc kstat_irqs on node 0 brI: port 2(vif1.0) entering learning state device vif1.1 entered promiscuous mode brE: port 2(vif1.1) entering learning state physdev match: using --physdev-out in the OUTPUT, FORWARD and POSTROUTING chains for

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 folks, in 2.4 kernels, device matching for bridged packets was done with iptables -i/-o. Since 2.6, I was used to use -m physdev here. In 2.6.18, This seems to be more complicated. At least the filter/INPUT chain now doesn't match with -m physdev --physdev-in anymore, but FORWARD and OUTPUT does. I also read the note that -m phydev is now deprecated for non-bridged traffic. Does this

Hello list, I''m using xen2.6 with a 2.6.11 kernel my config: kernel = "/boot/vmlinuz-2.6.11-xenU" memory = 1280 name = "s51" nics=1 vif = [ ''ip=82.149.232.51,mac=00:E0:81:29:71:3D'' ] disk = [ ''file:/home/xen/51/diskimage,sda1,w'', ''file:/home/xen/51/swapimage,sda2,w'',

Hi, I''ve been making leaps and strides with Xen on FC4. It has been easy to get installed and to start our first virtual host. I''ve got one outstanding issue with iptables that is preventing me progressing further. This is a colo''d server. It has s single NIC with public IPs. The bridge is set to come up binding vif* <> xen-br0 <> eth1. I can start a

Hi all! After upgrading to Squeeze, I am watching a Xen VMHost that after a while it hangs. This did not happen when I was using Xen with Debian Lenny (in this case as with Squeeze, the Xen components are from Debian repositories). In each case I connected a keyboard and monitor to the computer and the screen remained black without answering any key. This problem seems to also affect domUs,

Hi, i have problems with the network between pv-domains and the real network. I done an upgrade with apt-get in debian an now i have xen4.1 with kernel 3.2.9 first i must chance the vif-bridge script from http://nopaste.php-q.net/194087 to http://nopaste.php-q.net/194084 now i have a connection from pv to dom0 and the windows hvm, but no connection between physical network an the pv

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

Hi, I have a suspicious problem with multiple uplinks configuration. First of all my configuration: 1) kernel 2.6.20.3 2) iptables 1.3.7 3) last iproute (for masked marks) All wan interfaces are bridged (stp disabled) in only one interface (wan0), all lan interfaces are bridged (stp enabled) in only one interface (zlan0). The wan0 bridge is to allow UPnP works. To allow related

On Sat, Jan 05, 2013 at 02:18:46PM -0500, Nickolai Zeldovich wrote: > xen_add_device() in drivers/xen/pci.c allocates a struct > physdev_pci_device_add on the stack and then writes to optarr[0]. > The previous declaration of struct physdev_pci_device_add contained > a zero-length optarr[] array, presumably assuming it will be allocated > with kmalloc with a suitable number of

On Sat, Jan 05, 2013 at 02:18:46PM -0500, Nickolai Zeldovich wrote: > xen_add_device() in drivers/xen/pci.c allocates a struct > physdev_pci_device_add on the stack and then writes to optarr[0]. > The previous declaration of struct physdev_pci_device_add contained > a zero-length optarr[] array, presumably assuming it will be allocated > with kmalloc with a suitable number of

Trying to use the policy drop rule with the bridged firewall, when I removed the first line the transparent proxy works great? It seems a bit strange as from reading several articles on it I thought the following occurs. 1st line - if it doest match it gets dropped on the local filter input. 2nd line - redirects the traffic off the link layer into the network layer ready for line 3. 3rd line -