luke@tasis.utas.oz (Luke Visser) (03/03/89)
Ok here's a little problem that we've been working on but can't solve,
any ideas anyone out there?
The problem involves an AppleTalk ImageWriter (ATIW) II, AppleShare Print
Spooler, MultiGate (AT to EtherNet box) and PhoneNet.
The laboratory we have is connected via PhoneNet to the MultiGate box.
In the lab we have an AppleShare server also running the Print Spooler,
which is spooling to two ATIWs.
The problem is that in this configuration it is not spooling (the spooler
status message says it has problems communicating with the ATIW). However,
if we terminate the network so that it is not connected to the MG box
it does work ok. (So, theoretically it's not the spooler).
There is no problems at all communicating via the workstations in the
lab to outside of the lab or visa versa. (So, it shouldn't be the
network or the MG box). We tried switching channels on the MG box and
all the symptoms were the same (so, it shouldn't be the box).
Here's the interesting bit. While having Peek running on the network
(to check errors) we turned on the ATIW. Heaps of errors (approx 300)
- overruns and crc - with (usually) equal numbers of both. This is on
PhoneNet. Since we have an ATIW on LocalTalk cable I checked it out -
no errors. So we carted that ATIW up and it generated the errors.
(So it shouldn't be the ATIW.) However if we terminated the lab from
the MG box, we picked up very few errors turning on the ATIW (approx
20).
We did the standard length checks for the PhoneNet cabling connected to
MG box and they are ok.
So as far as I can tell the problem exists somewhere in the interaction
between the AS Print Spooler, PhoneNet and the ATIW. But what could it
be? Any ideas, anyone running a similar configuration? And does it
work?
Luke Visser
---------------------------------------------------------------------------
"I'm a Tasmanian" - Albert Einstein
Snail: Uni of Tasmania, Box 252C GPO, Hobart 7001, Tasmania, Australia.
ACSnet: luke@tasis.utas.oz ARPA: luke%tasis.utas.oz@uunet.uu.net
UUCP: {enea,hplabs,mcvax,uunet,ukc}!munnari!tasis.utas.oz!lukekre@cs.mu.oz.au (Robert Elz) (03/03/89)
In article <834@tasis.utas.oz>, luke@tasis.utas.oz (Luke Visser) writes: > The problem involves an AppleTalk ImageWriter (ATIW) II, AppleShare Print > Spooler, MultiGate (AT to EtherNet box) and PhoneNet. First, just for reference, a multigate is a k-box type thing, that is it started life as a Stanford "Seagate" derivative. Its distinguishing features are that its made in Australia, and that it has four localtalk connectors rather than one (that is, it can connect 4 localtalks and one ethernet). > Here's the interesting bit. While having Peek running on the network > (to check errors) we turned on the ATIW. Heaps of errors (approx 300) > - overruns and crc - with (usually) equal numbers of both. This is irrelevant to the problem, but its worth pointing out that by its very nature an overrun error detected by Peek is an error on the mac running Peek itself, not an error on the network - it just means that Peek was unable to keep up with the network. The CRC errors are generally the result of losing bytes due to the overruns. > So as far as I can tell the problem exists somewhere in the interaction > between the AS Print Spooler, PhoneNet and the ATIW. But what could it > be? The solution to Luke's problem will almost certainly be to get an updated version of Megan (the code that runs in the multigate). I have sent him mail indicating one way to do that. However, this posting actually gives me a chance to rant and rave, and flame, and generally make a nuisance of myself, about the quality of the implementation of NBP in the Appletalk Imagewriter (old or new versions). That's something I've been meaning to do for the past year or so, since I first saw this revolting piece of trash. First, notice that everything works when the multigate isn't there, and fails when it is. Since the mac with the spooler, and the printer are on the same net (it seems), unless the multigate were actually breaking the net itself (which would be pretty obvious), there's just one real difference that the addition of the gateway makes to all this - that's the way that the client (spooler in this case) uses NBP to locate the server (printer). When there's a gateway on the net, the client sends an NBP BrRq to the gateway, which then broadcasts an NBP LkUp on all nets in the appropriate zone. If there's no gateway the mac simply broadcasts a LkUp on its local net. Now, when the gateway is a multigate, this is what happens... Megan obeys all the nice layering principles that you would expect it to - a DDP packet arrives, addressed to the NBP socket in the gateway, the NBP packet inside is passed to Megan's NBP process which notices it is a BrRq, converts it to a LkUp, and then broadcasts the packet on the appropriate nets (found from its RTMP and ZIP tables). Nothing remarkable about that. The ImageWriter gets this LkUp, determines that the request is for an ImageWriter, and sends back an NBP LkUpReply, but here's the problem, rather than sending the reply back to the address in the NBP packet, it sends it back to the address that was in the DDP header it received! No other NBP implementation I have seen anywhere, running on anything, is that stupid, and its hard to see how anyone could have so botched the ImageWriter implementation. In any case, because Megan is well layered, the address in the DDP header of the LkUp it sent was its DDP address, not the address of the original client, so the idiot ImageWriter sends its reply back to the multigate, which looks at the packet, sees that its a LkUpReply responding to a LkUp that it didn't initiate, and throws the thing away. The solution to this (implemented in the current version of Megan) is to breach the layering, and have Megan send the LkUp with the DDP header containing the address of the requesting client, much as if it was simply forwarding a packet (which is really not a nice thing to do, as Megan is actually sending a new packet here). Earlier versions of Megan actually implemented this, but as a special case, only where the nbp type of the lookup was "ImageWriter", other lookups were handled properly. However the LQ ImageWriter (which uses "LQ" as the type) and Apple's spooler (which changes the type of the printer so only the spooler will be able to actually find the real printer) broke that scheme, so now Megan does the wrong thing all of the time. Its sad. kre
paul@taniwha.UUCP (Paul Campbell) (03/05/89)
In article <834@tasis.utas.oz> luke@tasis.utas.oz (Luke Visser) writes: >Ok here's a little problem that we've been working on but can't solve, >any ideas anyone out there? > >The problem involves an AppleTalk ImageWriter (ATIW) II, AppleShare Print >Spooler, MultiGate (AT to EtherNet box) and PhoneNet. I've seen a problem with ATIWs and gateways, if the NBP lookups to the zone which the ATIW is in is sent to a gateway and that gateway resends it using a type 1 (short) DDP packet, the name listener in the ATIW seems to reply to the gateway, rather than the requester address included in the NBP packet. Look for the NBP request and it's response, who is it sent to? Fortunately my gateway code has an option that lets you configure it to only generate type 2 (long) DDP packets. Paul -- Paul Campbell, Taniwha Systems Design, Oakland CA ..!mtxinu!taniwha!paul "'Give me your tired, your poor - I'll piss on them' that`s what the Statue of Bigotry sais. 'Let`s club them to death, get it over with and just dump them on the Boulevard'" - Lou Reed, "New York"