How to delete second network interface after removing network device?

[theirongiant]

What is the "correct" way to remove a network interface no longer installed in a System 7 Mac? How do you remove a second network interface from the system if you removed the physical network card? It's tripping up Apple Internet Router. I don't see an obvious extension for it either.

Backstory: I installed the DaynaPort SCSI/Link drivers required to use the BlueSCSI v2 Wi-Fi interface. It's insanely great, and the desk accessory made by @jcs to choose your Wi-Fi network is delightful.

After setting up the BlueSCSI, I configured Apple Internet Router to join the GlobalTalk network. I started the router successfully at least once and saw other peoples' Appletalk zones & shares in the Chooser. After that, I shut down the Mac LC and moved the BlueSCSI to another Mac.

Now when I try to start the Apple Internet Router, it complains:

"The router was unable to start because an error occurred while installing an AppleTalk connection driver for a configured port."

AIR does show two Ethernet interfaces. I have marked the other one as Inactive. No dice. I can also see two interfaces in the MacTCP control panel, and in the "Network" control panel for AppleTalk. In those panels, there is "Ethernet (Slot 1)" and "Ethernet Alternative."

My built-in card is the Farallon Ethernet card in the PDS slot.

Also, MacPing DOES see other computers on the network when scanning by IP address, so the computer can reach the rest of the network.

Any suggestions? I don't recognize any of the Extensions as belonging to the SCSI/Link to try and remove it.

 

[halkyardo]

Are you using the same router configuration file, or have you created a new one? I saw similar errors when I tried to move the router config from one machine to another. I didn't look into it too far, and just entered a new configuration from scratch. I don't *think* it's the leftover driver from the SCSI/Link, since all my Macs have countless ethernet drivers installed for various cards that they no logner have, and it's never complained about that.

If it does end up being the leftover SCSI/Link driver, you'll have to do some surgery to your System file to remove it, as it gets installed directly into there. You'll need a copy of ResEdit to do this.

1. Boot the machine from a *different* System Folder - eg. another drive partition or a boot floppy. This is crucial, because ResEdit can't operate correctly on a System file that is in use.
2. Take a copy of the System file (File->Duplicate in the Finder) and save it somewhere just in case things go wrong.
3. Open the System file in ResEdit, and browse to the 'DRVR' resource type.
4. In the list of DRVR resources, delete any resources with the name '.ENET0'
5. Save the edited System file and restart.

 

[LaPorta]

Those DaynaPORT/Asanté drivers inject some sort of code into the System file itself (as I recently discovered myself). You need to run the original installer you used, and choose the uninstall option to remove it.

 

[cheesestraws]

do surgery with resedit or reinstall.

in general though, ask bluescsi support questions through their own channels. they prefer people not to discuss it outside of their control.

 

[theirongiant]

do surgery with resedit or reinstall.

in general though, ask bluescsi support questions through their own channels. they prefer people not to discuss it outside of their control.

Thanks.

Where would that channel be? Discord?

This kind of troubleshooting would be necessary if I had a real DaynaPort or other hardware ethernet card so I don't think it's strictly a BlueSCSI issue. It just happens to be emulating a DaynaPort SCSI/Link.

Here's the proof that the SCSI/Link driver lives inside the System bundle.

 

[davewongillies]

Where would that channel be? Discord?

From their troubleshooting page

Additional support​

If you are still experiencing an issue you can use these community powered support options to ask for help. Remember to be calm, patient, and understanding when asking for help from others.

• Open Retro SCSI Discord
• TinkerDifferent Forum
• GitHub Discussions

 

[cheesestraws]

Where would that channel be? Discord?

no idea, I don't go near bluescsi stuff, too cowboy for me.

 

[theirongiant]

Are you using the same router configuration file, or have you created a new one? I saw similar errors when I tried to move the router config from one machine to another. I didn't look into it too far, and just entered a new configuration from scratch. I don't *think* it's the leftover driver from the SCSI/Link, since all my Macs have countless ethernet drivers installed for various cards that they no logner have, and it's never complained about that.

If it does end up being the leftover SCSI/Link driver, you'll have to do some surgery to your System file to remove it, as it gets installed directly into there. You'll need a copy of ResEdit to do this.

1. Boot the machine from a *different* System Folder - eg. another drive partition or a boot floppy. This is crucial, because ResEdit can't operate correctly on a System file that is in use.
2. Take a copy of the System file (File->Duplicate in the Finder) and save it somewhere just in case things go wrong.
3. Open the System file in ResEdit, and browse to the 'DRVR' resource type.
4. In the list of DRVR resources, delete any resources with the name '.ENET0'
5. Save the edited System file and restart.

No, sir. I created a new one from scratch and re-entered all 70+ IP addresses from the GlobalTalk spreadsheet by hand. (Why oh why isn't there a keyboard shortcut for the "Add" button, or a way to press Tab to select it?)

I'm more certain that it's the leftover driver because, when I reinserted the BlueSCSI and booted the Mac, the AIR app gave a different error:

"The router cannot start because there is no seed router on the network connected to the Ethernet port."

PS: hi there! I connected to your server earlier this month when I had AIR running on my Mac LC III. I got another Ethernet card for the LC because I wanted to run the apps on a more powerful system and leaving the routing to a low(er) end Mac.

My PhoneNET adapters arrived today and I'm going to add a Classic II and an SE to the network (if I can get this issue cleared up!). An AAUI adapter is on the way for the Quadra 650.

 

[halkyardo]

No, sir. I created a new one from scratch and re-entered all 70+ IP addresses from the GlobalTalk spreadsheet by hand. (Why oh why isn't there a keyboard shortcut for the "Add" button, or a way to press Tab to select it?)

I'm more certain that it's the leftover driver because, when I reinserted the BlueSCSI and booted the Mac, the AIR app gave a different error:

"The router cannot start because there is no seed router on the network connected to the Ethernet port."

Interesting... I wonder if the DaynaPort driver is active whether or not there's a device for it to talk to. That could definitely foul things up, but when I wrote my own ethernet driver a while ago, it's absolutely trivial to avoid that problem, even without the aid of the Slot manager. Maybe the network drivers of the "old days" weren't as well-written as I thought they were...

Someone (kalleboo, I think?) wrote an automated tool to update router configs from a list of hosts, but I haven't had a chance to give it a go yet.

PS: hi there! I connected to your server earlier this month when I had AIR running on my Mac LC III. I got another Ethernet card for the LC because I wanted to run the apps on a more powerful system and leaving the routing to a low(er) end Mac.

My PhoneNET adapters arrived today and I'm going to add a Classic II and an SE to the network (if I can get this issue cleared up!). An AAUI adapter is on the way for the Quadra 650.

Nice!

Reminds me, I need to get myself an LC at some point so I can design a new ethernet card for those too...

 

[LaPorta]

@halkyardo Yes, it does mess things up. I had issues after my SillyTinySCSI was disconnected from my IIfx that had a built-in ethernet card and the DaynaPort drivers were still installed. That is how I knew they need to be uninstalled. I must say: patching the System file seems a very crude and bothersome way to do this...you'd think that they would have just made an extension.

In fact, I'll bet some enterprising soul here can write an Extension that just carries and loads that resource when the Extension is loaded...making it much easier to install/remove on the fly.

 

[theirongiant]

The presence of the extra interface without a physical connection (or any way to talk to the network) meant that the desktop would never load. I had the same issue when I moved the LC and forgot to reconnect the Ethernet cable to the internal card.

Purging the driver from the system file worked. The extraneous interface is gone. However, that wasn't the end of the trouble.

I also had to boot with Extensions Off to remove the "Router" extension, and thus stop it from activating on boot.

On rebooting and launching Router Manager, it complained that I needed to reinstall the software. Missing extension. No problem. I moved it back to Extensions without rebooting, and started the application.

On launching Router Manager again, it told me that the router definition was referencing a non-existent interface. Acknowledged, and the document finally loaded.

The spurious Ethernet interface is no more.

After saving the router file, everything started normally!

 

[halkyardo]

@halkyardo Yes, it does mess things up. I had issues after my SillyTinySCSI was disconnected from my IIfx that had a built-in ethernet card and the DaynaPort drivers were still installed. That is how I knew they need to be uninstalled. I must say: patching the System file seems a very crude and bothersome way to do this...you'd think that they would have just made an extension.

In fact, I'll bet some enterprising soul here can write an Extension that just carries and loads that resource when the Extension is loaded...making it much easier to install/remove on the fly.

"Crude and bothersome" is a fairly apt description of the way a lot of things are in the Classic Mac OS network stack. It might work pretty well externally, but having spent a lot of time recently writing my own Ethernet driver, the internals are inelegant to say the least. The unfortunate fact is that there's a reason for some network drivers (such as the DaynaPort SCSI drivers) having to live in the System file, but it's a pretty frustrating one, and explaining it requires a bit of background on the ugliness under the hood. Beware, wall of text incoming.

Basically, there are two more-or-less independent classes of Ethernet driver - the .ENET driver stub for Ethernet devices that use the Slot Manager (e.g. NuBus or 030 PDS), and the .ENET0 driver for devices that exist outside of the Slot Manager's worldview (e.g. SCSI or 68000 PDS). Software is expected to just look for devices under both drivers, which is why you'll sometimes see a network device listed as "Ethernet (Alternate)" - some versions of the Network control panel use this to indicate a device using the .ENET0 driver.

The .ENET driver stub is by far the more 'civilised' of the two - it exists on all systems with network software installed, and when loaded, searches for an 'enet' resource whose ID matches the Board ID in the Ethernet device's declaration ROM, and loads the actual driver from there. In later versions (starting with Network Software Installer 1.4 I think?) it even looks for drivers in Extensions of type 'comd', doing exactly what you suggested, but because it is keyed off of the declaration ROM Board ID, this only works for Ethernet devices that the Slot Manager knows about.

For Ethernet devices that aren't supported by the Slot Manager, things are much more primitive. A driver for these devices must install itself as .ENET0, with no help from the operating system. And here's the sticking point: for AppleTalk to come up correctly, the Ethernet driver must already be present in the driver table before AppleTalk starts, which is very early in the boot process, before INITs get run. For Slot Manager devices, that's fine, the .ENET driver stub is always there, and when AppleTalk opens it, it looks up the appropriate driver and passes control to it. But for non-Slot Manager devices, the only practical way to make their .ENET0 driver available so early in boot, is to install it into the System file's 'DRVR' resources, so that it is always present in the driver table. Another related limitation is that while a system can happily have any number of drivers installed for Slot Manager cards, and just pick the right one based on the hardware that is installed, only one .ENET0 driver can be installed in a system at a time, as far as I can tell. Not a huge problem for most people, but it led to a bit of confusion when bringing up the driver for my ethernet card on my SE.

I know that there *are* ways to hook Extensions earlier into the boot process (e.g. by abusing language-system 'scri' extensions), and it may be possible to use these hooks to load a .ENET0 driver into the driver table before AppleTalk starts up, but as far as I'm aware these hooks were only ever intended for Apple's own use, and as such are poorly-documented and not supported on all systems. It's something I've been meaning to investigate for my own drivers, but I suspect that there's a reason that Apple and other vendors didn't do it that way.