DHCP does not work in bridged mode

[lerdmann]

host: Win64, guest: OS/2, network running in bridged mode

The OS/2 DHCP client does no longer receive an IP address. That used to work without a problem with Virtualbox 6.1.16 and I have changed nothing, neither Virtualbox settings nor anything in the guest.

My suspicion is, that this is due to the changes done for UDP packets (zero packet length) but I am by no means an ethernet expert.

[lerdmann]

Forgot to mention: for the guest configuration, I am using the "Intel PRO/1000 MT Server" (e1000) network adapter emulation. And I meant to say "UDP checksum offloading" instead of zero packet length.

[vushakov]

Please, can you provide a packet capture for a failing DHCP exchange?

[lerdmann]

Do I need to use Wireshark on the host or is there another way to capture ethernet packets ? Ah, ok, I see that there is a Virtualbox inbuilt feature to capture ethernet packets. I'll use that.

[vushakov]

Replying to lerdmann:

Do I need to use Wireshark on the host or is there another way to capture ethernet packets? Ah, ok, I see that there is a Virtualbox inbuilt feature to capture ethernet packets. I'll use that.

You can use built-in capture but that captures at the VM interface boundary, so if the problem is, say, with bridging code not delivering some packets, you won't see them obviously. So with bridged it's better to capture both on the host at the guest to be able to ddx problems like that.

[lerdmann]

DHCP with 6.1.16

[lerdmann]

DHCP with 6.1.18

[lerdmann]

For the time being, I have added pcap files only from the guest (Virtualbox internal pcap logging). But is already apparent, the sequence of DHCP related packets is different. Let me know if you also need host pcap files.

[lerdmann]

DHCP with 6.1.18, host side

[lerdmann]

also added for 6.1.18, host pcap tracing

[vushakov]

Thanks. Do these captures represent the same traffic? The transaction ids don't seem to match and they should not have been rewritten.

What's going on here is that 1) you are bridging to wifi and 2) the client uses unicast as you can see in the guest captures. Now, "bridging" to wifi is not really bridging, so guest's packets are rewritten by VBox. In particular all DHCP packets get broadcast flag added, otherwise the DHCP server reply would never reach the host. In the host trace you can see that the DHCP server replies do reach the host, but for some reason they are not delivered to the VM. Which is strange, as this code haven't change in quite a while and I don't recall other complaints about it being broken...

[lerdmann]

No, the host and client trace for 6.1.18 are not from the same traffic (it occured to me that you would ask for this only after I had taken those traces). Do you want me to repeat and trace simultaneously on host and guest ?

[lerdmann]

Have now added trace files taken simultaneously on host and guest.

[lerdmann]

And the very same for the working Virtualbox 6.1.16.

[lerdmann]

Forgot to mention: I have a VPN client running on the host. But why would that matter for 6.1.18 where it apparently does not matter for 6.1.16 ?

[lerdmann]

Now tried with the VPN client being turned off: it does not make a bit of a difference.

[vushakov]

Can you make an experiment and configure the IP address in the guest statically and check if if works?

This is really weird as I don't see any relevant changes between .16 and .18...

[aleksey]

Could you try PCNet adapter instead of e1000? It would help to pinpoint the issue.

[aleksey]

There is no need for additional tests. I've reproduced the issue locally. It is a recent regression in e1000, related to RDT register checks. It will be fixed in the upcoming maintenance release.

[lerdmann]

ok, thanks !

[lerdmann]

I confirm that the problem is fixed with Virtualbox 6.1.20. You can close this ticket.

[vushakov]

Thanks for the update.