The udpcast part is working well enough. I made a nice cast-o-matic image for PXE boot with all of the network devices we may need to support. I think cast-o-matic is the neatest think about udpcast and its tools. I'm using an initial menu in PXE boot to select how to launch udpcast (a solution suggested by Alain). For that process, DHCP client fires up and gets an address OK. The client is using a Broadcom BCM5702 based ethernet device. I select the menu item (say sender for whole disk) and then the linux kernel boots fine. DHCP gives out address 192.168.1.207 Now we get into the blue screen section and it shows: Sending bootp request... Alert info, udhcpc V0.9.9_pre) started debug, sending discover... (3 times) info, No lease, failing (OK) At the time the bootp request goes out the dhcp server shows this in the log file: in.tftpd[1902]: tftp: client does not accept options On the client, I use the OK button and see a prompt for Automatic Configuration. I select Yes for that, and I get another status screen showing that: info, udhcpc 0.9.9_pre started debug, Sending discover debug, sending select for 192.168.1.210 info, lease of 192.168.1.210 obtained lease time 2800 Again the daemon log for dhcpd and in.tftpd shows that "client does not accept options" However everything is fine on this second bootp pass. I read on Novell about the -r switch for in.tftpd to disable blksize for another Broadcom ethernet device in the same family. http://www.novell.com/coolsolutions/nnlsmag/features/a_install_via_pxe_boot_... So I've been using this to launch tftpd: in.tftpd -l -s /tftproot -vv -r blksize I'm avoiding inetd since it can stall when too many simultaneous requests come in (security feature, but no use to this situation). The -r blksize didn't change the problem. Once I manually click OK after the first bootp request and say Yes to automatically configuring with DHCP, it does work OK and udpcast works. However it would be better if the process could run without the user intervention at all of the clients. I know this isn't exactly a problem in udpcast itself, but in its surrounding environment, but I'm wondering if anyone might know if this is a problem specific to this client hardware and what might help the problem (other TFTP options to suspend, other kernel with newer driver that might avoid the issue)? There are only 2 machines on the network of my test, so there is no way another DHCP server might be answering the call. --Donald Teed