4.1c Ether Addressing Problem - (nf)

[billn at zinfandel.UUCP]

#R:sequel:-18800:zinfandel:12400031:000:1819
zinfandel!billn    Jul  1 07:56:00 1983

The description of the problem is correct, ie, on any bsd system,
the ethernet driver puts it's "own" 3 high-order ethernet address
bytes into outgoing packets.  So, the way the code is now,
any incomming packets from "other" manufacturers will get responded
to as if they were from "our" manufacturer.  Bsd currently supports
Interlan and 3com.  

Sri, I think, put in a hack to test the high bit of the high byte of
the lowest 3 bytes  of the internet address on interlan boards, and
if it was 1, send to 3com, else send to interlan.  Sigh.

The ideal solution is to do what Jim Kulp (Mr. control-Z) did in chaosnet.
In his system, chaosnet addressesa -- which can correspond to
internet addresses in bsd -- are logical only.  When the driver
gets an internet address to send to, it broadcasts to the net to see
who out there admits to being that logical address.  Either it gets
no reply or someone replys, obviously with his own specific ethernet
address.  Then the original sender stashes that address away in a table,
and uses it hence forth.  Eventually all of the hosts the current host
is talking to are known to the driver.  

The good thing is that address resolution is totally handled by the driver.
the upper level knows or cares nothing about it.  

Jim said he might push for release of this code for 4.2.  I dont know
the status, though.

In the meantime, I am implimenting a scheme where I can ioctl in
the correct ethernet address to the drivers by hand; ie, a non-automatic
version of Kulp's method.  The advantage is that it's easy and
doesnt screw up the upper levels.  The disadvantage is you have to
run around to all the hosts and change their tables when hardware moves,
and you have to have additional tables.  (/etc/etheraddrs ?).

/bill
ucbvax!unisoft!billn
zehntel!billn
northlich at sri-csl