blob: b4a60b4c829b0390b64eeb78621f205b3ae0e05f (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
|
debug: 0.834
network: 0.810
performance: 0.792
graphic: 0.767
ppc: 0.756
device: 0.713
register: 0.696
semantic: 0.655
PID: 0.655
socket: 0.638
hypervisor: 0.574
architecture: 0.569
vnc: 0.550
user-level: 0.496
peripherals: 0.479
risc-v: 0.443
TCG: 0.412
kernel: 0.388
VMM: 0.380
arm: 0.371
mistranslation: 0.356
i386: 0.339
boot: 0.314
permissions: 0.314
files: 0.295
KVM: 0.231
x86: 0.189
virtual: 0.174
assembly: 0.111
udp checksum computed as 0 not converted to 0xffff, from guest os that share a common linux bridge among multiple guest os
UDP checksum computed as '0' during transmission of packets that uses e1000 NIC in the Guest as well as emulated h/w in the qemu layer, That needs to be converted to 0xffff, This occurs only when Hardware checksum offload is been set in the guest OS NIC and made it as a transmitter. The guest O.S use the N/W interface that is been shared to the linux brige created in the host (used source=<bridge>) in the xml tags of libvirt.
As per RFC768(http://tools.ietf.org/html/rfc768 [^]), If the computed checksum is zero, it is transmitted as all ones (the equivalent in one's complement arithmetic). An all zero transmitted checksum value means that the transmitter generated no checksum (for debugging or for higher level protocols that don't care).
Triaging old buck tickets ... can you still reproduce this issue with the latest version of QEMU? Is it only happening with e1000 or also with other NICs? What kind of network backend are you using (--netdev user ? tap ? ....). Could you please provide the full command line that you use to run QEMU? Thanks!
Sorry, I meant "bug tickets", of course, not "buck tickets" ... need more coffee...
Question is where is this zero checksum observed which is not clear from the report.
If in the guest it is certainly correct.
If in the host it is correct so long as the bridge appears to have checksum offloading as well. If whatever interface the guest packets appear to come from is not set up with checksum offloading this is a bug which should be fixed by setting the offload flags to match the guest.
If outside the host this is a problem.
Fixed:
commit 0dacea92d26c31d453c58de2e99c178fee554166
Author: Ed Swierk <email address hidden>
Date: Thu Nov 16 06:06:06 2017 -0800
net: Transmit zero UDP checksum as 0xFFFF
The checksum algorithm used by IPv4, TCP and UDP allows a zero value
to be represented by either 0x0000 and 0xFFFF. But per RFC 768, a zero
UDP checksum must be transmitted as 0xFFFF because 0x0000 is a special
value meaning no checksum.
Substitute 0xFFFF whenever a checksum is computed as zero when
modifying a UDP datagram header. Doing this on IPv4 and TCP checksums
is unnecessary but legal. Add a wrapper for net_checksum_finish() that
makes the substitution.
(We can't just change net_checksum_finish(), as that function is also
used by receivers to verify checksums, and in that case the expected
value is always 0x0000.)
Signed-off-by: Ed Swierk <email address hidden>
Signed-off-by: Jason Wang <email address hidden>
|