[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Marinetti over LocalTalk/Appletalk?



andrew.roughan@writeme.com (Roughana) wrote in message news:<f6ab8a2f.0202142044.1ff3d1a8@posting.google.com>...
> jalapeno1@mac.com (jalapeno) wrote in message news:<2f367031.0202071539.76264050@posting.google.com>...
> > Maybe Andrew's IIGS isn't seeing the IPNetRouter as an IPGATEWAY? 
>  ...
> > Can Phil and/or Andrew download the file called "lk" and run it from a
> > shell (like ORCA Shell, it's an exe not a s16) on their IIGS's and see
> > if IPNetRouter is responding as an IPGATEWAY type?
> 
> I ran the lk utility from Orca Shell.
> Immediately after running, the machine crashed into GSBug and I was
> not able to clearly see the output screen.

Eh, that figures with a 15 minute hack in ORCA/C :)

> This is what I think I could decipher:
> 
> ---
> Error Return Code is 0
> Error returned is 0
> The number of entities is 4
> Entity 0 is 192.168.1.1:IPAddress@*
> Entity 1 is Macintosh 1400: ARA-Client-Only@*
> Entity 2 is Macintosh 1400:Macintosh-Powerbook@*
> Entity 3 is Macintosh 1400:Workstation@*
> 
> Error #1 in tool 17
> ---
> 

Ok, it looks like you got the desired info before the crash. I'm at
work and don't have access to my IIGS references so I don't know what
error #1 in tool 17 is (that didn't come from my program, that
probably came from GS/OS or sys 6.0.1, or maybe the program had a few
bytes zapped while travelling across the Internet). The good news is
that no error came back from the Appletalk calls (the zero's confirm
that). The number of entities in the table is 4 and you got 4
responses which read like this:

Object name  :  Object type  @ Zone

so the crash is due to the tool 17 error, I guess (it doesn't crash on
my IIGS, though). For a quick hack the crash isn't that important
because you got the info I was looking for with the program.

> This output was received with IIgs Rom 3 running appletalk in printer
> port (Slots 1 & 7 set to Appletalk)
> Macintosh 1400 running MacOS8.1 with Appletalk turned on through
> Alternate Ethernet. File sharing off.
> IPNetRouter running with MacIP interface up.
> (Upon reflection, I'm not sure how the IIgs managed to communicate
> with the Mac if the Mac's Appletalk was switched to Alternate
> Ethernet. Perhaps, I still had LocalTalk Bridge running.)
> 

The Object type "IPAddress" looks to be either how IPNetRouter is
registered on your Appletalk Network or more likely how your MacTCP
(or OpenTransport) client software is registered. I take it that your
Mac is set with 192.168.1.1 as the IP address?

The Object type "ARA-Client-Only" could be your Localtalk Bridge or
(more likely) your printer?

The other two are normal for your Mac.

> I ran lk both before and after establishing a Marinetti connection
> with MacIP Link Layer. The output appeared to be the same.
> 

Yes, that is to be expected because the lk program just does a NBP
lookup of everything registered on the local Appletalk network. It
only prints responses from other machines, not from your machine (this
is how the Appletalk protocols are implemented on the IIGS and lk just
sends out an "=:=:*", the "=" being a wild card for everything and the
"*" being the local network). If you had 2 IIGS's on the Localtalk
network then they would see each other but they can not see themselves
(unfortunately it can make debugging harder if you only have one IIGS
and no packet sniffer).


> Today, I reconfigured the Mac to remove Localtalk Bridge and changed
> Appletalk to use the Printer Port on the Mac.
> I also fiddled around with IPNetRouter to get Ethernet and MacIP
> routing "up".
> 
> I ran lk and got this:
> ---
> Error Return Code is 0
> Error returned is 0
> The number of entities is 3
> Entity 0 is 192.168.1.1:IPAddress@*
> Entity 1 is Macintosh 1400:Macintosh-Powerbook@*
> Entity 2 is Macintosh 1400:Workstation@*
> 
> Error #1 in tool 17
> ---
> 

The "ARA-Client-Only" disappeared so that confirms it was either your
Localtalk Bridge or the printer. Since you removed both it doesn't
really matter.

> I looked at MacPing (which tests Appletalk and IP networks). On the
> Appletalk network, the IIgs was seen as Apple IIgs:Andrew Roughan (it
> gets the user name from the Appletalk CDEV).
> 
> I connected Marinetti with MacIP Link Layer.
> After doing this, MacPing could see that the IIgs naming info had
> changed.
> As well as AppleIIgs:Andrew Roughan, MacPing had an alternate entry
> IPADDRESS:192.168.1.2.
> (I had entered 192.168.1.2 into the Marinetti MacIP configuration
> dialog.)
> 

This means that Marinetti's MacIP layer is registering itself on the
Localtalk network correctly. This doesn't say anything about the IP
packets yet, though. Do you have the source code for Marinetti's MacIP
link layer? Is the source for IPNetRouter available?

> I reran lk and got the same output as above.
> I was expecting to see an additional entry for the IIgs IPADDRESS.
> 

Yeah, you would think so, but the IIGS can't see itself via a NBP
lookup. Put another IIGS on the network, then run lk and you'll see
the Marinetti MacIP link layer registration (the "IPAddress" type) for
your first IIGS as well as the "APPLEIIGS" workstation type. Funny
thing, MacPing seems to reverse the Object name and Object type in
it's display. No biggy, though, does MacPing sort by Object type? That
could explain the reversal.

Appletalk uses a concept called NVE (network visible entity) because
client and server addresses are dynamic to a network. The address is
obtained when the client registers on the network. I suppose Apple (or
the Apple IIGS network software engineers) decided that the IIGS
workstation had no reason to see it's own NVE's.

> Upon some closer reading of the IPNetRouter documentation, it appears
> as though it does not fully implement an IP Gateway.
> 

It sounds like the only things missing at this point are the assigning
of IP addresses to the Appletalk clients and maintaining a table that
maps IP addresses to Appletalk addresses. It skirts both these by
making you manually configure the IP addresses on your clients.

Can you update IPNetRouter to be a full IP Gateway? Who cares! We can
write our own IP Gateway if you have a LanceGS card. IP Gateways are
easy (famous last words ;) to program and the MacIP docs tell you what
you need to include. With a IIGS IP Gateway you can get rid of your
Powerbook and IPNetRouter all together :)

> Here's what the IPNetRouter doco says:
> ===
> IPNetRouter supports MacIP (IP in AppleTalk) as a client. This means
> IPNetRouter can build a Link Stack that will add or remove the
> AppleTalk
> wrapper for MacIP allowing LocalTalk connected devices to access
> TCP/IP
> services via IPNetRouter. IPNetRouter does not assign IP addresses to
> other MacIP hosts at this time (as a traditional MacIP gateway), it is
> necessary to configure each MacIP host manually.
> 

Ok, and you did manually configure an IP address with Marinetti.

> MacIP is Apple's way of transporting TCP/IP packets over
> Appletalk. While IPNetRouter can send IP packets to a
> MacIP interface, IPNetRouter cannot send Appletalk
> packets themselves anywhere. The Appletalk Control panel
> determines where Appletalk packets are sent.
> 

Ok, it sounds like IPNetRouter is using your Mac's OpenTransport or
MacTCP client to send via Localtalk (which does Mac OS 8.1 use, I
forget? Probably OpenTransport). That shouldn't cause a problem,
theoretically, since Marinetti's MacIP link layer looks like it is
registering its NVE properly on the Localtalk network.

> Does IPNetRouter "multihome" Appletalk?
> IPNetRouter does not effect your Appletalk network in any
> way. Whatever Apple permits Appletalk to do, it will do.
> What does this mean? This means that whatever interface
> is selected in the Appletalk control panel is the one on
> which Appletalk will be active. IPNetRouter does not use
> Appletalk, nor can it manipulate the Appletalk transport
> layer. If you are experiencing problems getting your
> Appletalk printer to work, it is extremely unlikely that it has
> much to do with IPNetRouter. The same goes for
> Filesharing over Appletalk.
> 
> Since IPNetRouter does not multihome Appletalk, how can I get
> my Appletalk printer to be shared on a routed LAN?
> If you have an Appletalk capable printer, you can use
> Apple's printsharing in many instances. You may also find
> Apple's unsupported Localtalk Bridge software to
> multihome Appletalk between an ethernet and a localtalk
> interface handy. Farallon and Asante make Localtalk to
> Ethernet converters to put a localtalk printer on an ethernet
> network.
> ===
> 
> So while there may be no IPGATEWAY, it should still do the required
> protocol forwarding. I just havent gotten it to work yet, and am stuck
> for ideas.
> I think I need to debug at packet level to get any further.

I cautiously agree. My guess is that the Marinetti MacIP link layer is
mangling the payload (the payload being the entire IP packet, in this
case, including the IP headers) or is not correctly adding the DDP
headers to the Localtalk packet which causes IPNetRouter to strip them
off incorrectly, which in itself would cause a mangling (of sorts) to
the IP packet. The only way to really tell for sure is to look at the
packets themselves.

Do you have a Localtalk packet sniffer? Actually, a IIGS packet
sniffer shouldn't be hard to write (famous last words again) since
LLAP is built into the firmware. The IIGS only does phase one
Appletalk but the LAP is only getting packets via Localtalk anyway.
You appear to have a local Appletalk network (without Zones) so being
phase one shouldn't matter there either.

Once you get a look at the packets coming from the IIGS you can better
determine where to look next.

> 
> Cheers,
> Andrew