The option of ipappend 1 in the default file and retransmission
of HELLOs in udp-sender (--rexmit-hello-interval) has been
valuable to getting udpcast working with the Dell notebooks
we have with Broadcom 5700 series ethernet.
Today, with a slightly newer broadcom chipset appearing in
the most recent shipment, we noticed that udp-receiver was
intermittantly not showing the "hit any button to start transfer"
message. With some trial and error I found that if I
watched the tail of /var/log/message on the receiver (server)
and waited for the messages on TX and RX flow control to
complete before running udp-receiver, it would always initiate
a good connection. If I had started the udp-receiver
prior to the TX/RX flow control appearing in the message log
(in which case there was no "hit any key" message),
I could ^C the receiver, run it again and it would signify
the ready state with 100% success.
In conclusion, we have a workaround of starting udp-receiver
after a few seconds past the client PXE machine booting and
showing the udp-sender status ready (but not yet "hit any key...").
Another solution would be if udp-receiver also supported
--rexmit-hello-interval. It isn't a flaw in the udpcast system
but a kludge for a network device that is proving itself to be
sluggish in initialization in general.
--Donald Teed
Hi,
I wonder if someone could help me. I have started testing the
UDPreceive/udpsend programs for rolling out linux onto refurbished PC's for
a charity I work for. The idea is to role out linux onto 10-20 refurbished
PC's (at once) before shipping them to charities/schools/colleges that
really need them, mainly in Africa.
I am using the command line version because we are not transfering a raw
disk image we are transferring a tar'd tree and preparing the machines for
custom hardware detection (as all the hardware is basically random).
The tar file is about 1.2gig, and I am piping the output through both
md5sum and tar to extract it. When I tried this on 1 machine everything was
fine but today I tested it onto 5 machines in parallel and the MD5sum of
the result on all 5 clients did not match the server version (they did
however match each other) and the tar file appears to be slightly corrupted
(though the machines did boot ok).
So my question is "is it possible that the data is corrupted during
multicasting?"
and if so "Is there anything I can do to make it work reliably?"
There seem to be quite a few error correction parameters available, which
ones should I try first?
Any help much appreciated,
Matt.
At first I was, but when I couldn't get the multicast senders to wait
for the clients I tried manually running udp-sender and receiver.
This to take flamethrower out of the equation and to pinpoint what was
causing it.
However, I already found the bug, and made a patch for it this morning.
The problem is the time struct udp-sender uses to store the time at
which the first receiver connects is never initialized to 0, while a if
statement later on assumes that the value is 0 if no receiver has
connected yet.
This causes the udp-sender doesn't know the time of the first connected
client and that it doesn't wait
The fix is initializing the variable correctly and setting it to 0.
I have attached a diff patch which corrects it, it works great now :)
Regards,
Ramon.
> -----Original Message-----
> From: Brian Elliott Finley [mailto:finley@mcs.anl.gov]
> Sent: donderdag 27 mei 2004 17:46
> To: Ramon Bastiaans
> Cc: udpcast(a)udpcast.linux.lu
> Subject: Re: [Udpcast] udp-sender does not wait at all?
>
> Are you using flamethrower to do this?
>
>
> Thus spake Ramon Bastiaans (bastiaans(a)sara.nl):
> >Hi,
> >
> >I have been working on getting multicast systemimager image
broadcasts
> >to work, but I am having a hard time.
> >
> >Is it just me (am I doing something wrong?) or does udp-sender
> >completely ignore the wait and client parameters?
> >
> >Udp-sender doesn't wait at all for a minimum number of clients, after
> >the first connection, it immediately starts the multicast to the
first
> >client.
> >
> >On the server:
> >
> ># udp-sender --pipe 'tar -B -S -cpf - -C
/home/test/sara/ramon/testdir .
> >' --portbase 12345 --min-clients 20 --max-wait 1800 --min-wait 600
--fec
> >8x8/128 --interface eth0 --max-bitrate 20M --full-duplex
--nopointopoint
> >--nokbd
> >stripes=8 redund=8 stripesize=128
> >Udp-sender 2004-02-22
> >Using mcast address 234.168.44.1
> >Compressed UDP sender for (stdin) at 10.168.44.1 on eth0
> >Broadcasting control to 10.168.44.255
> >New connection from 10.168.44.5 (#0) 00000019
> >Starting transfer: 00000019
> >bytes= 11 929 600 re-xmits=000000 ( 0.0%) slice=1024 73 709 551
> >615 - 0
> >Transfer complete.
> >Disconnecting #0 (10.168.44.5)
> >
> >On the client:
> >
> ># udp-receiver --interface eth0 --portbase 12345 --nokbd --nosync
--file
> >./bla.tar
> >Udp-receiver 2004-02-22
> >UDP receiver for ./bla.tar at 10.168.44.5 on eth0
> >received message, cap=00000019
> >Connected as #0 to 10.168.44.1
> >Listening to multicast on 234.168.44.1
> >bytes= 11 929 600 ( 15.91 Mbps) 11 929 600
> >Transfer complete.
> >ramon@u5:~/1.udptest$
> >
> >
> >Now there is no timestamps, but the udp-sender starts the multicast
in
> >about 2 seconds after the connect from the client. But the sender
does
> >not have 20 clients connected, and it didn't wait 10 minutes at all
(I
> >kind of overdid the values here, but with lower values it doesn't
work
> >either).
> >
> >Am I missing something?
> >
> >Kind regards,
> >
> >Ramon Bastiaans.
> >
> >_______________________________________________
> >Udpcast mailing list
> >Udpcast(a)udpcast.linux.lu
> >http://udpcast.linux.lu/mailman/listinfo/udpcast
> >
>
> --
> ------------------------------------------------------
> Brian Elliott Finley Argonne, MCS Division
> Mobile: 630.631.6621 Office: 630.252.4742
> gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52
> ------------------------------------------------------
