rbk@sequel.UUCP (06/23/83)
The manual pages for 4.1c ethernet drivers specify that they fill in the 48-bit destination field in the packet with their *own* high-order 3-bytes, and 3-bytes of (low-order) destination address. The sources are consistent with this. This seems to imply that all the ethernet boards in your collection of systems must come from the same manufacturer, unless you have gateway(s). This is an undesireable restriction. Is this an accurate description of the problem? It seems that the inet code uses "struct sockaddr_in" to indicate addresses, and this contains a "struct in_addr" which uses a single (unsigned) long to store the address. There are comments that suggest this is "old style" inter-net addresses. Hence the questions: is this problem going to be fixed in 4.2? If not, does anyone have ideas on how to fix it? My fear is that changes might propogate throughout the TCP/IP code, due to the unusual size of the necessary addresses. -- Bob Beck Sequel Computer Systems ...ogcvax!sequel!rbk (503)627-9809
billn@zinfandel.UUCP (07/02/83)
#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@sri-csl
shannon@sun.UUCP (Bill Shannon) (07/07/83)
Bill Croft here at Sun implemented an Address Resolution Protocol for 10Mb Ethernet. His code will be in 4.2bsd. Unfortunately it does not allow you to talk to systems that are not running ARP, such as BBN TCP/IP or 3COM UNET. We may have to insert the old kludges if we can't get them to adopt ARP. Bill Shannon Sun Microsystems Inc.
jdd@allegra.UUCP (07/07/83)
Unisoft!billn's for automatic address resolution from Internet addresses to
Ethernet addresses, a la Chaosnet, is neat and nifty \but/ would only allow
4.1c systems to speak to other 4.1c systems! If you wanted a 4.1c system to
speak, say, to a VMS system, you'd be out of luck.
UNET does it better: it has a file of explicit correspondences between
Internet names and physical network names. You can (i.e., have to) edit
this file to set up any correspondences you like. When we were using just
UNET, we assigned our hosts numbers 1, 2, 3, ...; now we're having to go
back and assign their logical addresses based on their physical addresses,
which is a real drag.
Cheers,
John ("The Future Is Fun") DeTreville
Bell Labs, Murray Hillsam@ucbvax.UUCP (07/08/83)
Using a static mapping was long ago shown (through practical experiences) to be infeasible. A dynamic mapping scheme is the only way to handle such problems as multi-homed hosts (suppose a host splits time between network addresses, are you going to modify your mapping files every 2-3 hours?). Jim Kulp's algorithm is strongly based on ARP, if it isn't exactly ARP (he called me a few months back and described what he was going to do, it may have changed since then.) Standards are useful things if created with foresight and not too heavily influenced by politics. ARP appears to have won substantial backing in the Internet world which may result in many government locations requiring ARP support in any network oriented product purchased. 4.2 uses Bill Croft's ARP code for 10Mb/s Ethernets and some of the people that wrote interface drivers for other hardware devices have indicated they are likely to write the necessary code needed to make their interfaces use ARP. The bottom line is that if you run 4.2 on a 10Mb/s Ethernet and want another machine to talk to it, that machine is going to have to support ARP, or you're going to have to rip apart various pieces of the system. I suspect people will find it more attractive to implement ARP. Sam Leffler (finally starting to find time for things other than 4.2)
joe@cvl.UUCP (07/08/83)
Huh? The latest version of BBN TCP/IP does support the Address Resolution Protocol, in the interlan driver at least. This version may not have been announced/released to the world at large, however. If 4.2 is really being released this month, though, it seems silly to worry about BBN TCP/IP.
billn@zinfandel.UUCP (07/09/83)
#R:sun:-28100:zinfandel:12400033:000:77 zinfandel!billn Jul 8 08:25:00 1983 re availability of Croft's Address Reslolution Protocol in 4.2: Yay! /bill