dnb@meshugge.media.mit.edu (David N. Blank) (10/12/90)
Howdy-
Here at the Media Lab we have many a Mac networked via Localtalk.
I'm sure anyone who maintains a large site with this daisy-chained
"network" can empathize with the irritation I've had caused by one
strategically placed loose connection. I tend to use a combination
of visual inspection and Interpol which seems to take forever
sometimes to find the problem. So here's my questions:
1) How do other people go about debugging their Localtalk? What
software/hardware do you use?
2) Is there any hardware specifically designed for debugging this
network (similar to the TDR which I use for my ethernet problems)?
3) I have thought about getting a Mac to schlepp around with me to
spot test the network at different access points, but this seems to
be a bit pricey, what's the cheapest piece of Mac (or other
hardware) that will let me do this?
Please send your responses directly to me and I'll gladly summarize to
the net. Thanks muchly in advance.
Peace,
dNbmark@shiva.com (Mark D. Pesce) (10/15/90)
You've got a couple of options: The CHEAP solution: Apple makes a program called PEEK, which monitors a LocalTalk link for traffic and will capture and display packet information. This is good for determining if there are RTS/CTS problems in the network, but isn't really very good at protocol analyisis, at least, not unless you're debugging your own implementation of a protocol. The EXPENSIVE solution: Network General, Inc. makes a product called the Sniffer, which is an awesome tool for network analysis and debugging. Unfortunately, with a LocalTalk card and the appropriate software, it costs about $25,000. However, it has extensive features for packet filtering, line monitoring, etc., combined with an easy-to-use interface that makes it worth every penny, if a high-performance tool is what you need. We use both of these tools at Shiva, depending on what we're trying to debug, but it's generally a lot more convienient to launch PEEK on a Mac and take a look at what's going on on the net, than it is to schelp the sniffer over, plug it in, set it up, etc. But, sometimes, only the sniffer will do. Hope this helps. o--
bschmidt@bnr.ca (Ben Schmidt) (10/16/90)
> I'm sure anyone who maintains a large site with this daisy-chained ^^^^^^^^^^^^^ > "network" can empathize with the irritation I've had caused by one > strategically placed loose connection. I wish I knew a magic bullet to simplify LocalTalk problems too. :^( Although they don't solve LocalTalk trouble-shooting problems, here's some preventive measures, that can prevent a goodly number from occuring in the 1st place: - avoid using daisy-chained configurations. At least when the LocalTalk network is star-configured, someone unplugging his mac and taking the LocalTalk adaptor home with him doesn't segment the daisy-chain. - use active star hubs. This way if someone does daisy-chain additional LocalTalk devices off his mac drop, he doesn't lower the signal levels for all the devices on the other star hub ports. - pre-terminate the LocalTalk drops within the RJ-11 wall plate for your mac drops, and then ask your mac users not to use the terminating resistors in their LocalTalk adaptors (eg. PhoneNets or equivalent). This solves a lot of problems with users adding or removing terminators and the associated flaky network performance that this causes. - if you can, in combination with terminating resistors behind the RJ-11 wall plate, use LocalTalk adaptors (eg. PhoneNets) which have only one RJ-11 receptacle, instead of the more common two RJ-11 receptacles. Farallon makes one. Or just glue in a dummy RJ-11 plug in the unused RJ-ll receptacle to discourage daisy-chaining. - if you can afford to, place only 1 LocalTalk device on each active star hub port. If like many places, you place up to 4 LocalTalk devices on each star hub port, if anyone of those 4 users removes his terminating resistor and/or daisy-chains additional devices, he'll negatively impact not just his own mac drop, but up to 3 others sharing that hub port. - if you can't afford to give every LocalTalk device a dedicated star hub port, try to give at least network resource devices like FastPaths, filservers and printers dedicated ports. This prevents another mac user on the same port from removing his termination or daisy-chaining other devices and screwing up, not only this hub port but also anyone, anywhere on your AppleTalk network, who is trying to use a network resource on the same port. > I tend to use a combination > of visual inspection and Interpol which seems to take forever ^^^^^^^^ InterPoll's AppleTalk Echo protocol is great for checking out flakey connections. Forget those sissy default settings of 20 AEP packets at 1.5 second intervals: try 1k-2k packets at .1 intervals. (mind you, this doesn't do much for the network performance of other users). > 1) How do other people go about debugging their Localtalk? What > software/hardware do you use? Sniffer with LocalTalk interface - pricey but nice. Few bugs in the version of the AppleTalk decoder I have though. For example, "ZIP query for net x" always reports the incorrect net number. (Just convert to hex and reverse the bytes and convert back to decimal to get the net number that is actually being queried.) > 3) I have thought about getting a Mac to schlepp around with me to > spot test the network at different access points, but this seems to > be a bit pricey, what's the cheapest piece of Mac (or other > hardware) that will let me do this? Nuvotech (spelling?) makes PhoneNet-like connectors with LEDs which flash in response to LocalTalk traffic. Pretty quick and dirty check of live connections or active LocalTalk ports. Most star hubs (eg. Farallon's, UngerMann-Bass', etc) let you report statistics on each hub port. BUT THE STRATEGY I LIKE BEST WRT LOCALTALK is to avoid it like the plague. Unshielded twisted pair ethernet is dropping in price. We actively encourage purchase of modular macs and ethernet cards. Word is (rumour begins here) that Apple will legitimize the SCSI-ethernet adaptor market (eg. Dove, Compatible systems, Nuvotech, etc.) by bringing out their own, since so many of the new mac models don't have nubus slots. (rumour ends here) Ethernet gives you a fixed address which is great for tracking down machines. Once the MacTCP driver is opened by any application, that mac will also respond to IP Pings until it is rebooted. The application which opened MacTCP does not have to continue running for the Mac to continue support IP Ping. Just make something like telnet or the AGgroup's "WhatsmyAddress" the startup application and then you can always IP ping a mac. If you're on the same wire as the Mac, a good ethernet drop should result in more than 1-2 PING packets in a 1000 being dropped. And best of all, it's a lot more difficult to daisy-chain an Ethernet drop than a LocalTalk drop. :^) Ben Schmidt Bell-Northern Research, Ltd. Ph: (613) 763-3906 Information Technology P.O. Box 3511, Station C FAX:(613) 763-3283 bschmidt@bnr.ca Ottawa Ontario Canada K1Y 4H7
neff@hp-vcd.HP.COM (Dave Neff) (10/16/90)
Regarding LocalTalk problems and "Sniffer": Could someone send me some more information about "Sniffer". Just what does it do for me? Is it a software/hardware combination that consists of a board plugged into a Mac or what? Is it really worth 25K? Dave Neff neff@hpvcfs1.HP.COM