Search results

If possible, can you create a new folder and try sharing it? Netatalk versions prior to 4.1 didn't use native macOS resource forks and FinderInfo. Just trying to rule that out as a conflict. Also to advise you that your old shares are going to lose that information if mounted with the newer...

They should all be rebranded C-Itoh 8510 printers.

When the container is in this weird state, can you attempt to startup python's built in web server in the container and see if it binds to a listening port? Also check that you can connect to it from a machine on your network.

afpd forks child processes to service a client, that's why you are able to maintain a connection. The child process continues to work fine, but if you try to reconnect or connect new clients, the main process won't respond because it is unable to open up TCP port 541 to listen for new...

The sockets thing would be how many sockets Netatalk, specifically afpd, has open (both listening and active clients). The "resource not available" message points to the DDP listening socket (128) somehow becoming unavailable, which is triggering afpd to restart. Somehow after the restart, it...

Is there anything else AppleTalk/DDP running on that machine/interface? I'm not too familiar with Docker, does it's NIC passthru use the host's MAC? This behavior is certainly odd. The other possibility is that you are running out of listening sockets. How many connections are being made to...

I'm seeing references to a host called "saturn" in your past nbplkup queries sharing the same AppleTalk address as Pluto. Is there more then one docker container running netatalk or is the host itself running netatalk? That would case binding errors as the container can't open up listening ports...

Disable AppleTalk and see if the problem still occurs. The "asp_getsession" error is from afpd not initializing AppleTalk sockets correctly. The best I can tell is something is clobbering the NIC in the container so that it appears "busy/unavailable" whenever a device tries to bind and open a...

The device name is "mswinpr2", which your build has support for. https://ghostscript.readthedocs.io/en/latest/Devices.html#ms-windows-printers

Ghostscript has a GDI output option on Windows, so it can print to literally any Windows printer.

PCMacLan's print spooler has rudimentary support for passing Postscript jobs to Ghostscipt automatically. Of course the manual doesn't document it at all.

You can "create" a Postscript printer under Windows using Ghostscript and a tool called RedMon. This works similar to how Linux and CUPS along with CUPS Filters converts Postscript jobs into native printer formats. The latest version of PCMacLAN (9.1) supports Windows XP and still works with...

Only Linux and NetBSD have actively maintained support for AppleTalk /DDP.

macOS hosts don't support AppleTalk/DDP.

Hopefully this results in the terribly broken firmware in these devices getting fixed. There were rumors that a later revision existed to fix the problems, but it hasn't shown up.

To clarify, Netatalk 4.1.0 can store/retrieve the resource fork of files natively on macOS hosts without the need of "._" AppleDouble files. Additionally, Netatalk will now natively read and sync any FinderInfo data (File Type/Creator data, labels, etc.) it finds on the host file system.

I'd solder on a PCB directly on top of the footprint of the removed HDI-45, just push the pins directly into the holes on the board and use any lugs to stabilize it. It'll likely be a double sided board depending on the pin routing. There may be enough room to direct mount a right angle VGA...

Back in the late 90's, people didn't know where the market for ATX backplates was going. Most of the early ATX cases I had worked with included a set of "standard" back plates. Most of these were port configurations (ex: "Micronics", "Intel", etc.) that were already released onto the market...

The issue with System 3.3/Finder 5.4 was likely due to the AFPGetSrvrInfo packet being too large. That has been fixed with Netatalk 4.0.3. Something isn't working right here because PCMacLan shouldn't have any trouble connecting as an AFP3.1 compatible client.

Try directly connecting to the server via TCP/IP under "Miramar AppleTalk Network->AppleShare IP Network->Add a new IP Server". That completely bypasses AppleTalk from the handshake. Note that currently trying to connect via AppleTalk will limit the connection to AFP2.2. Either way, I'm not...