Re: [Etherboot-developers] currticks function

[<ke...@us...>]

>The retransmissions are occured by the tftpd server because the 
>etherboot does not send an ACK. However, I solved the problem by a 
>non-formal way. I set a breakpoint to the point that the tftp reads the 
>nic.packet struct
>
>        tr = (struct tftp_t *)&nic.packet[ETH_HLEN];
>
>I realized that even if it waits for a DATA block (or an OACK), the tr 
>struct gets data from broadcast MAC addresses (in the tftp function). 
>Thus, the tftp checks in this packet for an OACK or DATA field and it 
>fails. It is not very clear to me if it is right to this point to find 

But in this case it should just throw away the packet and wait for
another packet.  I don't know what your logic looks like but maybe you
should look at it again.

>data with broadcast addresses. So, at the beginning of the tftp function 
>I reconfigure the cs89x0 chip to process only packets with individual 
>MAC addresses. Therefore, in the driver I use the
>
>#define DEF_RX_ACCEPT (RX_IA_ACCEPT | RX_BROADCAST_ACCEPT | RX_OK_ACCEPT)
>
>and in the tftp function I use the
>
>#define DEF_RX_ACCEPT_AFTER (RX_IA_ACCEPT | RX_OK_ACCEPT)
>
>to reconfigure the chip, so as all the packet that will be processed 
>will have as destination only the MAC address of the development board. 
>The problem solved by I don't thing that this is the right way.

This will work but is not the ideal solution. Although I have not seen
one, it is possible for bootp servers to reply by broadcast, if they are
not able to create raw packets or inject an entry into the ARP cache. So
Etherboot has to accept broadcast also.