Re: [libvirt] --checksum-fill error on Ubuntu 10.04
caused by network filter driver depends on the newer iptables, there is no "--checksum-fill" option indeed in older iptables. The following commit log is from iptables git. commit 9d1b11102b53103c00b7fddf4658a4d2bdee1338 Author: Michael S. Tsirkin <mst@redhat.com> Date: Thu Jul 15 17:23:24 2010 +0200 extensions: libxt_CHECKSUM extension This adds a `CHECKSUM' target, which can be used in the iptables mangle table. You can use this target to compute and fill in the checksum in a packet that lacks a checksum. This is particularly useful, if you need to work around old applications such as dhcp clients, that do not work well with checksum offloads, but don't want to disable checksum offload in your device. The problem happens in the field with virtualized applications. For reference, see Red Hat bz 605555, as well as http://www.spinics.net/lists/kvm/msg37660.html Typical expected use (helps old dhclient binary running in a VM): iptables -A POSTROUTING -t mangle -p udp --dport bootpc \ -j CHECKSUM --checksum-fill Includes fixes by Jan Engelhardt <jengelh@medozas.de> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Patrick McHardy <kaber@trash.net> Even on my FC13, it's without "CHECKSUM" support, the build date is 'Thu 08 Apr 2010 06:30:45 PM CST', :-) Could we treat the error message as warnings? or make it only works for newer iptables? - Osier ----- "Justin Clift" <jclift@redhat.com> wrote:
Hi us,
Just noticed an error message when manually starting libvirtd (built from git) on Ubuntu 10.04, while checking something else:
iptables v1.4.4: unknown option `--checksum-fill'
It shows up in the initial default network setup:
10:40:19.807: error : virRunWithHook:855 : internal error '/sbin/iptables --table mangle --insert POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' exited with non-zero status 2 and signal 0: iptables v1.4.4: unknown option `--checksum-fill' Try `iptables -h' or 'iptables --help' for more information.
Just a FYI, in case someone wants to look into it.
Regards and best wishes,
Justin Clift
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 10/26/2010 01:41 PM, Osier wrote: <snip>
Could we treat the error message as warnings? or make it only works for newer iptables?
Yeah, the "error" message that we generate is a bit misleading, since Laine says it's effectively not stopping things from working. If you know how to easily fix the code so it classifies this as a warning, then I reckon "go for it". :)
On 10/26/2010 09:04 PM, Justin Clift wrote:
On 10/26/2010 01:41 PM, Osier wrote: <snip>
Could we treat the error message as warnings? or make it only works for newer iptables?
The only method to determine if --checksum-fill is in iptables or not is to execute the command, and if it's not there, iptables will exit with a non-0 status. It's not like, eg, qemu, where you can determine what's supported by execing a 'help' command first.
Yeah, the "error" message that we generate is a bit misleading, since Laine says it's effectively not stopping things from working.
If you know how to easily fix the code so it classifies this as a warning, then I reckon "go for it". :)
It's not all that simple, or it would have been that way from the start. The problem is that the function that execs this iptables command is shared with other code, and changing its error reporting would change what happens when the other iptables commands fail (and doing the exact right thing in all cases in the short term would require ugly code that would just become obsolete very quickly). There was a discussion about this when I first added in the --checksum-fill rule, and we agreed that, because it was a temporary problem that would only exist for a short while until a distro's iptables version caught up to the libvirt version, rather than mess up good clean code for something that was going to go away, it would be acceptable to just add an extra warning level log describing the likely cause of the problem, thus heading off any uninformed bug report before it was made. Of course 1) that's assuming that people actually look at all the log messages, and 2) at the time I'm sure nobody thought Fedora 14 would be released without this code in iptables. (BTW, examples escape me right now, but I have noticed other cases of commands run by libvirtd exiting with non-0 status and causing an error log, but otherwise being harmless, so this isn't without precedence. Maybe that's one of the things that can be fixed with virRun/virExec are replaced with the new exec library.)
participants (3)
-
Justin Clift -
Laine Stump -
Osier