Udpcast January 2006

udpcast@udpcast.linux.lu

4 participants
7 discussions

UDPCast source code issues...
by Saikrishna Dasari 25 Apr '06

25 Apr '06

Hi Alain, I was studying the UDPCast source code for some experimental purposes. I have the following question. 1. The whole data to be transfered into is divided into slices which again contains a series of blocks to transfer. Can we consider the whole data to be transfered as a single slice ( By setting appropriate parameters in code) and what kind of performance issues we can expect if we do a change of this kind at code level. Thanks in advance, Sai --------------------------------- Do you Yahoo!? Y! Messenger - Communicate in real time. Download now.

3 2

Buggy tg3 ethernet
by Donald Teed 04 Apr '06

04 Apr '06

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

2 1

Default boot not recognizing kb
by abarkley＠jamadots.com 04 Apr '06

04 Apr '06

I downloaded your CD image and it worked fine until I used it on a pc with a USB keyboard. These PCs are in the lab I am trying the program on. Do I need to compile my own image using my own kernal? I am using debian 3.1 and cannot find the required files as specified by the -k switch. Please, let me know what I need to do. Thanks, AJ

2 1

my problems
by Jean Razack 10 Jan '06

10 Jan '06

Hi, sorry for the last mail, i have forgotten to get a ip from dhcp. So my question is, what i musst enter to the console to get a ip from dhcp? thx -- Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko! Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner

2 1

Busybox wget ftpget tftp timeout
by Jean Razack 09 Jan '06

09 Jan '06

Hi, i have load a initrd from the udpcast online tool and have tried to use wget, tftp and ftpget and by all tools I get a timeout. I have found that the busybox tftp client have a bug, but not the other tools. Who can me they more about this problem? thx -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie

1 0

Modify initrd from cast-o-matic for pxe
by Jean Razack 09 Jan '06

09 Jan '06

Hi, i want to add some modules and scripts to my initrd. At first I have decompressed the initrd with bzip2. Then I want to mount ("mount -o loop ./initrd /mnt/initrd"), but I get the Message that the Filesystem is missing and ext2 and ext3 don't work? What I have done wrong ??? thx -- 10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail +++ GMX - die erste Adresse f�r Mail, Message, More +++

2 1

Image does not complete correctly (receiver hangs)
by Ramon Bastiaans 04 Jan '06

04 Jan '06

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

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast January 2006