Hi,
I could be wrong, but the problem may be that you just have to wait.
Is the hard drive on the target machine still active (LED on) when it apparently hangs? If so it might still be working fine.
In our environment, the last part of the write is an empty part of the disk, which is highly compressed. Our 512 MB RAM notebooks can hold a lot of compressed and zeroed data in memory, and it works out to about 5 GB of data to be written to disk. For us, it is normal for there to be a delay of between 5 and 10 minutes between the disconnect and the completion of writing to disk. If one used a slower disk on the target, and had lots of memory, this could even be more extreme difference between disconnect time and completing the write to disk time.
If network card X and Y are on different target client machines, then it might have nothing to do with the network cards.
If the same machine is involved with these 2 network cards, then it might be a hardware or driver issue.
--Donald Teed
On Tue, 3 Jan 2006, Ramon Bastiaans wrote:
Hi all,
I have been using udpcast to image machines succesfully for a while now. Now we are expanding our infrastructure with more machines and extra networks, which I would like to image with the same server.
This seems to work a little, except for the fact that it does not complete correctly on the new network(card/interface).
The receiver seems to get allmost all data, but the udp-receiver seems to 'hang' at the end. The most frustrating part is the udp-sender that says "Transfer complete, disconnecting".
When I try it in unicast and sniff the network I see the following on a _succesfull_ image to networkcard X: 16:06:59.620836 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length: 1472 16:06:59.620841 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length: 1472 16:06:59.620846 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length: 1472 16:06:59.620851 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length: 1472 16:06:59.620856 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length: 144 16:06:59.621146 IP 192.168.17.140.9032 > 192.168.16.3.9033: UDP, length: 8 16:06:59.621198 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length: 144 16:06:59.621397 IP 192.168.17.140.9032 > 192.168.16.3.9033: UDP, length: 8 16:07:00.654842 IP 192.168.16.3.9033 > 192.168.19.255.9032: UDP, length: 28 16:07:01.146772 IP 192.168.17.140.9032 > 192.168.16.3.9033: UDP, length: 4
When I do the same (failing) image to networkcard Y: 15:27:13.413078 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP, length: 1472 15:27:13.413084 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP, length: 1472 15:27:13.413089 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP, length: 1472 15:27:13.413095 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP, length: 1472 15:27:13.481157 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP, length: 144
And then nothing. This is the last part of the imaging process, right up till it completes at networkcard X, and just hangs on networkcard Y.
It seems to me the last few packets are missing and that's causing the hang.
Anyone experienced something like this before and/or has any pointers to what might cause this? I suspect a switch or similar device to block the last packets. I.e. a rate limiting setting or something.
Kind regards,
- Ramon Bastiaans.
-- There are really only three types of people:
Those who make things happen, those who watch things happen, and those who say, "What happened?"
ing. R. Bastiaans HPC - Systems Programmer
SARA - Computing and Networking Services Kruislaan 415 PO Box 194613 1098 SJ Amsterdam 1090 GP Amsterdam
Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast