VirtualBox

Ticket #17277 (closed defect: fixed)

Opened 12 months ago

Last modified 4 months ago

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

Reported by: TomPin Owned by:
Priority: major Component: network
Version: VirtualBox 5.2.0 Keywords: siemens tia portal simatic
Cc: tom.pinkas@… Guest type: Windows
Host type: Linux

Description

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

Attachments

pcap_and_log.tgz Download (29.6 KB) - added by TomPin 12 months ago.
Described in ticket message.
traffic-new.tgz Download (23.1 KB) - added by TomPin 12 months ago.
Simultaneous traffic from host and guest from version 5.1.30 and 5.2.0
PnDiscoveryPc.pcapng Download (24.3 KB) - added by sam48 4 months ago.
Computer packets while discoverying
PnDiscoveryVm.pcapng Download (38.7 KB) - added by sam48 4 months ago.
Vm traffic while discoverying

Change History

Changed 12 months ago by TomPin

Described in ticket message.

comment:1 follow-up: ↓ 2 Changed 12 months ago by 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)?

comment:2 in reply to: ↑ 1 Changed 12 months ago by TomPin

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.

comment:3 follow-up: ↓ 4 Changed 12 months ago by vushakov

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

comment:4 in reply to: ↑ 3 Changed 12 months ago by TomPin

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.

comment:5 follow-up: ↓ 6 Changed 12 months ago by 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.

Changed 12 months ago by TomPin

Simultaneous traffic from host and guest from version 5.1.30 and 5.2.0

comment:6 in reply to: ↑ 5 Changed 12 months ago by TomPin

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...

comment:7 Changed 12 months ago by aleksey

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.

comment:8 Changed 12 months ago by aleksey

  • Summary changed from Bridged Adapter driver filter out PROFINET DCP packets in Linux Host to Bridged Adapter driver filter out PROFINET DCP packets in Linux Host => Fixed in SVN

comment:9 Changed 12 months ago by michael

  • Status changed from new to closed
  • Resolution set to fixed

comment:10 Changed 12 months ago by aleksey

The fix went into 5.2.2.

comment:11 Changed 4 months ago by sam48

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

Changed 4 months ago by sam48

Computer packets while discoverying

Changed 4 months ago by sam48

Vm traffic while discoverying

comment:12 Changed 4 months ago by sam48

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

comment:13 Changed 4 months ago by aleksey

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.

comment:14 Changed 4 months ago by 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.

comment:15 follow-up: ↓ 16 Changed 4 months ago by 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.

comment:16 in reply to: ↑ 15 Changed 4 months ago by 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.

comment:17 Changed 4 months ago by aleksey

  • Status changed from reopened to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use