Udpcast November 2004

udpcast@udpcast.linux.lu

3 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

[PATCH] Syslog use
by Ramon Bastiaans 08 Feb '05

08 Feb '05

Hi all, I don't know if this should be applied to the source tree, but perhaps some people will find this patch useful (I know we do). We wanted some additional logging from udpcast to debug our casting sessions, because it seems that the only thing logged to its logfile is messages like this: "Doubling slice size to 1024" We also prefer syslog in stead of the separate file for logging So I wrote this little patch. It logs more information (very usefull for udpcast's running in the background on a image server) and it logs it to syslog. Information being logged: * New connections * Why a cast starts (is min clients reached or max wait passed, etc) * Transfer start (+ what file,pipe,port,if,participants) * Transfer complete * Disconnects See attached .patch Kind regards, -- Ramon Bastiaans SARA - Academic Computing Services Kruislaan 415 1098 SJ Amsterdam

2 2

rogue packet
by alexandre.letort＠club-internet.fr 06 Feb '05

06 Feb '05

Hi! I'am using udpcast to transfert disk Images from a server to several clients. The server box has one Network card and several virtual interfaces (eth0, eth0:0, eth0:1...). When I try to send a file to one client through one of the virtual interface(eth0:x) everything goes well. But when the client number increases (more than one) I get an error saying: Rogue packet received <eth0 IP address>:9001 expecting <eth0:x IP address>:9001 The command line used on the server is : udp-sender --file <filename> --interface eth0:x On the client: udp-receiver --file <filename> It seems that only the eth0 interface can be used bay udpcast. It works perfectly with this one. How can I get udpcast to work with my virtual interfaces Sorry for my bad English! Thank you for your help. regards Alex

2 1

(no subject)
by John Allison 06 Feb '05

06 Feb '05

hello group i work for a school system and have been using UDPCast for a couple of years now with great results. but we just got in the new dell gx280 pcs. they have sata hard drivers and a broadcom gigabit ethernet card. i can not get the boot disk nor the cd to use either device. is there anyone who has add these devices to the /dev/ on the floppy or cd image? (John Allison )

2 1

Udpcast built into a tftpboot image for Sun Sparc
by Donald Teed 25 Nov '04

25 Nov '04

I've joined udpcast and Gentoo's tftpboot Linux environment with lzop, Busybox, raidtools, etc. to make a solution for booting Sun Sparc machines on the network and using Udpcast to do the usual business of cloning disks and partitions. There is a guide (and related downloads/links) here: http://www.artistic.ca/dteed/tftpboot-udpcast.htm This might be useful for those who have wanted to 'boot net' a Sun sparc and use Udpcast from there. Enjoy... --Donald Teed

1 1

Another DHCP config question
by Donald Teed 03 Nov '04

03 Nov '04

The documentation I'm finding for DHCP is not very systematic in its approach. So I'm seeking help on this list... I'd like to have DHCP point to different PXE boot menus depending on what subnet the client is coming from. The config I've tried already is something like this: subnet 192.168.1.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.1.2 192.168.1.3; next-server 192.168.1.1; class "pxe1" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; filename "/pxe1/pxelinux.0"; # Uncomment } } subnet 192.168.2.0 netmask 255.255.255.0 { range dynamic-bootp 192.168.2.3 192.168.2.4; next-server 192.168.1.1; class "pxe2" { match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; filename "/pxe2/pxelinux.0"; # Uncomment } } This isn't exactly the configuration on our live DHCP server, but it should artificially reproduce the problem I want to handle, which is making two subnets refer to the TFTP server. What I see with this configuration is that one connection to TFTP goes ahead and boots OK, and then I get errors that there are "no free leases" available. In this testing with this configuration, I'm never seeing a client assigned 192.168.2.* It behaves as if the match is made and then it cannot move onto the next subnet block where there is also a good match. --Donald Teed

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast November 2004