Re: [Etherboot-developers] currticks function

[<ebi...@ln...>]

Fotis Andritsopoulos <fa...@te...> writes:

> >
> >
> >So occasionally it just times out?
> >Hmm. I would really try this with another tftp client and verify that
> >this isn't a server bug.
> >
> >Do you see retransmits from either the client or the server
> >
> 
> 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 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

No it shouldn't deal with broadcast addresses.  But how does the check
for the appropriate tftp port fail.  We should also check in software
the ip address, and the mac address (We don't need the NIC to do it).

But I'm curious how it got through the checks in await_reply.

In 5.1.2+ I have cleaned this up a little more, and I think I may have
actually implemented the check for the mac address, and the ip
address.  I know I noticed they were missing and implemented them
on another protocol I was working on.

Hmm.  I wonder if that is a bug in -DCONGESTED that it doesn't
retransmit ACKs when it receives a duplicate DATA packet.

Eric