Re: First experience with Netboot 0.6.0 remote booting

[George Shin <gshin@ix3.ix.netcom.com>]

At 08:43 AM 6/25/97 GMT, you wrote:
>This is the result of a bug in your packet driver. The bootrom asks the
>packet driver about it's MTU size using function 10h, which is what the
>specs call a high performance function. If the packet driver is too old,
>it doesn't have this call, and should therefore return with the carry
>flag set. This condition is checked in the bootrom. However, since that
>error message came out, your packet driver returned successfully to that
>function call, but since it can't support the function it returned illegal
>values. You are the first one who reported such a problem to me.
>
I'll ask the vendor to see if they are handling the function 10H
correctly.  As you stated, if the call to that function completed
successfully (i.e. without carry flag set) then that function
should be supported.  It doesn't make sense for the packet driver
to return good status on call to function 10H and at the same time
return illegal values.

>No, the current Packet Driver Spec. version is 1.09! Actually, I never
>used an older packet driver, as I don't have one. Would it be (legally)
>possible for you to send me your packet driver so that I can take a look
>at it? (Please uuencode it before sending). Thanks for your help.
>
I'll check with the vendor to see if i can get the source to their
packet driver and i'll e-mail to you uuencoded.  You are definitly
better off to analyze the packet driver source.

>No, the timeout is handled the way prescribed by the relevant RFC. A bit
>mask is shifted left for every retry, and a random value is masked with this
>bitmask and then used as the timeout in seconds (in the call to udp_read the
>timeout value is multiplied by 18 to convert it into timer ticks). The number
>of retries is in fact 32.
>Ok, I just removed the network cable from one of my clients and in fact it
>seems that the timeout is not increasing as it should. I will investigate
>this further, and let you know.
>
Okay and good to hear that you were able to duplicate the problem at
your end.

>No, it isn't adjustable. What do the others think about an infinite number
>of retries? There is still the option of pressing ESC to get out of the BOOTP
>loop and let the client boot from the floppy, so this might not be a bad idea.
>
Yes, i'm all for it.  The fact that you already provide the method to
get out of the bootp loop is great and this should be used in the event
of an attended remote booting of clients.

Thank you very much for your assistance,

-gshin