Trouble with tftpd and dhcp and broadcom ethernet client

Donald Teed dteed at
Thu Apr 8 16:19:41 CEST 2004

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

Now we get into the blue screen section and it shows:

Sending bootp request...
info, udhcpc V0.9.9_pre) started
debug, sending discover... (3 times)
info, No lease, failing


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
info, lease of 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.

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

--Donald Teed

More information about the Udpcast mailing list