Oracle Linux 5.6 64-bit, running under VirtualBox on my Win 7 Pro deskop
This is a 'lab' machine, replicating one of my live servers. For my lab purposes, it is configured with 2 NICs
#1 configured hostonly, assigned to eth0 and configured with a fixed ip in the same subnet as the VBox adapter running on the host os.
#2 configured for NAT, assigned to eth1 which was then configured for DHCP. I have really not used anything that would address eth1 in several months, until today.when I began testing application of an Oracle Grid Infrastructure update and letting OUI retrieve and install any applicable updates.
The connection test using my MOS credentials passes.
The app (OUI) is able to retrieve from MOS a list of applicable patches.
When actually trying to download the patches, it returns an error, and the details state that there is "a network connection problem." No information more specific than that.
I ran two other tests to exercise the NAT adapter in retrieving files.
THe first test was a 'yum install firefox'. It completed with no problems.
The second was a wget to retrieve a patch. The wget was in a shell script provided by MOS as a download option for the selected patch. On several tries all of the exchange of credentials passed, but the actual wget of the patch file would hang without completing. Each time (I tried this several times, each time increasing what I was watching on the side) there would be a partial download of the file before things seemed to stall out, and it was at a different point each time.
The fact that the yum install downloaded all of its files (eleven in all) without a problem, and the wget is able to get anything at all indicates the net adapter is at least fundamentally working ... no configuration issues that would have it totally inoperable.
The only other observation is this. In order to 'watch' the download activity, I had a second session where I set up a loop to watch the activity on eth1 and the file being downloaded:
ls -ltr /download_dir | tail -5
Doing this I could see the TX and RX numbers on eth1 increasing and the size of the downloaded file increasing, until such time as things stalled out. What was particularly interesting was the fact that the loop did not run at a constant speed. Sometimes the 'sleep 2' would end up more like 5 or 6. I'm sure that has to do with the way VBox is handling the internal clock timing but don't know if that could be related to the download problem.