Trouble with tftpd and dhcp and broadcom ethernet client

Donald Teed dteed at
Thu Apr 8 18:18:03 CEST 2004

Thanks for the quick reply.

I've verified the same server used with another client machine
not using this Broadcom ethernet boots problem free.
So this seems to be a DHCP problem with the Broadcom hardware
or drivers.

I found this item in a mailing list which seems to be about a similar problem:

(Slow DHCP)

Unless a newer driver for the Broadcom appears, I'll likely
go with not using the menu based client and just have it
automatically run receiver for when we are in full production.
That should avoid the second DHCP request being run.

Thanks for your help.


--Donald Teed

On Thu, 8 Apr 2004, Alain Knaff wrote:

> begin  Thursday 08 April 2004 16:19, Donald Teed quote:
> > 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...
> >                   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
> As you correctly point out yourself later in your message, this is not
> actually a dhcp message, but a tftp message. However, if you already
> got this far (udpcast menu), it means that tftp did fine anyways
> (i.e. the message is not a fatal error, but merely a warning).
> > 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"
> It's weird that you get another in.tftpd message at this point. After
> booting of the initial images (kernel+initrd), the udpcast system no
> longer uses tftp. Are you positively sure that no other clients are
> using the system? Or maybe this is not some "old" message that has
> actually been logged earlyer (use tail -f to see messages appear in
> real-time, as soon as they are added to the log...)
> It might also be interesting to have a tcpdump running in another
> window, to display packets as they are received.
>  tcpdump -s 1500 -ni eth0 port 67 or port 68
> (if eth0 is the interface to which the clients are connected)
> This displays any packets involving port 67 or 68, i.e. DHCP packets.
> You can also add "or port 69" to display tftp traffic as well.
> > 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.
> I do not actually think that tftp is the problem. The kernel and
> initrd loaded fine, or else you would not even have seen the menu.
> IMHO, the problem is with dhcpd rather than tftpd.
> Regards,
> Alain

More information about the Udpcast mailing list