Lost packets (was Re: Problem with SMC9432)

[Bill Arbaugh <waa@home.com>]

I can't speak for netboot, but I've noticed similar problems  in etherboot
.  The problem typically
happened during periods of high traffic.  The problem in etherboot is
related to a lack of buffering
in the driver and the lack of an underlying OS to handle
multitasking/interrupts.  Essentially the driver passes each packet up
that it receives to a function (can't remember the name right now) that
determines if the packet is valid. If it's not, and the valid packet
arrives during the check of the invalid packet.  You lose. Some of the
packet drivers may have the same problem.

Bill

Eibo Thieme wrote:

> Matthias Harders wrote:
>
> >         we have the same problems as described by Peter Debus
> >         in an earlier request (PCI 10/100 and netboot), that is
> >         somehow the connection between driver and netboot doesn't
> >         work properly.
> >         The packets are sent but netboot doesn't receive any.
> >
> >         * the bootp request is sent correctly and the server
> >           replies, but netboot does not receive the answer
>
> As I have exactly the same problem i would like to add to this
> description my
> experience:
>
> * tcpdump tells about the incoming request and probably correct answer.
> Both
>     request and answer are different from those of linux bootp thoug.
> These have
>     some length information attached and work without problem.
>
> * the packet debugger reveils an incoming packet, which appears to be
> only one
>     byte in length (00) which can be changed by changing the bootptab
> return address
>     broadcast to *.*.*.255 to FF.
>
> I hope someone finds out what happens here.
>
> eibo