• 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.

TashRouter: An AppleTalk Router

RolandJuno

Active member
Unfortunately, I don't see any change from before. Log attached.
Did some more testing, and it seems there's another issue?

I'm now having issues using Mini VMac LToUDP to browse netatalk's afpd (running on the same server). This used to work so I'm not sure when it stopped working. I can see the AFP share in the Chooser, select it, login with username/password, and select a share. It mounts on the desktop but double-clicking it causes the system to hang and eventually say the server unexpectedly closed after some time.

I reverted back to all previous name_information.py versions as well as the repo from a few weeks ago. None will let me mount a AFP share on Mini VMac LToUDP from netatalk on the same RaspberryPi as TashRouter. Maybe there's something else going on with my network? I tried reverting things back to the suggestions that @NJRoadfan gave me too.

Below are my settings. I'm not sure what's going on now.

$ ifconfig -a eth0: flags=4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST> mtu 1500 inet 192.168.1.232 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::87a3:6294:9ff3:63d9 prefixlen 64 scopeid 0x20<link> ether 00:e0:4c:68:2d:d6 txqueuelen 1000 (Ethernet) RX packets 48130 bytes 8371043 (7.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 18085 bytes 3471245 (3.3 MiB) 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 793 bytes 43399 (42.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 793 bytes 43399 (42.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tap0: flags=4611<UP,BROADCAST,ALLMULTI,MULTICAST> mtu 1500 inet6 fe80::a495:1dff:fe4c:5b0a prefixlen 64 scopeid 0x20<link> ether a6:95:1d:4c:5b:0a txqueuelen 1000 (Ethernet) RX packets 1709 bytes 105490 (103.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 260 bytes 20897 (20.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.216 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::9bc8:ae76:6310:7f67 prefixlen 64 scopeid 0x20<link> ether b8:27:eb:12:a5:c0 txqueuelen 1000 (Ethernet) RX packets 23328 bytes 6258876 (5.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 139 bytes 22766 (22.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


atalkd.conf:
eth0 -seed -phase 2 -net 2 -addr 2.222 -zone "EtherTalk Network" tap0 -seed -phase 2 -net 3 -addr 3.14 -zone "EtherTalk Network"

router.py:
import logging import time import tashrouter.netlog from tashrouter.port.ethertalk.tap import TapPort from tashrouter.port.localtalk.ltoudp import LtoudpPort from tashrouter.port.localtalk.tashtalk import TashTalkPort from tashrouter.router.router import Router logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(levelname)s: %(message)s') tashrouter.netlog.set_log_str_func(logging.debug) # comment this line for speed and reduced spam router = Router('router', ports=( LtoudpPort(seed_network=5, seed_zone_name=b'LToUDP Network'), TashTalkPort(serial_port='/dev/ttyAMA0', seed_network=6, seed_zone_name=b'LocalTalk Network'), TapPort(tap_name='tap0', hw_addr=b'\xAA\xBB\xCC\xDD\x11\x22'), )) print('router away!') router.start() try: while True: time.sleep(1) except KeyboardInterrupt: router.stop()


npblkup:
$ lookupall EtherTalk Network zone: pizero:ProDOS16 Image 3.14:3 pizero:Apple //e Boot 3.14:3 MacIPpi:AFPServer 3.14:131 LocalTime:TimeLord 3.14:129 pizero:Apple //gs 3.14:3 HP LaserJet 4000 Series:SNMP Agent 2.128:8 HP LaserJet 4000 Series:LaserWriter 2.128:157 HP LaserJet 4000 Series:HP LaserJet 2.128:158 HP LaserJet 4000 Series:HP Zoner Responder 2.128:156 LToUDP Network zone: mini vmac:SNMP Agent 5.97:8 mini vmac:PPCToolBox 5.97:252 mini vmac: Macintosh 5.97:253 mini vmac:Workstation 5.97:4 LocalTalk Network zone:
 

RolandJuno

Active member
Did some more testing, and it seems there's another issue?

I'm now having issues using Mini VMac LToUDP to browse netatalk's afpd (running on the same server). This used to work so I'm not sure when it stopped working. I can see the AFP share in the Chooser, select it, login with username/password, and select a share. It mounts on the desktop but double-clicking it causes the system to hang and eventually say the server unexpectedly closed after some time.

I reverted back to all previous name_information.py versions as well as the repo from a few weeks ago. None will let me mount a AFP share on Mini VMac LToUDP from netatalk on the same RaspberryPi as TashRouter. Maybe there's something else going on with my network? I tried reverting things back to the suggestions that @NJRoadfan gave me too.

Below are my settings. I'm not sure what's going on now.

$ ifconfig -a eth0: flags=4675<UP,BROADCAST,RUNNING,ALLMULTI,MULTICAST> mtu 1500 inet 192.168.1.232 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::87a3:6294:9ff3:63d9 prefixlen 64 scopeid 0x20<link> ether 00:e0:4c:68:2d:d6 txqueuelen 1000 (Ethernet) RX packets 48130 bytes 8371043 (7.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 18085 bytes 3471245 (3.3 MiB) 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 793 bytes 43399 (42.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 793 bytes 43399 (42.3 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 tap0: flags=4611<UP,BROADCAST,ALLMULTI,MULTICAST> mtu 1500 inet6 fe80::a495:1dff:fe4c:5b0a prefixlen 64 scopeid 0x20<link> ether a6:95:1d:4c:5b:0a txqueuelen 1000 (Ethernet) RX packets 1709 bytes 105490 (103.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 260 bytes 20897 (20.4 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.1.216 netmask 255.255.255.0 broadcast 192.168.1.255 inet6 fe80::9bc8:ae76:6310:7f67 prefixlen 64 scopeid 0x20<link> ether b8:27:eb:12:a5:c0 txqueuelen 1000 (Ethernet) RX packets 23328 bytes 6258876 (5.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 139 bytes 22766 (22.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0


atalkd.conf:
eth0 -seed -phase 2 -net 2 -addr 2.222 -zone "EtherTalk Network" tap0 -seed -phase 2 -net 3 -addr 3.14 -zone "EtherTalk Network"

router.py:
import logging import time import tashrouter.netlog from tashrouter.port.ethertalk.tap import TapPort from tashrouter.port.localtalk.ltoudp import LtoudpPort from tashrouter.port.localtalk.tashtalk import TashTalkPort from tashrouter.router.router import Router logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(levelname)s: %(message)s') tashrouter.netlog.set_log_str_func(logging.debug) # comment this line for speed and reduced spam router = Router('router', ports=( LtoudpPort(seed_network=5, seed_zone_name=b'LToUDP Network'), TashTalkPort(serial_port='/dev/ttyAMA0', seed_network=6, seed_zone_name=b'LocalTalk Network'), TapPort(tap_name='tap0', hw_addr=b'\xAA\xBB\xCC\xDD\x11\x22'), )) print('router away!') router.start() try: while True: time.sleep(1) except KeyboardInterrupt: router.stop()


npblkup:
$ lookupall EtherTalk Network zone: pizero:ProDOS16 Image 3.14:3 pizero:Apple //e Boot 3.14:3 MacIPpi:AFPServer 3.14:131 LocalTime:TimeLord 3.14:129 pizero:Apple //gs 3.14:3 HP LaserJet 4000 Series:SNMP Agent 2.128:8 HP LaserJet 4000 Series:LaserWriter 2.128:157 HP LaserJet 4000 Series:HP LaserJet 2.128:158 HP LaserJet 4000 Series:HP Zoner Responder 2.128:156 LToUDP Network zone: mini vmac:SNMP Agent 5.97:8 mini vmac:PPCToolBox 5.97:252 mini vmac: Macintosh 5.97:253 mini vmac:Workstation 5.97:4 LocalTalk Network zone:
Ok, figured out the issues with the unresponsive netatalk share. The AFPD service was throwing an error (found in /etc/syslog) about a corrupt CNID DB in the root of the share. I stopped the service, removed it, and started AFPD again and I can connect and browse the share as usual.

Ok, back to the ImageWriter! I'm using the latest name_information.py and I've printed two jobs so far successfully! I'll do some more testing tomorrow.
 

Tashtari

PIC Whisperer
Ok, figured out the issues with the unresponsive netatalk share. The AFPD service was throwing an error (found in /etc/syslog) about a corrupt CNID DB in the root of the share. I stopped the service, removed it, and started AFPD again and I can connect and browse the share as usual.
Glad to hear it!

Ok, back to the ImageWriter! I'm using the latest name_information.py and I've printed two jobs so far successfully! I'll do some more testing tomorrow.
Latest name_information.py from the repo or latest that I've attached to this thread?
 

RolandJuno

Active member
Glad to hear it!


Latest name_information.py from the repo or latest that I've attached to this thread?
I'm using the latest name_information 5 from this thread with the latest repo.

I've been trying various things, and here's what I'm observing now.

If I define different names for my zones as follows:

Network number 2: netatalk seeding (eth0) "EtherTalk Zone"
Network number 3: netatalk seeding (tap0) "EtherTalk Zone"
Network number 5: TashRouter seeding (LToUDP) "LToUDP Network"
Network number 6: TashRouter seeding (TashTalk) "LocalTalk Network"

And run netatalk and TashRouter, I'm able to print from Mini VMac to both the ImageWriter II and ImageWriter LQ without issue, selecting in in the Chooser in the "LocalTalk Network" zone. However, Namer is not able to locate the ImageWriters (there's no zone selection available in Namer).

If I define the same name for my zones (to collapse them into one zone in the Chooser) as follows:

Network number 2: netatalk seeding (eth0) "Biosrhythm Zone"
Network number 3: netatalk seeding (tap0) "Biosrhythm Zone"
Network number 5: TashRouter seeding (LToUDP) "Biosrhythm Zone"
Network number 6: TashRouter seeding (TashTalk) "Biosrhythm Zone"

From Mini VMac, I can locate both ImageWriters in Namer and rename them properly. Netatalk shows all devices belonging to the one zone properly in nbplkup. I can also locate the ImageWriters in the Chooser. But I'm not able to start any print jobs. It eventually fails and says the printer can't be found. I've attached a log for this.

I'm assuming that it's within spec to give different networks the same name, but maybe that's not allowed? It's preferable because you don't need to know which cable a device is connected to.
 

Attachments

  • tashrouter-rickards19-debugout.txt.zip
    8.7 KB · Views: 3

NJRoadfan

Well-known member
Namer is limited to only seeing and renaming devices in the current zone. That is intentional on Apple's part. Zones are strictly organizational in nature. You can name all the segments the same, or something different. Its your choice. The only limitation I've found involves netbooting Apple IIs. You have to have a netboot server in the zone your machine's LocalTalk network is in, otherwise you can't boot.
 

Tashtari

PIC Whisperer
But I'm not able to start any print jobs. It eventually fails and says the printer can't be found. I've attached a log for this.
Hm. Did you re-select the printer in Chooser after you changed the zone configuration? (Maybe you have to close it after selecting the printer, not sure...) The BrRqs coming from Mini vMac that appear to be associated with the print job are looking in the zone "LocalTalk Network", which is no longer valid in your configuration, and are not getting answered.
 

NJRoadfan

Well-known member
To all TashRouter users, particularly ones using another router to seed their Ethernet networks. Update to the latest code on github. It fixes a nasty issue with the ZIP service. A packet was being sent out as unicast instead of broadcast causing an AARP storm, plus it was preventing TashRouter from updating its Zone Information Table for connected EtherTalk networks.
 

RolandJuno

Active member
Hm. Did you re-select the printer in Chooser after you changed the zone configuration? (Maybe you have to close it after selecting the printer, not sure...) The BrRqs coming from Mini vMac that appear to be associated with the print job are looking in the zone "LocalTalk Network", which is no longer valid in your configuration, and are not getting answered.
Good catch! I tried rebooting several times, and selecting the IW II in the Chooser but it still insists on looking for it on "LocalTalk Network" despite there being only one zone now (Biosrhythm Zone), according to TashRouter logs. I even tried changing the network number of the tashtalk network from 6 to 7, hoping that it would "forget" the old name but that didn't work either. I also made sure it prompted me to open Page Setup, etc., etc. acknowledging a new printer was selected.

I tried a different system disk in Mini VMac (7.1) that I hadn't tried any of this before with and it printed to the IM II from the single zone without issue.

I went back and am still puzzled as to why it still looks for it in the wrong zone. Even the third-party IM II driver MacPalette II does the same thing. Any hints as to what to try and fix this, I'm open to suggestions!

In any case, it seems that this is an OS issue now and not a TashRouter issue. BTW, I pulled down the most recent version and used name_information 5 that you provided in the thread.
 

Attachments

  • Screenshot 2024-04-07 at 2.48.54 PM.png
    Screenshot 2024-04-07 at 2.48.54 PM.png
    125.3 KB · Views: 14

NJRoadfan

Well-known member
If running classic networking, open up the Network control panel and verify the correct zone is listed. If Open Transport, open up the AppleTalk control panel. The Mac should be auto-updating this, but isn't for some reason. Also try selecting the LaserWriter in Chooser, closing it, then re-selecting the ImageWriter.
 
Last edited:

RolandJuno

Active member
If running classic networking, open up the Network control panel and verify the correct zone is listed. If Open Transport, open up the AppleTalk control panel. The Mac should be auto-updating this, but isn't for some reason. Also try selecting the LaserWriter in Chooser, closing it, then re-selecting the ImageWriter.
Thanks for the tip! I'm using Classic Networking. I verified that the Network Control Panel did have the correct Zone listed but I was still unable to print as it was still looking in the wrong Zone. What fixed it was replacing the Extension "AppleTalk ImageWriter" with another copy (and without rebooting)! The same holds true for the MacPalette II AppleTalk driver-- replacing it allowed it to work on the new Zone. Not sure why, but it worked.
 

RolandJuno

Active member
I'm continuing with my AppleTalk networking at home and I'm so close to having everything working together from a single Raspberry Pi. I'm struggling with getting my LaserWriter II integrated. Forgive me if this problem isn't directly related to TashRouter (but it is a key part).

Where I'm at now:
  • Fresh install of Raspbian 11 (Bullseye) on a Pi Zero WiFi with a USB Ethernet hat and a TashTalk 2 hat on top of that (they don't conflict AFAIK).
  • Installed netatalk 2.3.1 from source.
  • Installed latest tashrouter with patches applied for ImageWriter LocalTalk card.
  • I've configured three named zones and 4 net numbers:
    • 10: 'Biosrhythm EtherTalk' (eth0, seeded by atalkd)
    • 11: 'Biosrhythm EtherTalk' (tap0, seeded by atalkd)
    • 12: 'LToUDP Network' (seeded by tashrouter)
    • 13: 'LocalTalk Network' (seeded by tashrouter)
A list of my network according to the Pi Zero using getzones and nbplkup:

Biosrhythm EtherTalk zone: pizero:ProDOS16 Image 11.236:3 pizero:Apple //e Boot 11.236:3 172.16.2.1:IPGATEWAY 11.236:72 pizero:Apple //gs 11.236:3 LocalTime:TimeLord 11.236:130 MacIPpi:AFPServer 11.236:128 HP LaserJet 4000 Series:SNMP Agent 10.128:8 HP LaserJet 4000 Series:LaserWriter 10.128:157 HP LaserJet 4000 Series:HP LaserJet 10.128:158 HP LaserJet 4000 Series:HP Zoner Responder 10.128:154 LToUDP Network zone: 172.16.2.2:IPADDRESS 12.38:72 mini vmac:SNMP Agent 12.38:8 mini vmac:AFPServer 12.38:251 mini vmac:PPCToolBox 12.38:252 mini vmac: Macintosh 12.38:253 mini vmac:Workstation 12.38:4 LocalTalk Network zone: Itchy & Scratchy:ImageWriter 13.252:138

The Problem: I have a LaserWriter II with a IIg card installed (named Web of Fate) and connected to my Ethernet network. It only shows up very briefly on the Mini VMac Chooser. I did some captures with tcpdump and it looks like it is assigned 10.59, repeating several times every 50 seconds. atalkd puts "zip ignoring gnireply" in the logs (searching for this didn't return anything useful).

TCPDump snippet:
14:23:05.182806 AT 10.188.rtmp > 0.rtmp: at-rtmp 22 14:23:05.184490 AT 10.59.zip > 0.zip: at-#6 27 14:23:05.185333 AT 10.59.129 > 10.188.nis: nbp-brRq 33: "Web of Fate:LaserWriter@Biosrhythm EtherTalk" 14:23:05.189415 AT 10.188.nis > 0.nis: nbp-lkup 33: "Web of Fate:LaserWriter@Biosrhythm EtherTalk" [addr=10.59.129] 14:23:05.683421 AT 10.59.zip > 0.zip: at-#6 79 14:23:06.183471 AT 10.59.zip > 0.zip: at-#6 79 14:23:06.184039 AT 10.59.129 > 10.188.nis: nbp-brRq 33: "Web of Fate:LaserWriter@Biosrhythm EtherTalk" 14:23:06.184503 AT 10.188.nis > 0.nis: nbp-lkup 33: "Web of Fate:LaserWriter@Biosrhythm EtherTalk" [addr=10.59.129] 14:23:06.683418 AT 10.59.zip > 0.zip: at-#6 79 14:23:07.183470 AT 10.59.zip > 0.zip: at-#6 79 14:23:07.183486 AT 10.59.129 > 10.188.nis: nbp-brRq 33: "Web of Fate:LaserWriter@Biosrhythm EtherTalk" 14:23:07.183762 AT 10.188.nis > 0.nis: nbp-lkup 33: "Web of Fate:LaserWriter@Biosrhythm EtherTalk" [addr=10.59.129] 14:23:07.335802 AT 10.153.zip > 0.zip: at-#6 17 14:23:07.683457 AT 10.59.zip > 0.zip: at-#6 79 14:23:08.183471 AT 10.59.zip > 0.zip: at-#6 79 14:23:08.683442 AT 10.59.zip > 0.zip: at-#6 79 14:23:09.183420 AT 10.59.zip > 0.zip: at-#6 79 14:23:09.683400 AT 10.59.zip > 0.zip: at-#6 79

syslog snippet (showing atalkd debug):
Apr 27 14:23:05 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:05 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:05 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:05 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:06 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:06 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:06 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:06 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:07 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:07 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:07 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:07 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:07 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:07 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:08 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:08 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:08 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:08 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:09 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:09 pizero atalkd[3639]: zip ignoring gnireply Apr 27 14:23:09 pizero atalkd[3639]: zip gnireply from 11.236 (tap0 cfa) Apr 27 14:23:09 pizero atalkd[3639]: zip ignoring gnireply

tashrouter snippet:
2024-04-27 14:23:05,184 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00\x1d\xe0\x01\x00\x00\x00\x0b\xff\xec\x01\x01\x01\x00\x0b\x08\xec\x00\x0b\x80\x00\x0b\x82\x00\n\x80\x00\n\x82' 2024-04-27 14:23:05,201 DEBUG: in to 11.121 tap0 0 0.255 11.236 1 1 1 b'\x00\x0b\x08\xec\x00\x0b\x80\x00\x0b\x82\x00\n\x80\x00\n\x82' 2024-04-27 14:23:05,209 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:05,213 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:05,218 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00A\xc8\xfa\x00\x00\x00\x0b\xff\xec\x02\x02\x02!!\x00\n;\x81\x00\x0bWeb of Fate\x0bLaserWriter\x14Biosrhythm EtherTalk' 2024-04-27 14:23:05,222 DEBUG: in to 11.121 tap0 0 0.255 11.236 2 2 2 b'!!\x00\n;\x81\x00\x0bWeb of Fate\x0bLaserWriter\x14Biosrhythm EtherTalk' 2024-04-27 14:23:05,692 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:05,696 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:05,800 DEBUG: out broadcast LToUDP 0 0.255 12.254 1 1 1 b'\x00\x0c\x08\xfe\x00\x00\x82\x00\r\x00\x00\x0b\x80\x00\x0b\x82\x00\n\x81\x00\n\x82' 2024-04-27 14:23:05,804 DEBUG: frame out LToUDP 255 254 type 01 b'\x00\x1b\x01\x01\x01\x00\x0c\x08\xfe\x00\x00\x82\x00\r\x00\x00\x0b\x80\x00\x0b\x82\x00\n\x81\x00\n\x82' 2024-04-27 14:23:05,808 DEBUG: out broadcast ttyAMA0 0 0.255 13.254 1 1 1 b'\x00\r\x08\xfe\x00\x00\x82\x00\x0c\x00\x00\x0b\x80\x00\x0b\x82\x00\n\x81\x00\n\x82' 2024-04-27 14:23:05,812 DEBUG: frame out ttyAMA0 255 254 type 01 b'\x00\x1b\x01\x01\x01\x00\r\x08\xfe\x00\x00\x82\x00\x0c\x00\x00\x0b\x80\x00\x0b\x82\x00\n\x81\x00\n\x82' 2024-04-27 14:23:05,817 DEBUG: out broadcast tap0 0 0.255 11.121 1 1 1 b'\x00\x0b\x08y\x00\x0b\x80\x00\x0b\x82\x00\x0c\x00\x00\r\x00' 2024-04-27 14:23:05,822 DEBUG: frame out tap0 090007FFFFFF AABBCCDD1122 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00\x1dp\x0b\x00\x00\x00\x0b\xffy\x01\x01\x01\x00\x0b\x08y\x00\x0b\x80\x00\x0b\x82\x00\x0c\x00\x00\r\x00' 2024-04-27 14:23:06,195 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:06,201 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:06,206 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00A\xc8\xfa\x00\x00\x00\x0b\xff\xec\x02\x02\x02!!\x00\n;\x81\x00\x0bWeb of Fate\x0bLaserWriter\x14Biosrhythm EtherTalk' 2024-04-27 14:23:06,210 DEBUG: in to 11.121 tap0 0 0.255 11.236 2 2 2 b'!!\x00\n;\x81\x00\x0bWeb of Fate\x0bLaserWriter\x14Biosrhythm EtherTalk' 2024-04-27 14:23:06,692 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:06,696 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:07,192 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00A\xc8\xfa\x00\x00\x00\x0b\xff\xec\x02\x02\x02!!\x00\n;\x81\x00\x0bWeb of Fate\x0bLaserWriter\x14Biosrhythm EtherTalk' 2024-04-27 14:23:07,196 DEBUG: in to 11.121 tap0 0 0.255 11.236 2 2 2 b'!!\x00\n;\x81\x00\x0bWeb of Fate\x0bLaserWriter\x14Biosrhythm EtherTalk' 2024-04-27 14:23:07,202 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:07,206 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:07,346 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00:\xbdS\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06\xa0\x00\x0b\x00\x0b\nBiosrhythm\x06\t\x00\x07\x00\x00\x7f\x14Biosrhythm EtherTalk' 2024-04-27 14:23:07,350 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06\xa0\x00\x0b\x00\x0b\nBiosrhythm\x06\t\x00\x07\x00\x00\x7f\x14Biosrhythm EtherTalk' 2024-04-27 14:23:07,693 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:07,697 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:08,192 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:08,196 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:08,694 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:08,699 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:09,192 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:09,196 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:09,694 DEBUG: frame in tap0 090007FFFFFF 324A63D676C7 b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00/\x89*\x00\x00\x00\x0b\xff\xec\x06\x06\x06\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f' 2024-04-27 14:23:09,698 DEBUG: in to 11.121 tap0 0 0.255 11.236 6 6 6 b'\x06 \x00\x0b\x00\x0b\x14Biosrhythm EtherTalk\x06\t\x00\x07\x00\x00\x7f'

Am I missing something obvious here?
 

NJRoadfan

Well-known member
Is the HP LaserJet 4000 showing up without a problem? The zipgnireply errors are likely due to an unpatched broadcast bug in the Linux kernel. I strongly suspect the printer is the source of the ZIP GetNetInfo packets and that is the problem.

I would need a more detailed tcpdump, or wireshark on a another machine (should be visible to the whole network as the ZIP packets are broadcast). This does NOT appear to be a TashRouter issue, but a netatalk atalkd issue. The LaserWriter managed to figure out what network its on and configured itself, but it looks like its trying to figure out what zone it is in and determine if the configured printer name is free. You should be able to "ping" the LaserWriter from the netatalk box using the command aecho 10.59
 

NJRoadfan

Well-known member
OK, this appears to be the annoying Linux AppleTalk kernel bug rearing its head. The printer keeps sending ZIP GetNetInfo packets because its never receiving a response. Netatalk is responding, but sending out the response to the tap interface instead of the Ethernet interface! There is a patch for this that should fix the problem, but that involves rebuilding the AppleTalk kernel module, which can be a pain on a RPi for some reason.

More background here: https://gist.github.com/VinDuv/4db433b6dce39d51a5b7847ee749b2a4

Tagging @dougg3 about this since he has past experience with kernel patches. Head up to @slipperygrey that maybe this should be in the netatalk docs as a "gotcha" on Linux. As far as I know, this is a Linux only problem and NetBSD and other platforms with native AppleTalk support should work fine.
 
Last edited:

NJRoadfan

Well-known member
@RolandJuno try reversing the order of the interface lines in your atalkd.conf file. If it is currently
Code:
eth0
tap0

reverse it to:
Code:
tap0
eth0

The above is a simplified example. Naturally, leave all the other switches and zone information in the file as-is. This might solve your problem as the unpatched Linux kernel tends the send the broadcast replies out the last configured interface.
 

RolandJuno

Active member
@RolandJuno try reversing the order of the interface lines in your atalkd.conf file. If it is currently
Code:
eth0
tap0

reverse it to:
Code:
tap0
eth0

The above is a simplified example. Naturally, leave all the other switches and zone information in the file as-is. This might solve your problem as the unpatched Linux kernel tends the send the broadcast replies out the last configured interface.
I swapped them around (tap0 is first now) and it works! And I'm really glad it did work because I started looking into the building the kernel module and was running into lots problems.

I'll continue on working on trying to build the kernel module to see if I can get it to work too. I'm using Raspbian 11 (because it's a Pi Zero W).

Thanks for your help!
 

NJRoadfan

Well-known member
I just did some testing here and can confirm that kernel patch will fix the problem. I also figured out why the HP printer works fine, but the LaserWriter doesn't. HP's JetDirect firmware doesn't broadcast ZIP GetNetInfo packets, it sends them directly addressed to the router, which doesn't trigger the bug. Apple's implementations, even on Macs, always defaults to broadcasting ZIP GetNetInfo packets to configure themselves on a given network.

TashRouter isn't affected since it currently doesn't use ZIP GetNetInfo to configure itself on non-seed interfaces.
 

RolandJuno

Active member
OK, this appears to be the annoying Linux AppleTalk kernel bug rearing its head. The printer keeps sending ZIP GetNetInfo packets because its never receiving a response. Netatalk is responding, but sending out the response to the tap interface instead of the Ethernet interface! There is a patch for this that should fix the problem, but that involves rebuilding the AppleTalk kernel module, which can be a pain on a RPi for some reason.

More background here: https://gist.github.com/VinDuv/4db433b6dce39d51a5b7847ee749b2a4

Tagging @dougg3 about this since he has past experience with kernel patches. Head up to @slipperygrey that maybe this should be in the netatalk docs as a "gotcha" on Linux. As far as I know, this is a Linux only problem and NetBSD and other platforms with native AppleTalk support should work fine.
I was able to compile a new AppleTalk kernel module on Raspberry Pi. The kernel sources were missing so I followed these instructions to install them. Then I followed the instructions you linked above to patch, compile, unload, and load the new module. I also swapped the order of the two interfaces (eth0 is now listed first again) in the atalk.conf file. It all still seems to work! Thanks.
 

slipperygrey

Well-known member
OK, this appears to be the annoying Linux AppleTalk kernel bug rearing its head. The printer keeps sending ZIP GetNetInfo packets because its never receiving a response. Netatalk is responding, but sending out the response to the tap interface instead of the Ethernet interface! There is a patch for this that should fix the problem, but that involves rebuilding the AppleTalk kernel module, which can be a pain on a RPi for some reason.

More background here: https://gist.github.com/VinDuv/4db433b6dce39d51a5b7847ee749b2a4

Tagging @dougg3 about this since he has past experience with kernel patches. Head up to @slipperygrey that maybe this should be in the netatalk docs as a "gotcha" on Linux. As far as I know, this is a Linux only problem and NetBSD and other platforms with native AppleTalk support should work fine.
Thanks for the heads-up.

I've added a brief blurb to the netatalk wiki page on this topic: https://github.com/Netatalk/netatalk/wiki/AppleTalk-Kernel-Module

Please feel free to flesh out the description of the problem, if you can think of a better way to phrase it.
 

dougg3

Well-known member
OK, this appears to be the annoying Linux AppleTalk kernel bug rearing its head. The printer keeps sending ZIP GetNetInfo packets because its never receiving a response. Netatalk is responding, but sending out the response to the tap interface instead of the Ethernet interface! There is a patch for this that should fix the problem, but that involves rebuilding the AppleTalk kernel module, which can be a pain on a RPi for some reason.

More background here: https://gist.github.com/VinDuv/4db433b6dce39d51a5b7847ee749b2a4

Tagging @dougg3 about this since he has past experience with kernel patches. Head up to @slipperygrey that maybe this should be in the netatalk docs as a "gotcha" on Linux. As far as I know, this is a Linux only problem and NetBSD and other platforms with native AppleTalk support should work fine.

Ahhh interesting, somehow I didn't get notified when you tagged me on this. Based on the last time it was submitted to the upstream kernel, it seems like there wasn't any resistance to the actual logic the patch did, it was just patch submission process stuff. It can be super intimidating and occasionally people can be...a little less than super nice about it. I could definitely take a crack at submitting this upstream again, especially since it seems like there are several examples of people experiencing success with this change.
 
Top