Public bug reported: If I send a broadcast message like this to the limited broadcast address:
echo a | nc -bu 255.255.255.255 5000 then the resulting packet looks like this on the sender side: 14:36:17.997662 02:00:c0:a8:7a:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 64, id 25278, offset 0, flags [DF], proto UDP (17), length 30) 192.168.122.251.42141 > 255.255.255.255.5000: [bad udp cksum 476f!] UDP, length 2 However, an other VM on the same host sees the following packet: 14:36:19.247793 02:00:c0:a8:7a:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 64, id 25278, offset 0, flags [DF], proto UDP (17), length 30) 192.168.122.1.42141 > 255.255.255.255.5000: [bad udp cksum 3b71!] UDP, length 2 So the source MAC address and other headers are untouched, but the source IP address is changed to the default gateway's! If I use a the subnet-specific broadcast, then the packets are left untouched, i.e.: echo a | nc -bu 192.168.122.255 5000 14:41:33.313490 02:00:c0:a8:7a:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 64, id 38571, offset 0, flags [DF], proto UDP (17), length 30) 192.168.122.251.46821 > 192.168.122.255.5000: [bad udp cksum aee5!] UDP, length 2 14:41:34.563615 02:00:c0:a8:7a:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 64, id 38571, offset 0, flags [DF], proto UDP (17), length 30) 192.168.122.251.46821 > 192.168.122.255.5000: [bad udp cksum aee5!] UDP, length 2 Is this a configuration issue, or a more fundamental issue of the virtual switch itself? ** Affects: qemu Importance: Undecided Status: New ** Tags: broadcast nat network -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1078305 Title: source IP address of broadcast packets gets rewritten when using NAT Status in QEMU: New Bug description: If I send a broadcast message like this to the limited broadcast address: echo a | nc -bu 255.255.255.255 5000 then the resulting packet looks like this on the sender side: 14:36:17.997662 02:00:c0:a8:7a:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 64, id 25278, offset 0, flags [DF], proto UDP (17), length 30) 192.168.122.251.42141 > 255.255.255.255.5000: [bad udp cksum 476f!] UDP, length 2 However, an other VM on the same host sees the following packet: 14:36:19.247793 02:00:c0:a8:7a:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 64, id 25278, offset 0, flags [DF], proto UDP (17), length 30) 192.168.122.1.42141 > 255.255.255.255.5000: [bad udp cksum 3b71!] UDP, length 2 So the source MAC address and other headers are untouched, but the source IP address is changed to the default gateway's! If I use a the subnet-specific broadcast, then the packets are left untouched, i.e.: echo a | nc -bu 192.168.122.255 5000 14:41:33.313490 02:00:c0:a8:7a:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 64, id 38571, offset 0, flags [DF], proto UDP (17), length 30) 192.168.122.251.46821 > 192.168.122.255.5000: [bad udp cksum aee5!] UDP, length 2 14:41:34.563615 02:00:c0:a8:7a:fb (oui Unknown) > Broadcast, ethertype IPv4 (0x0800), length 44: (tos 0x0, ttl 64, id 38571, offset 0, flags [DF], proto UDP (17), length 30) 192.168.122.251.46821 > 192.168.122.255.5000: [bad udp cksum aee5!] UDP, length 2 Is this a configuration issue, or a more fundamental issue of the virtual switch itself? To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1078305/+subscriptions