[Udpcast] Image does not complete correctly (receiver hangs)

Alain Knaff alain at knaff.lu
Tue Jan 3 17:12:35 CET 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).

What exactly is "new"? New make of network card? New switch? More than 
one switch between sender and receiver? Maybe even a router? Is it 
possibly for you to test each change "one-by-one", to try to identify 
which particular change brings the problem.

> 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

It looks like the "return" traffic (from the receiver back to the 
sender) is not working correctly. It's somewhat bizarre, because 
apparently it did work at the beginning of the transfer (or else the 
transfer could not have taken place at all, unless you used asynchronous 
mode)

[...]
> 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.
> 

 From the IP addresses, I assume you are using unicast mode (one single 
receiver).

It would help if you would tell us more about your network. What devices 
(switches, routers, etc.) are sitting between your sender and your 
receiver? What netmasks are involved? Where was the tcpdump observed (on 
sender? on receiver? on an unrelated box? If so, how was that box 
connected?) Are you reasonably sure that the trace is complete? (Many 
switches send unicast traffic only to the port where that machine is 
connected, unless you use a specifically configured monitoring port. 
That means that if you used an unrelated box to observe, the trace might 
be incomplete, depending on how the switch(es) has(ve) been set up)

Alain



More information about the Udpcast mailing list