VM Networking - Bridge adds padding (1x "0x00"-byte) to bridged frames with uneven length => Fixed in SVN

[VirtualRon]

Host:

• Windows 10 64-bit Enterprise - Release 1803
• Intel i219-LM LAN-Driver
• VirtualBox 6.0 and 5.2.22

VMs:

• Ubuntu Linux 18.04.1
• Cisco CSR 1000V 16.9.1
• Windows 2008R2

Defect: When any of these VMs generates frames which have uneven packet-length an additional padding [1x Byte = "0x00"] get's added when this frame is bridged out through the LAN-NIC.

Since adding padding to normal-length frames is absolutely useless i expect this to be a bug.

Workaround:

• don't
  • use bridged-networking
• use
  • a "host-only"-adapter [without DHCP-Service enabled!]
  • use the "Windows Networking"-Feature to bridge between the LAN-NIC and the "Virtual-Box Host-Only"-NIC

The windows-bridge works fine like a "transparent bridge" should and doesn't manipulate bridged frames.

[Aleksey Ilyushin]

This padding actually serves a purpose. Odd-length packets are padded with zeros to make sure their Ethernet header is aligned at word boundary. This prevents Microsoft Load Balancing/Failover (LB/FO) Provider from crashing as it modifies MAC addresses and expects them to be aligned at word boundary. LB/FO Provider is used in NIC teaming setups. Please refer to ​this forum thread for the description of the original issue.

[VirtualRon]

since MS-LB/FO is a rare cornercase, isn't it? IMHO this padding-feature should be disabled as default-setting and could be a configurable option for those few who need this.

did i really understand right: modifying frames in a transparent bridge (not so transparent anymore, just to 50% of all frames) for every virtualbox-user - just to overcome a bug in another software-product!?

[Aleksey Ilyushin]

Please try out one of the recent test builds (r128786 for 5.2 and r128790 for 6.0). These builds do not add padding, but they still should work fine with NIC teaming setups that use the LB/FO provider.