Bridged Adapter driver filter out PROFINET DCP packets in Linux Host => Fixed in SVN

[Tomáš Pinkas]

Host: Linux (Debian, kernel 4.11.0), Ethernet controller Intel I219-LM, driver e1000e.ko
Guest: Windows 7 Professional
Used software: ​Siemens TIA portal V14 SP1
Action: search for network devices on local network segment using protocol ​DCP, which is link layer broadcast (​more about DCP). In TIA Portal it's function Update accessible devices.

What have I discovered:

1. Software in GUEST OS send packet "PN-DCP: Ident req" (see attached pcap files)
2. HOST OS capture reply packet "PN-DCP: Ident OK" from remote device, but GUEST OS doesn't get it. It's probably filtered out by Bridged Adapter driver.

Same scenario works OK with Windows 10 HOST and VirtualBox 5.2.0, but doesn't work with Linux HOST.
Same scenario works with Linux HOST and VirtualBox 5.1.30.

Attachment: pcap files during DCP discovery process:

1. host-traffic.pcapng: from Linux HOST OS, see packets 12 and 14.
2. guest-traffic.pcap: from VirtualBox packet logging mechanism, see packet 191. and no Ident OK response further.
3. VirtualBox log file

[Tomáš Pinkas]

Described in ticket message.

[Valery Ushakov]

Same scenario works with Linux HOST and VirtualBox 5.1.30

Does 5.1.30 work on the same Linux host (just to clarify, in case kernel version might have something to do with it)?

[Tomáš Pinkas]

Replying to vushakov:

Same scenario works with Linux HOST and VirtualBox 5.1.30

Does 5.1.30 work on the same Linux host (just to clarify, in case kernel version might have something to do with it)?

Yes, same Linux host. (Uninstalled VirtualBox 5.2.0 and than installed 5.1.30). I've even tried different kernels 3.16.0 and 4.13.0 - same result.

[Valery Ushakov]

Also, do these captures contain the same traffic or were they taken independently? They don't seem to match.

[Tomáš Pinkas]

Replying to vushakov:

Also, do these captures contain the same traffic or were they taken independently? They don't seem to match.

Yes, those were taken independently. I don't have simultaneous pcaps anymore. If it would help, I can prepare them.

[Aleksey Ilyushin]

Can you manually assign IP addresses to the guest and the remote host (if they do not have addresses) and try to ping the guest from the remote host or vice versa? In other words, is the problem specific to DCP or is it observable with ICMP as well? Locally I can ping guests bridged to host VLAN interfaces with both 5.2.0 and 5.1.30 in Ubuntu 16.04 (4.4 kernel).

Could it be that in 5.1.30 and in 5.2.0 were bridged to different interfaces? For example, the guest was bridged to VLAN interface on the host in 5.1.30, while in 5.2.0 it somehow was bridged to the physical adapter (to which VLAN interface was "bound"). It is apparent from the capture files that the remote node (28:63:36:d7:68:a7) is configured to be on VLAN 0, while the guest (08:00:27:eb:fc:6f) is clearly not on VLAN.

[Tomáš Pinkas]

Simultaneous traffic from host and guest from version 5.1.30 and 5.2.0

[Tomáš Pinkas]

Replying to aleksey:

Can you manually assign IP addresses to the guest and the remote host (if they do not have addresses) and try to ping the guest from the remote host or vice versa? In other words, is the problem specific to DCP or is it observable with ICMP as well? Locally I can ping guests bridged to host VLAN interfaces with both 5.2.0 and 5.1.30 in Ubuntu 16.04 (4.4 kernel).

Could it be that in 5.1.30 and in 5.2.0 were bridged to different interfaces? For example, the guest was bridged to VLAN interface on the host in 5.1.30, while in 5.2.0 it somehow was bridged to the physical adapter (to which VLAN interface was "bound"). It is apparent from the capture files that the remote node (28:63:36:d7:68:a7) is configured to be on VLAN 0, while the guest (08:00:27:eb:fc:6f) is clearly not on VLAN.

It seems the problem is related to DCP only - ping works OK from remote host to guest and back. I made the two same environments (with Virtualbox 5.1.30 and 5.2.0) and took simultaneous capture from guest and host - that makes 4 pcap files. I did DCP request and than ping from remote host (192.168.1.101) to guest. You can find it in attachment traffic-new.tgz.

Description:
host_filename:packet_number = guest_filename:packet_number

Virtualbox 5.1.30:
request:
vbox5.1.30-OK--simultaneous-capture-from-host.pcap:22 = vbox5.1.30-OK--simultaneous-vbox-capture.pcap:94

reply:
vbox5.1.30-OK--simultaneous-capture-from-host.pcap:34/35 = vbox5.1.30-OK--simultaneous-vbox-capture.pcap:101,102

Virtualbox 5.2.0:
request:
vbox5.2.0-NOK--simultaneous-capture-from-host.pcapng:39 = vbox5.2.0-NOK--simultaneous-vbox-capture.pcap:122

reply:
vbox5.2.0-NOK--simultaneous-capture-from-host.pcapng:43,44 = missing

---

Btw. If it would help, I'm able to share vbox image with software generating DCP requests...

[Aleksey Ilyushin]

Thanks a lot for providing capture files! This was indeed a regression in 5.2. The protocol field got duplicated, when VLAN tag stripped by host adapter was re-inserted back into the packet by VirtualBox. DCP was affected because it apparently uses priority tags (VLAN tags with ID 0). The fix will be included into the next maintenance release.

[Aleksey Ilyushin]

The fix went into 5.2.2.

[sam48]

Good morning, i'm new to the forum, i'm running virtualbox v5.2.16 and it seems that the issue described here still present.

i'm running windws 7 as guest and windows 7 as host.

[sam48]

Computer packets while discoverying

[sam48]

Vm traffic while discoverying

[sam48]

I've attache the wireshark packets sniffed from both pc and Vm. I hope that someone could help me. Thanks.

[Aleksey Ilyushin]

Hi Sam,

Why did you decide you had the same issue? I can clearly see both requests and replies in the VM packet capture file you have provided (packets #100 and #104, as well as #101/#105 in other direction).

Moreover, there are no priority tags in any captured PN-DCP packets, which means your issue is definitely not related to the original one. Note that the host OS is different as well. You need to come up with the complete description of your problem. It is not clear which of original symptoms apply to your case. Logs would be nice as well.

[sam48]

Hi Aleksey, i thought that it was the same issue cause the onlyu device responding to the dcp discovery request is my real pc, i saw that the packets coming from the outside are not forwarded to the Vm.

you can see on PnDiscoveryPc.pcapng packets 22 to 30 are not present on the PnDiscoveryVm.pcapng.

i'm new, and i thaught that os was not so relevant. i will open a request next time instead of modifying an old one.

which log i could attach?

i was discoverying profinet nodes on the network with tia portal v14 sp1.

thanks for your help.

[Aleksey Ilyushin]

No logs are need, I believe. Just like any other host on your LAN, your VM (MAC address 08:00:27:1a:4f:70) is not supposed to receive unicast packets 22 to 30 because they are sent toward your router (74:da:38:e6:ba:35) by various hosts on your LAN. In order to receive such packets you need to set "Promiscuous Mode" to "Allow All" in VM virtual network adapter settings (Machine->Settings->Network->Advanced). This is completely irrelevant to the issue reported by the originator of this ticket, so if you would not mind, I'd like to resolve the issue as fixed.

[sam48]

Thank you, sorry for my mistake. Set it as fixed.

Replying to aleksey:

No logs are need, I believe. Just like any other host on your LAN, your VM (MAC address 08:00:27:1a:4f:70) is not supposed to receive unicast packets 22 to 30 because they are sent toward your router (74:da:38:e6:ba:35) by various hosts on your LAN. In order to receive such packets you need to set "Promiscuous Mode" to "Allow All" in VM virtual network adapter settings (Machine->Settings->Network->Advanced). This is completely irrelevant to the issue reported by the originator of this ticket, so if you would not mind, I'd like to resolve the issue as fixed.