Launchpad has imported 25 comments from the remote bug at
https://bugzilla.redhat.com/show_bug.cgi?id=657918.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2010-11-28T17:45:17+00:00 Arnaud wrote:
Description of problem:
Starting libvirtd with its default configuration creates a bridge
interface virbr0 with IP 192.168.122.1. It also adds iptables rules to
the nat table to allow VMs connected to this bridge to access the
external network. These rules catch any incoming packet whose
destination is not on the 192.168.122.0/24 subnet, even multicast
packets.
As a result, the host sees mDNS datagrams from its guests coming from
its own IP address with a (more or less) random source port, whereas
avahi expects them to come from port 5353.
The obvious workaround (add a static nat rule like "iptables -t nat -A
POSTROUTING -d 224.0.0.0/4 -j RETURN" to /etc/sysconfig/iptables) does
not work, as libvirt inserts its rules before the existing ones.
Version-Release number of selected component (if applicable):
libvirt-0.8.2-1.fc13.x86_64
How reproducible:
Always.
Steps to Reproduce:
1. service libvirtd start
2. virsh start myguest
(here myguest is a guest VM with avahi-daemon enabled)
3. getent hosts myguest.local
Actual results:
The last command times out. Here is the relevant line from
/var/log/messages:
Nov 28 12:11:51 carrosse avahi-daemon[22764]: Received response from
host 192.168.122.1 with invalid source port 1025 on interface 'virbr0.0'
Expected results:
% getent hosts myguest.local
192.168.122.157 myguest.local
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/14
------------------------------------------------------------------------
On 2011-05-17T15:50:45+00:00 Frank wrote:
If one's willing to use hand-written iptables to accomplish NAT,
is there a way of making libvirtd not try running iptables at all?
I don't see documentation for the /etc/libvirt/libvirtd.conf file,
should that hold the magic door.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/16
------------------------------------------------------------------------
On 2011-05-30T13:21:57+00:00 Bug wrote:
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '13'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 13's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 13 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/17
------------------------------------------------------------------------
On 2011-06-10T17:59:55+00:00 Cole wrote:
Sounds like this is something libvirt could handle itself? Moving to
rawhide
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/18
------------------------------------------------------------------------
On 2011-09-22T17:50:52+00:00 Fedora wrote:
This package has changed ownership in the Fedora Package Database.
Reassigning to the new owner of this component.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/19
------------------------------------------------------------------------
On 2011-09-22T17:53:26+00:00 Fedora wrote:
This package has changed ownership in the Fedora Package Database.
Reassigning to the new owner of this component.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/20
------------------------------------------------------------------------
On 2011-09-22T17:58:59+00:00 Fedora wrote:
This package has changed ownership in the Fedora Package Database.
Reassigning to the new owner of this component.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/21
------------------------------------------------------------------------
On 2011-11-30T19:31:38+00:00 Fedora wrote:
This package has changed ownership in the Fedora Package Database.
Reassigning to the new owner of this component.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/22
------------------------------------------------------------------------
On 2011-11-30T19:35:02+00:00 Fedora wrote:
This package has changed ownership in the Fedora Package Database.
Reassigning to the new owner of this component.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/23
------------------------------------------------------------------------
On 2011-11-30T19:41:53+00:00 Fedora wrote:
This package has changed ownership in the Fedora Package Database.
Reassigning to the new owner of this component.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/24
------------------------------------------------------------------------
On 2011-11-30T19:53:13+00:00 Fedora wrote:
This package has changed ownership in the Fedora Package Database.
Reassigning to the new owner of this component.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/25
------------------------------------------------------------------------
On 2011-12-01T23:39:10+00:00 Eric wrote:
Stefan Berger has been working on related code in the nwfilter
components, with several improvements for 0.9.8. I have no idea if
those improvements meet your need, or if there is still more to go to
the point that you want; I suggest bringing this topic up on libvir-
***@redhat.com (Stefan is more likely to see this on-list than by
finding this BZ).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/26
------------------------------------------------------------------------
On 2011-12-02T02:46:08+00:00 Stefan wrote:
With nwfilter we may be able to prevent a VM from sending multicast
traffic, but cannot influence what happens to it in case of NATing.
We could add the above mentioned rule
iptables -t nat -A POSTROUTING -d 224.0.0.0/4 -j RETURN
via utils/iptables.c to the list of 3 rules that libvirt automatically
creates in the iptables nat POSTROUTING chain.
HOWEVER:
Typically the multicast traffic would have to go onto the wire to get as many responses as possible. In this case I don't see it going onto the wire at all. I see them on the VM's tap interface but not on the physical interface anymore and while pinging from the VM into the network works and shows a counter increase on the respective masquerading rule I don't see any counter increase for the above rule if it is first in the list of rules. Some logic maybe already discards multicast traffic from entering the iptables NAT table? Adding the rule there at least doesn't make sense considering what I am seeing.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/27
------------------------------------------------------------------------
On 2011-12-02T15:26:38+00:00 Arnaud wrote:
For my use case, mDNS is link-local anyway, so if the host acts as a
router, the guest won't get to talk with the outside world and it is
perfectly fine. OTOH the host should definitely get to see mDNS
announcements from the guest.
Note multicast routing is quite complicated anyway (needs dedicated
protocols, on a LAN this probably means PIM), so I wouldn't expect it to
work out of the box with a Linux host as a router.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/28
------------------------------------------------------------------------
On 2011-12-05T01:12:26+00:00 Stefan wrote:
Following my observations in comment 12 of the above iptables rule
applied to the NAT table, I don't think that any changes are required to
the iptables setup to the host's NAT table. However, I cannot confirm
that an application running on the host gets the packets, but for sure I
did not see them going on the wire in this network setup.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/29
------------------------------------------------------------------------
On 2011-12-08T10:13:46+00:00 Arnaud wrote:
As I wrote earlier, the issue is that the packets get rewritten even if
they are destined to the host, so the host sees them coming from the
wrong UDP port (mDNS relies on source port).
I guess my point is the iptables setup should be configurable, not
hardcoded in libvirt.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/30
------------------------------------------------------------------------
On 2011-12-08T13:21:25+00:00 Stefan wrote:
I had done the following test:
iptables -t nat -I POSTROUTING 1 -d 224.0.0.0/4 -s 129.168.122.0/24 -j
ACCEPT
This adds a rule that presumably intercepts all multicast traffic from
VMs and simply accepts it.
A VM is started and receives the IP address 192.168.122.239, which is in
the above source subnet 129.168.122.0/24.
This VM now starts pinging for example 8.8.8.8.
iptables -t nat -L POSTROUTING -n -v
Chain POSTROUTING (policy ACCEPT 64 packets, 4057 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * * 129.168.122.0/24 224.0.0.0/4
0 0 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
0 0 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
1 84 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24
Above shows a counter of '1' indicating the masquerading of the ICMP
traffic. Stopping and restarting the ping puts the counter to '2'. (due
to connection tracking the rule is only needed once per ICMP stream)
I started a 'tcpdump -i vnet0 -n' to monitor traffic from that VM.
Inside the VM I did
service avahi-daemon restart
which then shows a flood of multicast messages on vnet0. One would think
that that traffic now gets 'ACCEPT'ed due to the 1st rule above, but
this is not the case. The output of
iptables -t nat -L POSTROUTING -n -v
still shows the same as above -- no counter change in the 1st ryule. The kernel was 2.6.35.14-97.fc14.x86_64.
Changing above first rule to '-j MASQUERADE' or '-j RETURN' doesn't change a anything. The counter remains on '0'.
My conclusion is that adding a rule here (for this kernel version at
least) for multicast traffic makes no sense since it doesn't get
invoked. Also see comment 12.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/31
------------------------------------------------------------------------
On 2012-06-07T14:06:15+00:00 Cole wrote:
Moving this to the upstream tracker, since there's been some discussion
and it's not really fedora specific (or a high impact bug)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/35
------------------------------------------------------------------------
On 2012-12-11T18:06:07+00:00 Brian wrote:
What is the upstream tracker so that we can follow that?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/37
------------------------------------------------------------------------
On 2012-12-11T19:56:07+00:00 Dave wrote:
(In reply to comment #18)
What is the upstream tracker so that we can follow that?
This BZ is the upstream tracker; Cole is just pointing out that he
changed the Product field from Fedora to 'Virtualization Tools'.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/38
------------------------------------------------------------------------
On 2012-12-11T20:03:36+00:00 Brian wrote:
(In reply to comment #19)
This BZ is the upstream tracker; Cole is just pointing out that he changed
the Product field from Fedora to 'Virtualization Tools'.
Ahhh. Got it.
Any action on this item? It seems like pretty low hanging fruit. I
think I even had a libvirt that had a hack in place to do this, since I
am seeing this issue resurfacing after upgrading to FC18.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/39
------------------------------------------------------------------------
On 2012-12-11T20:07:11+00:00 Brian wrote:
(In reply to comment #16)
iptables -t nat -I POSTROUTING 1 -d 224.0.0.0/4 -s 129.168.122.0/24 -j ACCEPT
Surely you wanted to do s/129/192/ didn't you?
iptables -t nat -L POSTROUTING -n -v
Chain POSTROUTING (policy ACCEPT 64 packets, 4057 bytes)
pkts bytes target prot opt in out source
destination
0 0 ACCEPT all -- * * 129.168.122.0/24 224.0.0.0/4
0 0 MASQUERADE tcp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
0 0 MASQUERADE udp -- * * 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
1 84 MASQUERADE all -- * * 192.168.122.0/24 !192.168.122.0/24
...
My conclusion is that adding a rule here (for this kernel version at least)
for multicast traffic makes no sense since it doesn't get invoked. Also see
comment 12.
It probably would if the address in the rule were correct. It works
here.
It should be noted that you probably want to add 226.0.0.0/8 to your
ACCEPT list.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/40
------------------------------------------------------------------------
On 2012-12-11T22:12:59+00:00 Brian wrote:
Created attachment 661710
Exempt multicast networks (224.0.0.0/4) from NATting
How about this patch? It compiles here and has worked in previous
versions of libvirt. I don't have occasion to test it right at this
moment (to much other work with VMs still in progress) but I'm fairly
confident that it should still work.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/41
------------------------------------------------------------------------
On 2012-12-11T22:28:57+00:00 Eric wrote:
Can you please also post this patch upstream to libvir-***@redhat.com?
You'll get a faster review, as not all list readers pay attention to BZ
attachments.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/42
------------------------------------------------------------------------
On 2016-03-22T22:55:37+00:00 Cole wrote:
I think this was eventually fixed by:
commit 51e184e9821c3740ac9b52055860d683f27b0ab6
Author: Laszlo Ersek <***@redhat.com>
Date: Wed Sep 25 12:45:26 2013 +0200
bridge driver: don't masquerade local subnet broadcast/multicast
packets
Reply at:
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/447442/comments/49
** Changed in: libvirt
Status: Unknown => Fix Released
** Changed in: libvirt
Importance: Unknown => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/447442
Title:
avahi-daemon reports "Received response with invalid source port # on
interface 'eth0.0'" all the time
To manage notifications about this bug go to:
https://bugs.launchpad.net/libvirt/+bug/447442/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-***@lists.ubuntu.com