No surprises there. MacOS X 10.6 dropped the AppleTalk stack, so netatalk is TCP/IP only on that platform. Another troubleshooting tip. Are any of the client Macs showing up on the nbplkup list? Once the AppleTalk control panel is set to "Ethernet", the client Macs should be outputting NBP packets to announce themselves on the network. They should also be listening and acknowledging they are connected to an AppleTalk zone and show the popup "Your AppleTalk Network is Now Available".
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Yet Another Netatalk 2.2 Fork
- Thread starter slipperygrey
- Start date
TweedyF
Well-known member
I'm having some trouble getting Netatalk and Daynaport emulation on a PiSCSi to work together. I'm hoping maybe someone here might know what I'm doing wrong!
My setup:
- Raspberry Pi 2B, wired ethernet
- PiSCSI fullspec board
- PiSCSI April 2023 release image
After installing a fresh release image, I did `modprobe appletalk`, installed Netatalk 2.x via easyinstall.sh, and added `eth0` to atalkd.conf. Having done that, AFP via DDP works great: `nbplkup` correctly reports the PiSCSI's shares and other AppleTalk machines on my local network, and the PiSCSI is there in the Chooser when I go look for it on my local Macs.
Now for the trouble. Next, I used easyinstall.sh to configure the PiSCSI Bridge/DaynaPort emulation. But this breaks AFP via DDP. Either I can have `eth0` in atalkd.conf, in which case `nbplkup` reports the PiSCSI's AFP shares only, or I can have `piscsi_bridge` there, in which case it reports other local machines only. In either case, the PiSCSI is not visible in Chooser on other machines.
Reinstalling Netatalk after configuring Daynaport emulation doesn't seem to make a difference.
Is there some more complex configuration I need for atalkd.conf, involving phase/seed/? Or both interfaces? Or something entirely?
My setup:
- Raspberry Pi 2B, wired ethernet
- PiSCSI fullspec board
- PiSCSI April 2023 release image
After installing a fresh release image, I did `modprobe appletalk`, installed Netatalk 2.x via easyinstall.sh, and added `eth0` to atalkd.conf. Having done that, AFP via DDP works great: `nbplkup` correctly reports the PiSCSI's shares and other AppleTalk machines on my local network, and the PiSCSI is there in the Chooser when I go look for it on my local Macs.
Now for the trouble. Next, I used easyinstall.sh to configure the PiSCSI Bridge/DaynaPort emulation. But this breaks AFP via DDP. Either I can have `eth0` in atalkd.conf, in which case `nbplkup` reports the PiSCSI's AFP shares only, or I can have `piscsi_bridge` there, in which case it reports other local machines only. In either case, the PiSCSI is not visible in Chooser on other machines.
Reinstalling Netatalk after configuring Daynaport emulation doesn't seem to make a difference.
Is there some more complex configuration I need for atalkd.conf, involving phase/seed/? Or both interfaces? Or something entirely?
robin-fo
Well-known member
Actually, there should be no need for configuration outside easyinstall.sh.. (not even the modprobe). I usually do options 1), 7) and 5) in easy install.sh and then add the Daynaport through the web interface (and save the SCSI device configuration as default)
Best delete your current configuration and redo steps 7 and 5
Best delete your current configuration and redo steps 7 and 5
TweedyF
Well-known member
No luck. Here's some more information.
After fresh image install and Netatalk (7) via easyinstall.sh:
You can see two other Macs on the network, and I see the piscsi from the CC's Chooser. (And you're right, modprobe wasn't necessary!) No entries in atalkd.conf. ifconfig reports just eth0 and lo.
After configuring the Daynaport network bridge (5):
So at this point, I've lost access to the local shares via DDP, and no clue how to get them back.
Here's a gist of the whole process: https://gist.github.com/tweedyf/ff73439dd26778d1bdba99dd7473b803
Edit: I didn't run (1) in easyinstall.sh first since it takes ages to rebuild the piscsi software and I was using a release image from the piscsi github page, but I have tried that step in previous attempts to troubleshoot this issue, and it doesn't change things.
Code:
PiSCSI software version: 23.4.1
Hardware and OS: Raspberry Pi 2 Model B Rev 1.1, Linux 6.1.21-v7+ armv7lAfter fresh image install and Netatalk (7) via easyinstall.sh:
Code:
pi@piscsi:~ $ nbplkup
piscsi:ProDOS16 Image 65280.182:3
piscsi:Apple //e Boot 65280.182:3
piscsi:TimeLord 65280.182:131
piscsi:AFPServer 65280.182:129
piscsi:Apple //gs 65280.182:3
Color Classic:Macintosh 65280.243:252
Color Classic:Workstation 65280.243:4
Q:Darwin 65356.78:128
Q:AFPServer 65356.78:129You can see two other Macs on the network, and I see the piscsi from the CC's Chooser. (And you're right, modprobe wasn't necessary!) No entries in atalkd.conf. ifconfig reports just eth0 and lo.
After configuring the Daynaport network bridge (5):
Code:
● atalkd.service - Netatalk AppleTalk daemon
Loaded: loaded (/lib/systemd/system/atalkd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2023-10-10 20:29:01 BST; 1min 16s ago
Process: 517 ExecStart=/usr/local/sbin/atalkd (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 1595)
CPU: 35ms
CGroup: /system.slice/atalkd.service
└─522 /usr/local/sbin/atalkd
Oct 10 20:28:12 piscsi systemd[1]: Starting Netatalk AppleTalk daemon...
Oct 10 20:28:12 piscsi atalkd[522]: Set syslog logging to level: LOG_DEBUG
Oct 10 20:28:12 piscsi atalkd[522]: restart (2.230302)
Oct 10 20:28:30 piscsi atalkd[522]: zip_getnetinfo for piscsi_bridge
Oct 10 20:28:40 piscsi atalkd[522]: zip_getnetinfo for piscsi_bridge
Oct 10 20:28:50 piscsi atalkd[522]: zip_getnetinfo for piscsi_bridge
Oct 10 20:29:00 piscsi atalkd[522]: config for no router
Oct 10 20:29:01 piscsi atalkd[522]: ready 0/0/0
Oct 10 20:29:01 piscsi systemd[1]: Started Netatalk AppleTalk daemon.
Code:
pi@piscsi:~ $ nbplkup
Q:Darwin 65336.58:128
Q:AFPServer 65336.58:129
Color Classic:Macintosh 65280.243:252
Color Classic:Workstation 65280.243:4
Code:
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether b8:27:eb:54:7f:6c txqueuelen 1000 (Ethernet)
RX packets 1131 bytes 200037 (195.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 378 bytes 128814 (125.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 679 bytes 200656 (195.9 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 679 bytes 200656 (195.9 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
piscsi0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::6c53:d0ff:fe49:c1b7 prefixlen 64 scopeid 0x20<link>
ether 6e:53:d0:49:c1:b7 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
piscsi_bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.75 netmask 255.255.255.0 broadcast 192.168.178.255
inet6 fd00::ba27:ebff:fe54:7f6c prefixlen 64 scopeid 0x0<global>
inet6 2001:a61:2bae:1f01:ba27:ebff:fe54:7f6c prefixlen 64 scopeid 0x0<global>
inet6 fe80::ba27:ebff:fe54:7f6c prefixlen 64 scopeid 0x20<link>
ether 6e:53:d0:49:c1:b7 txqueuelen 1000 (Ethernet)
RX packets 1089 bytes 193298 (188.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 342 bytes 122390 (119.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0So at this point, I've lost access to the local shares via DDP, and no clue how to get them back.
Here's a gist of the whole process: https://gist.github.com/tweedyf/ff73439dd26778d1bdba99dd7473b803
Edit: I didn't run (1) in easyinstall.sh first since it takes ages to rebuild the piscsi software and I was using a release image from the piscsi github page, but I have tried that step in previous attempts to troubleshoot this issue, and it doesn't change things.
Last edited:
robin-fo
Well-known member
I wonder where the piscsi0 device comes from..
I realized I didn't use DaynaPort Emulation on my second PiSCSI yet, so I configured it now (not tested!)
This is my /etc/network/interfaces.d/piscsi_bridge
/etc/dhcpcd.conf ends with:
and atalkd.conf is empty (just comments)
I hope this helps..
Btw. I'm not quite sure if you had the DaynaPort driver working yet or not. Did you install it correctly and did you change the AppleTalk connection (Control Panel "Network" or "AppleTalk") to "EtherTalk Alternate" (or similar)?
I realized I didn't use DaynaPort Emulation on my second PiSCSI yet, so I configured it now (not tested!)
This is my /etc/network/interfaces.d/piscsi_bridge
Code:
robin@raspberrypi4:~/piscsi $ cat /etc/network/interfaces.d/piscsi_bridge
#
# Defines the 'piscsi_bridge' bridge that connects the PiSCSI network
# interface (ex DaynaPort SCSI/Link) to the outside world.
#
# Depending upon your system configuration, you may need to update this
# file to change 'eth0' to your Ethernet interface
#
# This file should be place in /etc/network/interfaces.d
auto piscsi_bridge
iface piscsi_bridge inet dhcp
bridge_ports eth0/etc/dhcpcd.conf ends with:
Code:
# fallback to static profile on eth0
#interface eth0
#fallback static_eth0
denyinterfaces eth0and atalkd.conf is empty (just comments)
I hope this helps..
Btw. I'm not quite sure if you had the DaynaPort driver working yet or not. Did you install it correctly and did you change the AppleTalk connection (Control Panel "Network" or "AppleTalk") to "EtherTalk Alternate" (or similar)?
You may be running into a weird bug with nbplkup. Check to see if all the hosts are appearing on the client Macs. I noticed when testing the tashtalk as a bridge, nbplkup showed either the LocalTalk segment or the Ethernet segments depending on what order I placed the interfaces in atalkd.conf.
Also you may want to add the "-seed" option to each interface line and assign a zone to your network. This should allow bridging to work properly on the AppleTalk side of things. A sample atalkd.conf is below.
I don't know what interface is the "raw" tap interface from the DaynaPort emulation. You may have to substitute "piscsi0" instead of the bridge interface.
Also you may want to add the "-seed" option to each interface line and assign a zone to your network. This should allow bridging to work properly on the AppleTalk side of things. A sample atalkd.conf is below.
Code:
eth0 -seed -phase 2 -net 1 -zone "Ethernet"
piscsi_bridge -seed -phase 2 -net 2 -zone "PiSCSI"I don't know what interface is the "raw" tap interface from the DaynaPort emulation. You may have to substitute "piscsi0" instead of the bridge interface.
TweedyF
Well-known member
Thanks! I do have the Daynaport drivers installed and the device added to the SCSI bus on the piscsi. I can use it to access the Internet and AppleTalk over TCP/IP. So the piscsi software seems to be working fine; it's Netatalk that's running into problems (albeit with the piscsi bridge interface). Your interfaces.d/piscsi_bridge, dhcpcd.conf, and atalkd.conf look the same as mine after easyinstall.sh (5).
NJRoadfan:
Interesting about nbplkup, but alas the piscsi doesn't appear in the client Macs' Choosers either after I enable the network bridge.
I'm away from home now, but I'll try your atalkd.conf suggestions when I'm back on Sunday. I hadn't considered putting the piscsi0 interface in there -- where does that interface come from/what is it doing? (I only barely know what I'm doing with Linux network interfaces, and I know even less what I'm doing with AppleTalk zones and routing.)
NJRoadfan:
Interesting about nbplkup, but alas the piscsi doesn't appear in the client Macs' Choosers either after I enable the network bridge.
I'm away from home now, but I'll try your atalkd.conf suggestions when I'm back on Sunday. I hadn't considered putting the piscsi0 interface in there -- where does that interface come from/what is it doing? (I only barely know what I'm doing with Linux network interfaces, and I know even less what I'm doing with AppleTalk zones and routing.)
TweedyF
Well-known member
Still not working, but I think we may have some progress.
I added these lines to atalkd.conf and restarted afpd and atalkd. Afterwards, this is what nbplkup reported:
Which is better than I've had so far! But there are two problems: 1. The crucial entry `piscsi:AFPServer` is missing, and more importantly, 2. The piscsi doesn't show up in the client machine's Chooser (in AppleShare or in Tardis).
On reboot, the atalkd.conf entries are preserved but it adds -addr flags, and nbplkup reverts to its earlier behavior:
And again nothing in the client machine's Chooser. At least this time the printer sticks around...?
It does seem like atalkd.conf entries might be the key here, but I'm in over my head. Any other suggestions?
I added these lines to atalkd.conf and restarted afpd and atalkd. Afterwards, this is what nbplkup reported:
Code:
pi@piscsi:~ $ nbplkup
piscsi:ProDOS16 Image 2.191:3
piscsi:Apple //e Boot 2.191:3
HP OfficeJet Pro 9010 series 8D:LaserWriter 2.191:131
piscsi:TimeLord 2.191:129
piscsi:Apple //gs 2.191:3
Color Classic:Macintosh 65280.243:252
Color Classic:Workstation 65280.243:4Which is better than I've had so far! But there are two problems: 1. The crucial entry `piscsi:AFPServer` is missing, and more importantly, 2. The piscsi doesn't show up in the client machine's Chooser (in AppleShare or in Tardis).
On reboot, the atalkd.conf entries are preserved but it adds -addr flags, and nbplkup reverts to its earlier behavior:
Code:
eth0 -seed -phase 2 -net 1 -addr 1.143 -zone "Ethernet"
piscsi_bridge -seed -phase 2 -net 2 -addr 2.191 -zone "PiSCSI"
Code:
pi@piscsi:~ $ nbplkup
piscsi:AFPServer 1.143:128
piscsi:ProDOS16 Image 1.143:3
piscsi:Apple //e Boot 1.143:3
HP OfficeJet Pro 9010 series 8D:LaserWriter 1.143:132
piscsi:TimeLord 1.143:129
piscsi:Apple //gs 1.143:3And again nothing in the client machine's Chooser. At least this time the printer sticks around...?
It does seem like atalkd.conf entries might be the key here, but I'm in over my head. Any other suggestions?
TweedyF
Well-known member
Another clue -- when I select Chooser/Tardis on the client machine, I get a stream of entries like the following in /var/log/syslog:
(65280.243 is the client machine's AFP address)
Code:
Oct 15 20:35:43 piscsi atalkd[927]: nbp lkup sendto 65280.243: Network is unreachable
Oct 15 20:35:44 piscsi atalkd[927]: nbp lkup sendto 65280.243: Network is unreachable
Oct 15 20:35:45 piscsi atalkd[927]: nbp lkup sendto 65280.243: Network is unreachable
Oct 15 20:35:46 piscsi atalkd[927]: nbp lkup sendto 65280.243: Network is unreachable
Oct 15 20:35:47 piscsi atalkd[927]: nbp lkup sendto 65280.243: Network is unreachable(65280.243 is the client machine's AFP address)
TweedyF
Well-known member
Sorry, it turns out I should have waited to write. But the good news is I got it to work!
I used `-router` and `-phase 2` in atalkd.conf, then restarted all the relevant services: atalkd, afpd, timelord, papd. Then they all show up in the client machine's Chooser. Having `-seed` in there doesn't seem to do anything. -net and -addr are auto populated regardless when atalkd starts.
Weirdly, on reboot atalkd.conf still (not immediately but as atalkd starts up) gets overwritten with an eth0 entry. Can anyone guide me as to why that might be happening and how to prevent it?
Edit: davewongillies hack works to keep atalkd from loading before the piscsi_bridge interface does at startup.
I used `-router` and `-phase 2` in atalkd.conf, then restarted all the relevant services: atalkd, afpd, timelord, papd. Then they all show up in the client machine's Chooser. Having `-seed` in there doesn't seem to do anything. -net and -addr are auto populated regardless when atalkd starts.
Weirdly, on reboot atalkd.conf still (not immediately but as atalkd starts up) gets overwritten with an eth0 entry. Can anyone guide me as to why that might be happening and how to prevent it?
Edit: davewongillies hack works to keep atalkd from loading before the piscsi_bridge interface does at startup.
Last edited:
Not having all the network interfaces available on boot is going to cause problems with atalkd. It'll overwrite your previous configuration since it only sees eth0 and considers the other interface as invalid.
I think the issue with the Color Classic is that it didn't reconfigure itself to your network. It should have switched to a network of "2" and showing the configured zones. Usually unplugging and replugging the network cable in fixes that. Some machines just don't get the hint that there is a router on the network advertising.
I think the issue with the Color Classic is that it didn't reconfigure itself to your network. It should have switched to a network of "2" and showing the configured zones. Usually unplugging and replugging the network cable in fixes that. Some machines just don't get the hint that there is a router on the network advertising.
slipperygrey
Well-known member
> Which is better than I've had so far! But there are two problems: 1. The crucial entry `piscsi:AFPServer` is missing, and more importantly, 2. The piscsi doesn't show up in the client machine's Chooser (in AppleShare or in Tardis).
This can happen when afpd starts up before atalkd during f.e. system boot. When atalkd is fully started up, stopping afpd, waiting 2s, starting afpd should get the AFPServer service registered with NBP.
> Weirdly, on reboot atalkd.conf still (not immediately but as atalkd starts up) gets overwritten with an eth0 entry. Can anyone guide me as to why that might be happening and how to prevent it?
Another hack is to make atalkd.conf read-only e.g. <code>chmod 444</code> although the override workaround seems more sophisticated.
I have started collecting AppleTalk troubleshooting tips in the project wiki. Please don't hesitate to add to this (anyone with a github account has permissions to edit the wiki.)
github.com
This can happen when afpd starts up before atalkd during f.e. system boot. When atalkd is fully started up, stopping afpd, waiting 2s, starting afpd should get the AFPServer service registered with NBP.
> Weirdly, on reboot atalkd.conf still (not immediately but as atalkd starts up) gets overwritten with an eth0 entry. Can anyone guide me as to why that might be happening and how to prevent it?
Another hack is to make atalkd.conf read-only e.g. <code>chmod 444</code> although the override workaround seems more sophisticated.
I have started collecting AppleTalk troubleshooting tips in the project wiki. Please don't hesitate to add to this (anyone with a github account has permissions to edit the wiki.)
Connect to AFP Server from Mac clients
Netatalk is a Free and Open Source AFP fileserver. A *NIX or BSD system running Netatalk is capable of serving many Macintosh clients simultaneously as an AppleShare file server. - Netatalk/netatalk
github.com
slipperygrey
Well-known member
For the record: The original topic of this thread is my fork, eventually known as "Netatalk 2.x". However, I archived my fork last month in favor of Netatalk proper, since the upstream 2.2 branch is now perfectly usable. For a clearer separation of concerns, I gently request that further Netatalk discussion takes place in other threads. 
