[comp.protocols.tcp-ip.ibmpc] NE1000 Clarkson PD strangeness,

mah@dec1.wu-wien.ac.at (Michael Haberler) (03/06/91)

In article <1991Mar06.004805.5386@nestroy.wu-wien.ac.at>, mah@nestroy.wu-wien.ac.at (Michael Haberler) writes:
|> (I *think* it's 2 bytes too long on the Echo reply receive, I'll have 
|> to check that again.)

Ok, I investigated some more. 

The receive length fields look perfectly fine, as compared to the 3c501 pd.

I tried cu tcp 2.2D and that WORKS FINE. It also works with the Packet Driver
version of Netwatch. And the University of Minnesota POPmail/PC package V 2.0.

:-( Now I'm confused.

karn@epic.bellcore.com (Phil R. Karn) (03/09/91)

Michael sent me some mail with the resolution to the problem, and
since I haven't seen a followup here yet, I thought I'd pass on the
new info.

It turns out that some Taiwanese clones of NE-1000 boards have illegal
Ethernet addresses in their address PROMS: they have the multicast bit
set (the low bit of the first byte). My code tests for this bit on
incoming packets and sets a "multicast" flag that affects the behavior
of IP and higher layer protocols (IP refuses to forward such packets,
ICMP error messages about them are inhibited, and TCP refuses to have
anything to do with them.)

Because of the illegal address, every incoming packet would set the
multicast flag inside NOS and causing the strange behavior.

The "right" solution to this problem is to use a different (legal)
Ethernet address on the card. I understand the Clarkson package
includes a command to change the address of an interface.

Nevertheless, to avoid future head-scratching I've added a test to the
"attach" command for the packet driver in NOS: if an illegal address
is detected, a warning is issued.

Phil