xjeldc@GEMINI.LDC.LU.SE (Jan Engvald LDC) (10/10/89)
>I have a BOOTP problem with the Clarkson 3C501 packet driver and >NCSA TN3270 software. We are using a Gould NP1 to run the BootP >program and all works well with an IBM with a 3C523 card. But when >using an IBM Model 30 w/3c501 card, I get a scambled packet with >the BootP request. The same machine works fine without BootP, that is, >when I include "myip=a_real_number" instead of "myip=BOOTP" David, If your bootp server is fast, you can't use bootp from a 3C501 card. This is because the 3C501 is a stoneage old Ethernet card, and it is even designed in violition with the recomendations in the Ethernet specifications. Quoting from DIX The Ethernet, A Local Area Network, Data Link Layer and Physical Layer Specification, appendix E: Interframe Recovery, last paragraph: Reception of an incoming frame immediately after transmission of an outgoing frame is a very important capability, even for stations which do not tend to communicate with several other stations concurrently. All stations, low performance to high performance, should allow reception of an incoming frame immediately after transmission of an outgoing frame. Well, the 3C501 can't do that, and it will miss the answer unless you have a slow server or some communication delay. I noticed this when installing packet drivers and NCSA Telnet with bootp. We mostly use WD8003 Ethernet cards, but had a few 3C501. Installation and first test went well, then I returned to one of the PCs with a 3C501 and it didn't work any longer. Checked the other PC with 3C501, and that one was also not working. The reason for this behaviour was that I updated the bootptab file after each installation. For the first test bootp didn't have the ethernet address in RAM memory, so it had to read the updated file (takes a short while). From then on, all answers for that address was from RAM memory, and thus were fast and got lost in the 3C501. In summury: Use a modern Ethernet card (3C503, WD8003, NI5210, or the like). Jan Engvald, Lund University Computing Center ________________________________________________________________________ Address: Box 783 E-mail: xjeldc@ldc.lu.se S-220 07 LUND Earn/Bitnet: xjeldc@seldc52 SWEDEN (Span/Hepnet: Sweden::Gemini::xjeldc) Office: Soelvegatan 18 VAXPSI: psi%24020031020720::xjeldc Telephone: +46 46 107458 (X.400: C=se; A=TeDe; P=Sunet; O=lu; Telefax: +46 46 138225 OU=ldc; S=Engvald; G=Jan) Telex: 33533 LUNIVER S
mrm@sceard.Sceard.COM (M.R.Murphy) (10/10/89)
In article <8910092133.AAsunic17654@sunic.sunet.se> xjeldc@GEMINI.LDC.LU.SE (Jan Engvald LDC) writes: [description of BOOTP problem with 3C501 deleted for brevity, the soul of wit] >The reason for this behaviour was that I updated the bootptab file after >each installation. For the first test bootp didn't have the ethernet address >in RAM memory, so it had to read the updated file (takes a short while). >From then on, all answers for that address was from RAM memory, and thus >were fast and got lost in the 3C501. > >In summury: Use a modern Ethernet card (3C503, WD8003, NI5210, or the like). > Or remove the update of the bootptab file after each installation. Or put a delay in the server software so that existing hardware will continue to work. Emphasis on "server" comes to mind:-) -- Mike Murphy Sceard Systems, Inc. 544 South Pacific St. San Marcos, CA 92069 mrm@Sceard.COM {hp-sdd,nosc,ucsd,uunet}!sceard!mrm +1 619 471 0655
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (10/11/89)
If this is indeed the problem, then there is another fix. Simply add another bootp server or two. That way your pc will be more than one answer and will have a higher chance of receiving one. Drew
ssw@cica.cica.indiana.edu (Steve Wallace) (10/11/89)
We (Indiana University) have been having problems using bootp with the packet driver. Using our sniffer, we found that some packets (I think short ones) produced by the 3c501 via the packet driver we not correctly formed. They may have show up as fragments, I don't remember exactly. I'll take another look and follow up with more prices information. Our Sun did not recognize these packets as being bootp requests. Steven Wallace Indiana University ssw@lavanix.bacs.indiana.edu
ssw@cica.cica.indiana.edu (Steve Wallace) (10/11/89)
In article <8910092133.AAsunic17654@sunic.sunet.se>, xjeldc@GEMINI.LDC.LU.SE (Jan Engvald LDC) writes: > >I have a BOOTP problem with the Clarkson 3C501 packet driver and > >NCSA TN3270 software. We are using a Gould NP1 to run the BootP > >program and all works well with an IBM with a 3C523 card. But when > >using an IBM Model 30 w/3c501 card, I get a scambled packet with > >the BootP request. The same machine works fine without BootP, that is, > >when I include "myip=a_real_number" instead of "myip=BOOTP" > Here's what our sniffer reports for bootp packets send from a 3C501 card. - - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - -DLC: ----- DLC Header ----- DLC: DLC: Frame 1 arrived at 07:53:56.1873 ; frame size is 120 (0078 hex) bytes. DLC: FRAME ERROR: Bad alignment DLC: Destination: BROADCAST FFFFFFFFFFFF, Broadcast DLC: Source : Station 3Com 418917 DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----- IP: IP: Version = 4, header length = 20 bytes IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 328 bytes IP: Identification = 1 IP: Flags = 0X IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 100 IP: Protocol = 17 (UDP) IP: Header checksum = 55A5 (correct) IP: Source address = [0.0.0.0] IP: Destination address = [255.255.255.255] IP: No options IP: UDP: ----- UDP Header ----- UDP: UDP: Source port = 68 (Bootp client) UDP: Destination port = 67 UDP: Length = 308 (longer than remaining frame data) UDP: Checksum = 57D9, should be 58B7 UDP: BOOTP: ----- BOOTP Header ----- BOOTP: BOOTP: Boot record type = 1 (Request) BOOTP: Hardware address type = 1 10Mb Ethernet BOOTP: Hardware address length = 6 bytes BOOTP: BOOTP: Hops = 0 BOOTP: Transaction id = 52473325 BOOTP: Elapsed boot time = 256 seconds BOOTP: BOOTP: Client self-assigned IP address = [0.0.0.0] (Unknown) BOOTP: Client hardware address = 3Com 418917 BOOTP: DLC: --- Frame too short - - - - - - - - - - - - - - - - Frame 2 - - - - - - - - - - - - - DLC: ----- DLC Header ----- DLC: DLC: Frame 2 arrived at 07:54:02.3587 ; frame size is 117 (0075 hex) bytes. DLC: FRAME ERROR: Bad alignment DLC: Destination: BROADCAST FFFFFFFFFFFF, Broadcast DLC: Source : Station 3Com 418917 DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----- IP: IP: Version = 4, header length = 20 bytes IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 328 bytes IP: Identification = 2 IP: Flags = 0X IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 100 IP: Protocol = 17 (UDP) IP: Header checksum = 55A4 (correct) IP: Source address = [0.0.0.0] IP: Destination address = [255.255.255.255] IP: No options IP: UDP: ----- UDP Header ----- UDP: UDP: Source port = 68 (Bootp client) UDP: Destination port = 67 UDP: Length = 308 (longer than remaining frame data) UDP: Checksum = 57D9, should be 58BA UDP: BOOTP: ----- BOOTP Header ----- BOOTP: BOOTP: Boot record type = 1 (Request) BOOTP: Hardware address type = 1 10Mb Ethernet BOOTP: Hardware address length = 6 bytes BOOTP: BOOTP: Hops = 0 BOOTP: Transaction id = 52473325 BOOTP: Elapsed boot time = 256 seconds BOOTP: BOOTP: Client self-assigned IP address = [0.0.0.0] (Unknown) BOOTP: Client hardware address = 3Com 418917 BOOTP: DLC: --- Frame too short - - - - - - - - - - - - - - - - Frame 3 - - - - - - - - - - - - - DLC: ----- DLC Header ----- DLC: DLC: Frame 3 arrived at 07:54:03.4018 ; frame size is 119 (0077 hex) bytes. DLC: FRAME ERROR: Bad alignment DLC: Destination: BROADCAST FFFFFFFFFFFF, Broadcast DLC: Source : Station 3Com 418917 DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----- IP: IP: Version = 4, header length = 20 bytes IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 328 bytes IP: Identification = 3 IP: Flags = 0X IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 100 IP: Protocol = 17 (UDP) IP: Header checksum = 55A3 (correct) IP: Source address = [0.0.0.0] IP: Destination address = [255.255.255.255] IP: No options IP: UDP: ----- UDP Header ----- UDP: UDP: Source port = 68 (Bootp client) UDP: Destination port = 67 UDP: Length = 308 (longer than remaining frame data) UDP: Checksum = 57D9, should be 58B8 UDP: BOOTP: ----- BOOTP Header ----- BOOTP: BOOTP: Boot record type = 1 (Request) BOOTP: Hardware address type = 1 10Mb Ethernet BOOTP: Hardware address length = 6 bytes BOOTP: BOOTP: Hops = 0 BOOTP: Transaction id = 52473325 BOOTP: Elapsed boot time = 256 seconds BOOTP: BOOTP: Client self-assigned IP address = [0.0.0.0] (Unknown) BOOTP: Client hardware address = 3Com 418917 BOOTP: DLC: --- Frame too short - - - - - - - - - - - - - - - - Frame 4 - - - - - - - - - - - - - DLC: ----- DLC Header ----- DLC: DLC: Frame 4 arrived at 07:54:06.3678 ; frame size is 122 (007A hex) bytes. DLC: FRAME ERROR: Bad alignment DLC: Destination: BROADCAST FFFFFFFFFFFF, Broadcast DLC: Source : Station 3Com 418917 DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----- IP: IP: Version = 4, header length = 20 bytes IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 328 bytes IP: Identification = 4 IP: Flags = 0X IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 100 IP: Protocol = 17 (UDP) IP: Header checksum = 55A2 (correct) IP: Source address = [0.0.0.0] IP: Destination address = [255.255.255.255] IP: No options IP: UDP: ----- UDP Header ----- UDP: UDP: Source port = 68 (Bootp client) UDP: Destination port = 67 UDP: Length = 308 (longer than remaining frame data) UDP: Checksum = 57D9, should be 58B5 UDP: BOOTP: ----- BOOTP Header ----- BOOTP: BOOTP: Boot record type = 1 (Request) BOOTP: Hardware address type = 1 10Mb Ethernet BOOTP: Hardware address length = 6 bytes BOOTP: BOOTP: Hops = 0 BOOTP: Transaction id = 52473325 BOOTP: Elapsed boot time = 256 seconds BOOTP: BOOTP: Client self-assigned IP address = [0.0.0.0] (Unknown) BOOTP: Client hardware address = 3Com 418917 BOOTP: DLC: --- Frame too short - - - - - - - - - - - - - - - - Frame 5 - - - - - - - - - - - - - DLC: ----- DLC Header ----- DLC: DLC: Frame 5 arrived at 07:54:07.3572 ; frame size is 119 (0077 hex) bytes. DLC: FRAME ERROR: Bad alignment DLC: Destination: BROADCAST FFFFFFFFFFFF, Broadcast DLC: Source : Station 3Com 418917 DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----- IP: IP: Version = 4, header length = 20 bytes IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 328 bytes IP: Identification = 5 IP: Flags = 0X IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 100 IP: Protocol = 17 (UDP) IP: Header checksum = 55A1 (correct) IP: Source address = [0.0.0.0] IP: Destination address = [255.255.255.255] IP: No options IP: UDP: ----- UDP Header ----- UDP: UDP: Source port = 68 (Bootp client) UDP: Destination port = 67 UDP: Length = 308 (longer than remaining frame data) UDP: Checksum = 57D9, should be 58B8 UDP: BOOTP: ----- BOOTP Header ----- BOOTP: BOOTP: Boot record type = 1 (Request) BOOTP: Hardware address type = 1 10Mb Ethernet BOOTP: Hardware address length = 6 bytes BOOTP: BOOTP: Hops = 0 BOOTP: Transaction id = 52473325 BOOTP: Elapsed boot time = 256 seconds BOOTP: BOOTP: Client self-assigned IP address = [0.0.0.0] (Unknown) BOOTP: Client hardware address = 3Com 418917 BOOTP: DLC: --- Frame too short Notice that the UDP length and checksum are wrong for each frame. It's as if the packet driver was not padding the frames correctly. Here's what a good and working bootp frame looks like (from 3C523 cards). - - - - - - - - - - - - - - - - Frame 1 - - - - - - - - - - - - - DLC: ----- DLC Header ----- DLC: DLC: Frame 1 arrived at 08:12:13.7023 ; frame size is 342 (0156 hex) bytes. DLC: Destination: BROADCAST FFFFFFFFFFFF, Broadcast DLC: Source : Station 3Com 756558, test bootp DLC: Ethertype = 0800 (IP) DLC: IP: ----- IP Header ----- IP: IP: Version = 4, header length = 20 bytes IP: Type of service = 00 IP: 000. .... = routine IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 328 bytes IP: Identification = 1 IP: Flags = 0X IP: .0.. .... = may fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 100 IP: Protocol = 17 (UDP) IP: Header checksum = 55A5 (correct) IP: Source address = [0.0.0.0] IP: Destination address = [255.255.255.255] IP: No options IP: UDP: ----- UDP Header ----- UDP: UDP: Source port = 68 (Bootp client) UDP: Destination port = 67 UDP: Length = 308 UDP: Checksum = 8660 (correct) UDP: BOOTP: ----- BOOTP Header ----- BOOTP: BOOTP: Boot record type = 1 (Request) BOOTP: Hardware address type = 1 10Mb Ethernet BOOTP: Hardware address length = 6 bytes BOOTP: BOOTP: Hops = 0 BOOTP: Transaction id = 474B3325 BOOTP: Elapsed boot time = 256 seconds BOOTP: BOOTP: Client self-assigned IP address = [0.0.0.0] (Unknown) BOOTP: Client hardware address = 3Com 756558, test bootp BOOTP: BOOTP: Host name = "" BOOTP: Boot file name = "" BOOTP: BOOTP: [Vendor specific information] BOOTP: Anyone know of a fix for this? Is it a bug in the packet driver? thanks Steven Wallace Indiana University ssw@lavanix.bacs.indana.edu
ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) (10/12/89)
> Excerpts from internet.pcip: 11-Oct-89 Re: Bootp and 3C501 Steve > Wallace@apple.com (10653) > Anyone know of a fix for this? Is it a bug in the packet driver? As I said in a previous note, it's a bug in the packet driver which is caused by the incredible stupidity of the 3c501. It's interesting to see a real Sniffer trace of the problem after all these years. Drew
nelson@sun.soe.clarkson.edu (Russ Nelson) (10/12/89)
In article <sZB4cku00UoJI0cJJ6@andrew.cmu.edu> ddp+@ANDREW.CMU.EDU (Drew Daniel Perkins) writes: > Excerpts from internet.pcip: 11-Oct-89 Re: Bootp and 3C501 Steve > Wallace@apple.com (10653) > Anyone know of a fix for this? Is it a bug in the packet driver? As I said in a previous note, it's a bug in the packet driver which is caused by the incredible stupidity of the 3c501. It's interesting to see a real Sniffer trace of the problem after all these years. That's interesting, because I use the exact algorithm used by Phil Karn in his TCP/IP code (that's why the packet driver's copyright is attributed to him--give credit where credit is due). So if there's a bug, it's also in Karn's code (give blame where blame is due. :-)). I'll tell him about it. -- --russ (nelson@clutx [.bitnet | .clarkson.edu]) Live up to the light thou hast, and more will be granted thee. A recession now appears more than 2 years away -- John D. Mathon, 4 Oct 1989.
tdavis@unocss.UUCP (Thomas Davis) (10/12/89)
Interesting.. I've also seen the same problem with the 3c501
cards, with the packet drivers. We are running bootp on a VMS machine
under Wollogong TCP/IP. Now, without the packet drivers, it works.
So it _is_ the packet driver. Unfortunely, we don't have a sniffer
here at UNO (and we don't know anybody with one). Oh, I also remember
now that when I was playing with it, (packet drivers and bootp), our
bootp daemon would see the packets, reply to them, but the packet drivers
would ignore them.
Tom Davis,
EET TA, University Of Nebraska Lincoln @ Omaha Campus