[Udpcast] Buggy tg3 ethernet
alain at knaff.lu
Tue Apr 4 16:33:26 CEST 2006
Donald Teed wrote:
> 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
Sorry for the slow reply.
Cast-o-matic now has a way to insert a sleep before the start of udpcast
(only available with full-featured shell). Inserting a sleep of 3 seconds
should be enough to address this issue.
If you use makeImage, you can obtain the same effect by inserting a
script that sleeps 3 seconds using the --pre parameter.
More information about the Udpcast