VMware Communities
uniquwy
Contributor
Contributor
Jump to solution

Linux Host, Windows Guest, Bridged network, crazy incoming packets multiplication

Hi all!

Config:

VMWare Player 17.0.2

Host: Ubuntu LTS 22.04.2 LTS (fully up-to-date)

Guest: Windows 10 (fully up-to-date)

Physical network interface on the host: Comet Lake PCH CNVi WiFi (vid:8086 pid:06f0) Any

Physical network interface on the guest: Intel(R) 82574L (e1000e in the VMX) Any, configured as bridged

Situation:

Using VMWare to debug network application I noticed strangest incoming network traffic.

Each packet from the network to the guest via bridged iface duplicated at least 63 times.

I just run the network monitor tool and send single ICMP echo request to remote LAN host.

Result on the picture.

We see one outgoing packet and 63 incoming replies with same sequence number and tiny time delta.

Sometimes I seen even two packets, which was sent one-by-one, but arrived as interlaced mix of 63+63 duplicates.

Another details:

This behavior does not depends from: WiFi router (two different was probed), remote host (a lot tested), type of virtual network adapter.

Problem does not appear in the NAT mode.

Problem affects all tested network protocols: ICMP, UDP, TCP.

Overall network performance is very low due to this, by fact bridged network is unusable at all.

Any ideas?

UPDATE 1:

Tried with another WiFi adapter (Ralink Technology, Corp. MT7601U Wireless Adapter vid:148f pid:7601).

Now every outgoing ICMP request generates the same 63 replies.

So problem not in the wireless adapter/driver on the host.

UPDATE 2:

By analyzing duplicated packets I found out that every next dup has decreased TTL field. And flood always over after this value reaches 1.

Thus it can be assumed that there is a ring somewhere inside VMWare network subsystem.

0 Kudos
1 Solution

Accepted Solutions
uniquwy
Contributor
Contributor
Jump to solution

After additional traffic analyzing on the host, I found out that root of the problem is enabled packed forwarding on the host.

Host's TCP/IP stack forward each incoming transit packet to the same interface, where it came from. In result I see a classic ping-pong between wlan0 and itself until TTL will exhausted.

After echo 0 > /proc/sys/net/ipv4/ip_forward the virtual network become normal.

This is enough for me in the current situation, but if forwarding will really needed I still don't know what to do.

At least one thing is clear now: this is not an VMWare issue, this is complex problem of interference of Linux-host's TCP/IP stack and VMWare virtual network.

View solution in original post

0 Kudos
2 Replies
uniquwy
Contributor
Contributor
Jump to solution

After additional traffic analyzing on the host, I found out that root of the problem is enabled packed forwarding on the host.

Host's TCP/IP stack forward each incoming transit packet to the same interface, where it came from. In result I see a classic ping-pong between wlan0 and itself until TTL will exhausted.

After echo 0 > /proc/sys/net/ipv4/ip_forward the virtual network become normal.

This is enough for me in the current situation, but if forwarding will really needed I still don't know what to do.

At least one thing is clear now: this is not an VMWare issue, this is complex problem of interference of Linux-host's TCP/IP stack and VMWare virtual network.

0 Kudos
shixudong
Contributor
Contributor
Jump to solution

Three factors add up. Just remove any one of them

1. ip_forward

2. Bridge the wireless network card

3. The VMware VM interacts with the host using the MAC after Layer 2 nat (that is, the host wireless NIC MAC)

The third factor is vmware's problem

See https://blog.csdn.net/sxd2001/article/details/130985812

0 Kudos