berger@andromeda.rutgers.edu.rutgers.edu (Theresa Berger) (02/20/90)
I've got two Novell networks (ANetware '286 v.2.15C) using 3Com 3C501 cards in the workstations. These networks also talk to the rest of the world via NCSA Telnet. I'm using what I believe is the current Clarkson packet driver for the 3C501 (dated 11/15/89). Bootp does not work with the packet driver, as far as we can tell the request never hits the wire. If I boot the PC standalone without the packet driver, bootp works fine, so the bootp servers are doing their job. In labs that are configured the same except for NI5210 cards in the workstations, I can get the packet driver & bootp working together off the Novell server, so the problem is the 3C501. We absolutely can't afford to replace the 3C501 cards in the two labs. Is there any solution, such as an update to the 3C501 packet driver that will let it send bootps, or should I just give up and find a better workaround? BTW, why doesn't it work? Theresa Berger
jbvb@VAX.FTP.COM (James Van Bokkelen) (02/20/90)
You need to do special hacks on the 3C501 driver in order to allow it to send a broadcast packet longer than X bytes without an error. You see, the card has only one packet buffer, and it sees this packet going out that it wants to receive, and it gets unhappy.... I think these fixes might be deducible from the CMU PCIP 3C500 driver, because people there first encounterd the problem. I don't know if they might also be found in the Harvard version. James B. VanBokkelen 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 fax: (617) 246-0901
nelson@sun.soe.clarkson.edu (Russ Nelson) (02/22/90)
In article <9002201509.AA22868@vax.ftp.com> jbvb@VAX.FTP.COM (James Van Bokkelen) writes:
You need to do special hacks on the 3C501 driver in order to allow it to
send a broadcast packet longer than X bytes without an error. You see,
the card has only one packet buffer, and it sees this packet going out
that it wants to receive, and it gets unhappy....
Yes, that seems to be the problem. Now that I have ready access to a 3c501
again, I'll have a go at fixing it.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problemsnelson@sun.soe.clarkson.edu (Russ Nelson) (02/23/90)
In article <Feb.19.16.37.22.1990.7792@galaxy.rutgers.edu> berger@andromeda.rutgers.edu.rutgers.edu (Theresa Berger) writes:
I'm using what I believe is the current Clarkson packet driver for
the 3C501 (dated 11/15/89). Bootp does not work with the packet
driver, as far as we can tell the request never hits the wire.
BTW, why doesn't it work?
This is what happens:
The send_pkt routine transmits the broadcast packet. The 3c501 tries
to receive the packet. It will generate an interrupt that reports an
error. The error will indicate that a packet was received while a
packet was being sent. The interrupt routine nukes the packet being
sent (I think). The correct solution is to keep the interrupt
routine from nuking the packet. The enclosed solution waits for
the packet to finish being sent while keeping interrupts off. Icky,
but it works.
Insert the following code fragment immediately before the "clc" that
is immediately before the last "ret" in send_pkt. Reassemble.
mov bx,20000 ;try this many times.
send_pkt_4:
in al,dx ;if not busy, exit.
and al,IE_XMTBSY
je send_pkt_5
dec bx
jne send_pkt_4
mov dh,CANT_SEND ;timed out, can't send.
stc
ret
send_pkt_5:
--
--russ (nelson@clutx [.bitnet | .clarkson.edu]) Russ.Nelson@$315.268.6667
Violence never solves problems, it just changes them into more subtle problems