VirtualBox

11 年 前 建立

11 年 前 結束

10 年 前 更新

#12441 closed defect (fixed)

TCP connections from host to guest drop on host network reconfiguration events. -> fixed in SVN

回報者: jglogan 負責人:
元件: network/NAT 版本: VirtualBox 4.3.4
關鍵字: networking 副本:
Guest type: Linux Host type: Mac OS X

描述 (由 vasily Levchenko 作最後更新)

I have started seeing this behavior after upgrading to 4.3.4. It is 100% repeatable on my system, and has a pretty significant impact on productivity.

The forum article I posted is https://forums.virtualbox.org/viewtopic.php?f=8&t=58909.

Reproduction steps:

1.) Start guest VM
2.) ssh into guest (localhost:2322 forwarded to guest:22 in my config)
3.) Perform any of the following operations:
  a.) disable, then enable WiFi (issue occurs on enable, not disable)
  b.) disable VPN on host (happens with IPSecuritas and NetExtender VPNs on my system)
  c.) enable VPN on host

Expected behavior: no impact on ssh connection from host to guest

Actual behavior in 4.2.x: same as expected

Actual behavior in 4.3.4: ssh connection terminated, 'Connection to localhost closed by remote host.'

Config:

Host - MacOS 10.8.5, Guest - Ubuntu 13.04, 3.8.0-34-generic x86_64 Guest network - Paravirtualized network (NAT, natdnshostresolver enabled so that I can resolve VPN hostnames, but I have tested with it disabled and the same issue occurs) WiFi physical network connection

附加檔案 (4)

VBox.log (59.3 KB ) - 11 年 前, 由 jglogan 新增
VBox.log, network events at end of log file.
guest.pcap (23.8 KB ) - 11 年 前, 由 jglogan 新增
Guest-side capture, failure at 06:11:04.579
host.pcapng (48.4 KB ) - 11 年 前, 由 jglogan 新增
Host-side capture, fails at 06:16:29.183.
guest.2.pcap (18.4 KB ) - 11 年 前, 由 jglogan 新增
Guest-side capture.

下載所有附檔: .zip

更動歷史 (34)

11 年 前jglogan 編輯

附檔: 新增 VBox.log

VBox.log, network events at end of log file.

comment:1 11 年 前vasily Levchenko 編輯

Could you please collect pcap file of your ssh session?

11 年 前jglogan 編輯

附檔: 新增 guest.pcap

Guest-side capture, failure at 06:11:04.579

11 年 前jglogan 編輯

附檔: 新增 host.pcapng

Host-side capture, fails at 06:16:29.183.

11 年 前jglogan 編輯

附檔: 新增 guest.2.pcap

Guest-side capture.

comment:2 11 年 前jglogan 編輯

I used Wireshark on the host side and tcpdump on the guest side; please let me know if that's not okay.

host.pcapng and guest.2.pcap are captures of the same failure event from the host and guest side, respectively. guest.pcap is a capture of a separate failure, I just forgot to check the "replace attachement with same filename" when I uploaded guest.2.pcap.

Thanks! John

comment:3 11 年 前jglogan 編輯

Just curious, could this be a side effect of this bugfix for 4.3.4?

https://www.alldomusa.eu.org/ticket/12225

comment:4 11 年 前jglogan 編輯

Another datapoint...I downgraded to 4.3.2 and I don't see the problem anymore. My guess is that the change for bug 12225 is causing this.

comment:5 11 年 前vasily Levchenko 編輯

描述: 修改 (差異)

comment:6 11 年 前vasily Levchenko 編輯

Ah, this isn't a bug it's the feature :) the idea behind this is to enforce guest's dhcp client to request new lease, in case you've changed network or location. Perhaps we should think about flexibility there.

comment:7 11 年 前jglogan 編輯

With a NAT, though, shouldn't I be isolated from what happens on the host network?

Or is the DHCP renewal done mainly to handle changes to DNS servers?

If that's the case, then is it necessary to force new DHCP requests if I'm using one of the host DNS proxy options (e.g. natdnshostresolver)?

jgl

回覆:  7 comment:8 11 年 前vasily Levchenko 編輯

Replying to jglogan:

With a NAT, though, shouldn't I be isolated from what happens on the host network?

Or is the DHCP renewal done mainly to handle changes to DNS servers?

right

If that's the case, then is it necessary to force new DHCP requests if I'm using one of the host DNS proxy options (e.g. natdnshostresolver)?

for DNS proxy it isn't require to enforce guest renew dhcp lease. Will check whether we can do anything on this direction.

jgl

comment:9 11 年 前jglogan 編輯

Thanks. It'd be mighty helpful. Right now I lose everything if I start/stop my VPN, or sleep/wake my laptop.

comment:10 11 年 前CrashRoX 編輯

I'm also experiencing this problem. Not sure if its machine specific but I've tried on OS X mountain lion and mavericks. Any VMs that I'm sshed into lose their connection when the computer sleeps. The problem started when I upgraded to VBox 4.3.6, not sure what version I was on before.

comment:11 11 年 前CrashRoX 編輯

I'm also experiencing this problem. Not sure if its machine specific but I've tried on OS X mountain lion and mavericks. Any VMs that I'm sshed into lose their connection when the computer sleeps. The problem started when I upgraded to VBox 4.3.6, not sure what version I was on before.

comment:12 11 年 前remillet 編輯

I also started having this problem after updating to VirtualBox 4.3.6 on OS X Mavericks 10.9.1. Very frustrating.

comment:13 11 年 前lukeasrodgers 編輯

Also having this problem with VirtualBox 4.3.6r91406 on OSX 10.9.1.

If anyone has suggestions for a temporary workaround until a bugfix is landed, that would be most appreciated.

comment:14 11 年 前jglogan 編輯

I've resigned myself to running 4.3.2 for now. Fortunately this has worked well enough for me.

comment:15 11 年 前franky22 編輯

Having trouble with this as well. Makes using virtualbox for development nearly worthless.

comment:16 11 年 前vasily Levchenko 編輯

Could you please verify that build-osx fixes issue for you?

comment:17 11 年 前jglogan 編輯

It works properly for three of these test cases described above, thanks!

Any reason why I should not stay with this build on my dev system until 4.3.8 releases? Or should I downgrade back to 4.3.2 for now?

回覆:  17 comment:18 11 年 前vasily Levchenko 編輯

Replying to jglogan:

It works properly for three of these test cases described above, thanks!

Thank for testing and update.

Any reason why I should not stay with this build on my dev system until 4.3.8 releases? Or should I downgrade back to 4.3.2 for now?

There are no such reasons, it's hotfix based on stable branch.

comment:19 11 年 前vasily Levchenko 編輯

摘要: TCP connections from host to guest drop on host network reconfiguration events.TCP connections from host to guest drop on host network reconfiguration events. -> fixed in SVN

comment:20 11 年 前lukeasrodgers 編輯

The above link to build-osx is broken. I was able to download it for one machine, which fixed the problem, but am still running 4.3.6 on other machines which are still subject to this bug.

comment:21 11 年 前yvess 編輯

I also want to download this test build. Would be nice if the link would be get fixed by someone

comment:22 11 年 前Frank Mehnert 編輯

Here is another test build.

comment:23 11 年 前emptysquare 編輯

Recent test build fixes this issue for me--an ssh session to the virtual machine persists after the host sleeps and wakes.

comment:24 11 年 前toobulkeh 編輯

I'm also having this issue. Can't wait to see the release pushed!

最後由 toobulkeh 編輯於 11 年 前 (上一筆) (差異)

comment:25 11 年 前Frank Mehnert 編輯

狀態: newclosed
處理結果: fixed

Fix is part of VBox 4.3.8.

comment:26 11 年 前mattdw 編輯

I'm still seeing exactly this bug in 4.3.8. I've checked that I'm updated; kextstat shows only v4.3.8 extensions loaded, I've upgraded both virtual box and the vbox tools in my VM, and turning the wifi on and off (my primary interface is by ethernet cable) or sleeping my computer will reliably disconnect all ssh sessions into my VM.

comment:27 11 年 前jglogan 編輯

From the fix description in the release notes: "NAT: transparent handling of host sleep/resume and network configuration changes if the dnsproxy is enabled or if the hostresolver is used"

Are you using DNS proxy or the host DNS resolution options? If not, you may not get transparent handling on sleep/resume.

It's fixed for me; I use host DNS resolution on my laptop VMs.

comment:28 11 年 前mattdw 編輯

Hey jglogan, thanks. Where would I find those settings? I haven't set anything up explicitly. (However, I didn't have this problem in older versions of VirtualBox either.

comment:29 11 年 前mattdw 編輯

Ah, found it:

VBoxManage modifyvm "VM name" --natdnshostresolver1 on

And thanks, that appears to have solved the problem for me. A little disappointed that it was this involved to (IMO) restore previous default behaviour, but never mind. Thanks for your help, jglogan.

comment:30 10 年 前Valery Ushakov 編輯

元件: networknetwork/NAT
注意: 瀏覽 TracTickets 來幫助您使用待辦事項功能

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette