[Udpcast] Buggy tg3 ethernet

[Alain Knaff]

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.

Regards,

Alain