NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/bsd/5233

Internet Message Format | 1992-09-08 | 5.9 KB

Xref: sparky comp.unix.bsd:5233 comp.protocols.tcp-ip.ibmpc:5090
Newsgroups: comp.unix.bsd,comp.protocols.tcp-ip.ibmpc
Path: sparky!uunet!cs.utexas.edu!torn!cunews!revcan!latour!mcr
From: [e-mail] (Michael Richardson)
Subject: Re: [386bsd] NS8390 ethernet evaluation board
Message-ID: <[e-mail]>
Followup-To: comp.unix.bsd
Summary: first byte isn't transmitted
Keywords: 8390, NE2000, 386bsd
Organization: Sandelman Software Works, Debugging Department, Ottawa, ON
References: <[e-mail]>
Date: Mon, 7 Sep 1992 00:45:47 GMT
Lines: 126

[  I'm going to followup to my own article with a number more details.
  I sat and studied my /usr/lib/newsgroups wondering where NS8390
gurus would hangout, and considered cross-posting to sci.electronics,
but since I don't have it here right now, and it has been over a year
since I last read it, I'll refrain. Since the 8390 chip seems to show
up on nearly every ISA ethernet card I've seen recently, I'm hoping
tcp-ip.ibmpc will snag a couple more people who've written drivers for
it. ]

In article <[e-mail]> [e-mail] (Michael Richardson) writes:
>  I have two National Semiconductor (Nominal Semidestructor? cute comment)
>network evaluation boards. These are 8 bit cards with 8k of ram, an 8390 and
>associated logic. I have placed one in my 386 running 386bsd 0.0
>(I will be going to 0.1 when my network starts working) The other is
>sitting in my Amiga 2000 (via GoldenGate).

>  The 386bsd's hostname is bud. (as in _Married With Children_)
>  Further data:
>    3/60 (latour): 192.139.46.129, 08:00:20:06:22:c6
>    Jolix (bud):   192.139.46.130, 08:00:17:40:0b:d4

  (latour runs SunOS 4.1.0. I have made sure it has the right
broadcast address. I also swapped ethernet cards, and the new one is
8:0:17:40:c:ab)

>  There are no other machines on the thinnet segment which is all of
>two feet long (although six inches would do the trick)

  One person suggested that my segment should be at least 6 feet long,
and that I was setting up standing waves. The ethernet guru at work
suggested that was only true for thicknet, but lent me some more cable
anyway.

  I have been monitoring the cable with etherfind on the 3/60.
  I invoke it as: etherfind -i le0 -x -v -d greater 1
  to get all the packets dumped.

  Invoking `ping latour' on the 386BSD machine. I see:

ip arp request from bud.sandelman.ocunix.on.ca(8:0:17:40:c:ab) for latour.sandel
man.ocunix.on.ca
 00 ff ff ff ff ff 08 00 17 40 0c ab 08 06 00 01
 08 00 06 04 00 01 08 00 17 40 0c ab c0 8b 2e 82
 00 00 00 00 00 00 c0 8b 2e 81 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 10 30 20


  Oops, what is that 0x00 doing at the beginning? I have been dumping
the packets that I am writing into the 8390 memory, and checking that
what I wrote is properly there. It is in fact an 0xff. I am starting
this on a 256 byte page properly. If I start one byte further, I get
the whole packet (offset by a byte, therefore nonsense)
  I can get a different packet transmitted by ping the 386bsd machine
from the 3/60, therefore priming the 386bsd's arp cache with the
3/60's hardware address.

latour% ping bud
bud% ping latour

  and I see:



ip arp request from latour.sandelman.ocunix.on.ca(8:0:20:6:22:c6) for bud.sandel
man.ocunix.on.ca
 ff ff ff ff ff ff 37 20 31 61 20 30 08 06 00 01
 08 00 06 04 00 01 08 00 20 06 22 c6 c0 8b 2e 81
 00 00 00 00 00 00 c0 8b 2e 82 0a 0a 00 00

ip arp reply from bud.sandelman.ocunix.on.ca(8:0:17:40:c:ab) for latour.sandelma
n.ocunix.on.ca(8:0:20:6:22:c6)
 00 00 20 06 22 c6 08 00 17 40 0c ab 08 06 00 01
 08 00 06 04 00 02 08 00 17 40 0c ab c0 8b 2e 82
 08 00 20 06 22 c6 c0 8b 2e 81 34 20 30 30 20 30
 32 20 30 38 20 30 30 20 31 37 20 34 00 00 00 00
 61 fc 00 00

ICMP from bud.sandelman.ocunix.on.ca to latour.sandelman.ocunix.on.ca echo 64 da
ta bytes
 45 00 20 06 22 c6 08 00 17 40 0c ab 08 00 45 00
 00 54 00 3b 00 00 ff 01 dd 53 c0 8b 2e 82 c0 8b
 2e 81 08 00 ad c7 38 00 05 00 45 24 aa 2a 30 e6
 02 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35
 36 37 33 31 30 30

  In otherwords,
   a) the two machines can both transmit on the wire.
   b) the 386bsd machine can recieve, recognize its address, and
respond to the arp request.
   c) the 386bsd machine can send onto the wire.

  I also assume that that the CRCs are correct, or the packets would
have been dropped, (although I see nothing that says that /dev/nit and
etherfind can't also see dropped packets, I don't see anything that
says they can receive it. In fact the warning to the -d flag suggests
that they can't)

  Notice that the first byte is always == the 14 th byte. I did an
experiment. On the 386bsd machine I set the 14th byte to the first
byte. Lo, and behold, the first byte is now correct. I swapped them
outright --- nope. The 14th byte is transmitted anyway.
  I note that the 14th is the first byte of the actual data (as far as
the ethernet is concerned. It is not data for the higher level
protocols unless trailers are on).

  i) Do I have a bad (or rather two) 8390? Could these be part of a
bad run?
  ii) do I perhaps have some kind of debugging or diagnostic mode on?
(Nothing I can find in my 1992 edition of the NS lan data book
suggests anything)
  iii) I don't think that it is bad memory since I can receive things
okay, and having byte #14 bad would sort of mess everything up. I have
tried moving the transmit buffer around in memory (which is from
0x2000 -> 0x3fff) to no avail.

  iv) I going to call my local NS rep on Tuesday and I'll report back
then.

--
   :!mcr!:            |  The postmaster never | So much mail,
   Michael Richardson |    resolves twice.    |  so little time.
HOME: [e-mail]     Bell: [phone]
SCHOOL: [e-mail]