I had originally posted in the compact mac forum, but I think this is a more appropriate place. Since switching to Daynaport SCSI networking for my SE/30 (via Zuluscsi Pico Slim) persistent volume connections are no longer working. I suspect this is because Appletalk init during boot takes place before the SCSI subsystem is available. Has anyone been able to get this working in their environment? Any suggestions for a workaround would be greatly appreciated.
-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
Persistent Appletalk connections?
- Thread starter shirsch
- Start date
Ah.. As opposed to simply checking those items in the chooser? I will try it.
Good suggestion, but it doesn't work. On restart I get prompted to authenticate for each remote volume, but that fails with a complaint that the remote volume cannot be found.
The problem may be down in the system file itself, since that's where the SCSI driver and Daynaport driver live. Is it possible to configure the startup order for system-resident drivers?
Good suggestion, but it doesn't work. On restart I get prompted to authenticate for each remote volume, but that fails with a complaint that the remote volume cannot be found.
The problem may be down in the system file itself, since that's where the SCSI driver and Daynaport driver live. Is it possible to configure the startup order for system-resident drivers?
Last edited:
If they are both DRVR resources, it may be as simple as re-ordering them in the System file via ResEdit. I know, for example, in pre-System 7 DAs are stored in the system file as DRVR resources alongside the actual drivers. By re-ordering them you can change the order they appear in the Apple menu.
It would be easy enough to test— just make sure to make a backup of your System file before playing around.
DRVR resources are read in reverse order, BTW (at least in pre-System 7), so the driver you want loaded first you’d want at the bottom of the list.
It would be easy enough to test— just make sure to make a backup of your System file before playing around.
DRVR resources are read in reverse order, BTW (at least in pre-System 7), so the driver you want loaded first you’d want at the bottom of the list.
FWIW, neither driver appears in the Apple menu. I'll do some studying on ResEdit, a tool I'm unfortunately not at all familiar with.
There's also one important difference between wired ethernet or localtalk connections and one made over Wifi. In the latter case the Appletalk session is established over TCP using OpenTransport, while ethernet and localtalk pass DDP. Is it possible that persistent sessions require DDP? For example, no zones ever appear when connected by Wifi, although remote volumes work properly.
There's also one important difference between wired ethernet or localtalk connections and one made over Wifi. In the latter case the Appletalk session is established over TCP using OpenTransport, while ethernet and localtalk pass DDP. Is it possible that persistent sessions require DDP? For example, no zones ever appear when connected by Wifi, although remote volumes work properly.
I didn’t mean to imply ACTUAL drivers will show up in the Apple menu. They do not. I was merely drawing a parallel to desk accessories because desk accessories were also stored as DRVRs at one time, in early System versions. And you could re-order them to suit your needs.
Make a copy of your System file. Open the copy in ResEdit and find the DRVR resource. If you open it, you’ll get a list of drivers contained within. See if you can get there and post a screenshot.
Also, persistent connections should not require DDP. I could be wrong, but I don’t know why that would be the case.
Make a copy of your System file. Open the copy in ResEdit and find the DRVR resource. If you open it, you’ll get a list of drivers contained within. See if you can get there and post a screenshot.
Also, persistent connections should not require DDP. I could be wrong, but I don’t know why that would be the case.
I bet you there's a timing issue at play here. Something about the combination of WiFi and IP and AFP-over-IP is slower to come up than DDP-over-Ethernet (let's face it, there are a lot of reasons here...) and it's just not ready when AppleShare needs it to be (maybe it hasn't got a DHCP lease yet?)
If you're running 7.5+, could I suggest an experiment where you use an AppleScript in the startup items folder to wait a few seconds and then open the alias?
If you're running 7.5+, could I suggest an experiment where you use an AppleScript in the startup items folder to wait a few seconds and then open the alias?
The .ENET0 driver does appear in the DRVR resource. I tried several times to get a screen shot, but all attempts yield a blank page when I load the .pict file into Preview on a modern Mac. There's a driver called .ATP that precedes .ENET0. If the ethernet device is loading after .ATP that might explain the problem. But - I also have the wired ethernet driver and that appears after .ATP as well.
Since the connection is being made as AFP over TCP/IP (OpenTransport 1.3) DDP isn't in the picture.
UPDATE: Finally figured out how to render screenshots....
Last edited:
Unfortunately, something that I did in the course of troubleshooting has broken the DaynaPORT SCSI networking completely. Need to backtrack or possibly reinstall System 7.5.5. Ugh.
Networking is back (afpd daemon crashed on server). Referencing aliases of the remote volumes still isn't working. Each one prompts me for my credentials, then gives up with a complaint that the volume is not found. I tried recording an Applescript to open the Chooser and run through the process of re-authenticating, but apparently the Applescript recorder does not follow ones activity into the application and I don't know enough about it to code this from scratch.
Try moving both the .ENET drivers above the Apple Sound stuff in your System copy by giving them IDs of, say, -16510 and -16509 respectively. Then boot using your modified System file and see if it makes a difference. Make sure to keep the unaltered one safe and easily accessible if you need to switch back.
If that doesn’t change anything, revert to your unchanged System file and make a new copy. Open the new copy, open the DRVR resource, and under View select By order in file instead of by ID. Then cut and paste both the .ENET drivers to the top of the file and try booting with that.
If that doesn’t change anything, revert to your unchanged System file and make a new copy. Open the new copy, open the DRVR resource, and under View select By order in file instead of by ID. Then cut and paste both the .ENET drivers to the top of the file and try booting with that.
Last edited:
After making this change it was not possible to select 'Alternate Ethernet' (Dayna SCSI) as the Appletalk interface. It popped up an error dialog telling me it wasn't available.
Alas, both .ENET and .ENET0 were already at the top.
I appreciate the suggestions, however, and am glad to try any other advice you might offer!
@nathall I'm not actually able to rearrange driver order in the "By Order in File" view. I can cut them, but then 'Paste' is grayed out and there's no obvious way to reinsert it. Also not finding any mention of this in the ResEdit manuals. Are there some secret undocumented commands? I'm sure I'm overlooking the obvious. Somewhere.
I think I created my own problems. Yesterday I was making a copy of the System file for backup, then rebooting from the rom simm to edit it. For whatever reason, that approach yields a grayed out paste option. Today I made a copy, moved it to another folder and ResEdit was able to rearrange the order. That's the good news. Bad news is that no matter what I tried it ended up with either non-functional Appleshare client or a working client with the same "no remount" behavior. I've asked several times on this forum and TinkerDifferent if anyone with the Daynaport SCSI interface (real or emulated) had observed a working remount but there have been no confirming replies. I'm starting to wonder if it ever actually worked at all with the .ENET0 device.
Can you think of anything else that I might try?
Can you think of anything else that I might try?
Not off the top of my head, other than cheesestraws’ script idea.
Unfortunately my ZuluSCSI does not have the Daynaport feature so I can’t really play around on my end with that piece of it.
I’d be willing to try to whip up an Applescript for you to try in the next day or so, however.
Unfortunately my ZuluSCSI does not have the Daynaport feature so I can’t really play around on my end with that piece of it.
I’d be willing to try to whip up an Applescript for you to try in the next day or so, however.
I have a workaround of sorts! It turns out that MacOS 8.1 with Modem Manager active will register on the Appletalk network and cheerfully remount remote volumes at startup. I did try using the modem manager on System 7.6.1. It loaded without complaint but does not solve the problem in that environment. The pre-built OS 8.1 image I'm using has a Dynaport SCSI driver extension which I may try using with the older system. I don't know where that comes from as the Dayna installer embeds the drive in System rather than adding an extension. Might be worth trying that with older MacOS.
