Firefox.com Firefox can't completely Download files

[paulg.ca]

I have been running into what appears to be a bug with VirtualBox.

Host OS is Windows7 SP1 x64 with the latest updates. Guest OS is Centos 7.1 x64 with the latest updates.

When we use Firefox from www.firefox.com, it freezes when we try to download a file.

Steps to reproduce:

1. Start Guest OS
2. Immediately launch Firefox (38.2.1ESR or the latest 40.x release) and try to download a file (In our case, it is a epub file, ​http://www.cse.yorku.ca/~jr/epub/w/CV.epub)
3. Firefox should them freeze

If you close the VM and restart the VM, Firefox should be able to download the file. If you reboot the host and retry the steps above you will reproduce the FF download failure.

If you look a Wireshark trace during the download you actually see the file start to download, but it seems that it isn't getting fully processed/closed/or TCP session closed.

Google Chrome/wget doesn't have this issue. It seems to tied to the FF from firefox.com

I am able to reproduce this with VirtualBox 5.0.2 and 5.0.4. VirtualBox 4.3.30 doesn't have this issue.

See the attached log and network captures.

[paulg.ca]

How can I upload the Wireshark network trace files. The 512KB limit seems kinda small for log files, can this be increased?

[Valery Ushakov]

Replying to paulg.ca:

How can I upload the Wireshark network trace files. The 512KB limit seems kinda small for log files, can this be increased?

Not easily. Can you put your capture some place accessible and provide the url here?

[paulg.ca]

You can find the WireShark network trace at the following URLs.

​https://www.cse.yorku.ca/~paulg/vbox-4.3.30-epub-capture-success-download.pcapng

​https://www.cse.yorku.ca/~paulg/vbox-5.0.4-epub-capture-fail-download-epub.pcapng

[Valery Ushakov]

At first glance it looks like Firefox freezing is the cause, not the effect. Apparently at some point firefox freezes for whatever reason and stops reading from the socket, so the OS buffers data in the socket buffer in the kernel, advertising smaller and smaller TCP window to the peer (NAT in this case), until finally the window closes in frame 357. At this point NAT stops forwarding data to the guest, waiting for the window to open. Since that doesn't happen in a while, NAT sends a window probe, one byte of data into the closed window, frame 360. Host rejects the probe in frame 361, re-sending the old ack and advertising zero window again. If you waited longer, you would see a few more window probes like that.

So from the TCP point of view I don't see anything unusual.

Have you tried disabling firerfox add-ons if you have any installed?

At this point strace'ing the firefox process to see what it's doing is probably the next logical step. But this doesn't look like a network/NAT bug to me from what I've seen so far.

[paulg.ca]

Are you saying that the packet trace in 4.3.30 and 5.0.4 are the same? Are you able reproduce the problem?

If I take the same VDI file and run it in VBox 4.3.30 Firefox works, nothing else changed NOTHING!, just the version of VBox. Whats up with that? I don't have a trace file for VBox 5.0.2, but in 5.0.2 the trace is significantly different from 5.0.4.

Do you need a trace from VBox 5.0.2, would that help? Should I be running the Wireshark trace in the Host OS (Windows 7)?

[Valery Ushakov]

I'm saying that the 5.0.4 trace indicates the causation that is the opposite of what you are implying. The problem is not that firefox freezes because of a network problem. Rather the observed difference in the traces is caused by firefox freezing for whatever reason.

[paulg.ca]

Thank you vushakov for your response.

I still don't get why VBox 4.3.30 always works and 5.0.2 and 5.0.4 don't work. I am using the the same VDI file. Are you able to reproduce the problem ?

Thank You Paul