Opened 4 years ago
Closed 4 years ago
#20148 closed defect (fixed)
DHCP does not work in bridged mode
| Reported by: | lerdmann | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 6.1.18 |
| Keywords: | Cc: | ||
| Guest type: | other | Host type: | Windows |
Description
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.
Attachments (8)
Change History (26)
by , 4 years ago
| Attachment: | eComStationV2.2-2021-01-23-12-29-48.log added |
|---|
follow-up: 4 comment:3 by , 4 years ago
Do I need to use Wireshark on the host or is there another way to capture ethernet packets ?
comment:4 by , 4 years ago
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.
comment:5 by , 4 years ago
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.
comment:7 by , 4 years ago
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...
comment:8 by , 4 years ago
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 ?
by , 4 years ago
| Attachment: | trace_6_1_18_guest.pcap added |
|---|
by , 4 years ago
| Attachment: | trace_6_1_18_host.pcapng added |
|---|
by , 4 years ago
| Attachment: | trace_6_1_16_guest.pcap added |
|---|
by , 4 years ago
| Attachment: | trace_6_1_16_host.pcapng added |
|---|
comment:11 by , 4 years ago
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 ?
comment:12 by , 4 years ago
Now tried with the VPN client being turned off: it does not make a bit of a difference.
comment:13 by , 4 years ago
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...
comment:14 by , 4 years ago
Could you try PCNet adapter instead of e1000? It would help to pinpoint the issue.
comment:15 by , 4 years ago
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.
comment:17 by , 4 years ago
I confirm that the problem is fixed with Virtualbox 6.1.20. You can close this ticket.
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 (ticket #19930).