krf@wucs1.wustl.edu (Kevin Fenster) (03/13/91)
Newsgroups: comp.protocols.appletalk Subject: EtherTalk Startup & InterLan NIA310 boards Distribution: usa We are looking at Ethernet boards for a bunch of Macs in a student lab. I purchased a couple NIA310 boards from Racal/InterLan since they seemed to have a pretty good reputation, and they supposedly have a lifetime warranty on the boards (good for a student lab). We are also looking at uShare from IPT to make a Unix machine (either a Sun or Sony workstation) look like an AppleShare fileserver. We have uShare on our main Sun server for evaluation purposes. Anyway, I was using the Macs with the ethernet boards, mounting the Sun disks as AppleShare disks. But I noticed that everytime I turned my test Mac on, I would get a seemingly random route inserted into the route table on the Sun. For example, our registered internet address at Nebraska Wesleyan is 192.94.109.xxx. I have the uShare software set up as directed from IPT (thanks for the help from Victoria at IPT). When I turn the Mac on, I get a route inserted in the route table, which says something like all packets destined for 192.255.69.0 should go through the uShare EtherTalk driver (et0). If I turn the mac off and then back on, I get a different route, like 192.255.41.0. Do this enough times and you get a relly offensive looking route table. Anyway, so I start recalling my days of working with AppleTalk at the bit level and I remember that Macs use a dynamic node address assignment algorithm. I yank my copy of Inside AppleTalk from my shelf (kinda reminds you of "Twas the night before Christmas...) and confirm this and then note that the network number is not supposed to be dynamic, but rather start with the unknown network (defined to be 0 which is also the local network), and learn your network number from some gateway or server. I grab another Mac, toss another NIA310 board in it, start up Racal/InterLan's EtherScope product, and watch what happens with the packets being transmitted by the test mac when it gets powered on. The first packet to come out of the test Mac is an AARP probe packet, and it has a field in the packet which is the "Source protocol address", and in decimal dot notation it has its 4 bytes which look like 0.255.41.39. There is another field "Tentative protocol address" which has the same value. I interpret the above value to mean network 255.41 and node 39. From what I see with EtherScope and what I read in Inside AppleTalk, I seem to be getting conflicts. I would expect to see this first probe packet to have in it a "Source protocol address" and "Tentative protocol address" which looks more like 0.0.0.39. This would seem to indicate that the Mac did not know which network it was connected to, and will wait to find out from something with authority. Am I correct in what I expect to see, and am I correct in thinking that the test mac is spitting out a bogus probe packet? Note that I tried different Mac's (one a IIsi with system 6.0.7, the other a IIci with system 6.0.4) and got consistent results. I've been told that the problem is being caused by the uShare software on the Sun, but I don't understand this since the probe packet I am looking at is the first piece of data on the ethernet from the mac, and it neither the mac or the uShare sun have any knowledge of each other. Any suggestions, comments, advice, moral support would be appreciated. It gets a little intimidating when talking to some of these "bigger" companies, and their first response is "Can't be a problem; nobody else has said anything." Just need some confirmations that I am seeing something inconsistent with the specs. Sincerely, Kevin R. Fenster Nebraska Wesleyan University Lincoln, NE (402) 465-2341 E-mail: krf@wucs1.wustl.edu (pretty soon I'll have my own email on campus)