AppleTalk and afpstats on musl?

[APCCV]

Netatalk 4.0.x now builds as a package for OpenWrt. AFP works great.
AppleTalk and afpstats require glibc to build, yet this distro use musl instead due to size requirements.
Assuming that headers are going to be like for like between glibc and musl... what would be the places to look at to explore AppleTalk and afpstats on musl? Patch meson.build? Somewhere else?

[rdmark]

This is great to hear! Does this mean that netatalk4 has been packaged as an OpenWrt ipk, or simply that you succeeded in building it yourself?

When building with musl libraries, Netatalk should be supplying its own AppleTalk headers. Last I checked it doesn't rely on glibc for AppleTalk... At least on Alpine Linux with musl.

Are you seeing some particular errors in the Meson setup or compile logs?

afpstats is a bit of a different beast, relying on D-Bus and GLib (which is a GNOME library, different from glibc IINM?) Isn't GNOME available on OpenWrt?

[APCCV]

netatalk4 has been packaged as an OpenWrt ipk

We made it to the stable build!
https://downloads.openwrt.org/releases/23.05.5/packages/arm_cortex-a15_neon-vfpv4/packages/netatalk_4.0.7-1_arm_cortex-a15_neon-vfpv4.ipk (one example - should be there for all architectures).

appletalk kernel module hasn't been merged and I give it a 50-50 chance for it to for this build. If it does... we would get that working too.

And as an update, I have a tentative patch to the kernel that would make AppleTalk work again on OpenWrt. Hopefully that will shape up. We are looking at a really weird use case where a device is running appletalk and also has a local switch and also manages it with DSA... probably something only OpenWrt or network equipment vendors would ever hit. Let's see what happens.

[APCCV]

I'm in the process of updating the 3.2.5 ipk. I compiled netatalk4 as a package (an ipk) and it is running now on a router. Stuck on finding a way to provide UnicodeData.txt to the build process as OpenWrt build containers doesn't seem to have it. That's a different issue. Would be awsome if there was a way to precompile that.

AppleTalk... I'll rebuild with it in and look for the error.

afpstats... guess I mixed up GLib and glibc. GNOME makes no sense on OpenWrt (I'm sure some creative soul might port it) as most devices are small appliances with no display adapter let alone a window manager. Is afpstats a GUI app?

[rdmark]

afpstats is not a GUI app. It just uses GLib's D-Bus messaging interface. For historical reasons (choices of a previous maintainer team), a lot of the more modern functionality is built on GNOME tech. Spotlight is using GNOME Tracker (tracker-miner, tracker-sparql) as the indexer and search backend, notably. I think you can pull in GLib without too much of GNOME desktop environment dependencies though. We were able to get the Alpine Linux based official Docker container for Netatalk down to ~40MB compressed, so it isn't too bad.

I'm sorry about the UnicodeData.txt situation. This was my choice to remove the pre-generated sources to cut down on the maintenance overhead for the project... I'm open to suggestions though.

[APCCV]

Oh, no worries about UnicodeData.txt. I have no doubt you make choices like that with priority on netatalk.
Besides, if someone competent with OpenWrt was doing this, it would probably be no issue. I'll find a way.
GLib... maybe there is a way to pick it up from the host. Again, not too sure what I'm doing here. You've given me enough to poke it for a while. But to put it in perspective, some routers have maybe 8MB free storage, and that's to share with everything else. We are talking tiny.

[rdmark]

To be honest, afpstats is not that important. It prints stats on logged in users. You can use the macusers Perl script as a light-weight alternative.

[APCCV]

Figured out a way to have the build containers pull UnicodeData.txt during build. That's cleared.
Played a bit with config to include dbus (succeeded) and GLib2 (failed).
Also fidgeted with AppleTalk and build also failed.
Crashes are with tests for libiconv or other stuff that I can open a separate thread for.
The package is already quite large and has several dependencies that add to it. To play with the AppleTalk functions I'll rather figure out how to create a separate AppleTalk enabled "full functionality" package.
Size is a real issue. Modern routers have plenty of space, but OpenWrt caters also to tons of older boxes that have very little storage. Perl is too large for many.

[rdmark]

@APCCV In the recently released 4.0.5, I removed the hard dependency on UnicodeData.txt and restored bundled versions of those generated sources under libatalk/unicode ... so you have the option now to remove that dependency in your build script, if you would like to reduce the complexity.

But you also have the option to keep it as-is. The netatalk build system will still make use of UnicodeData.txt if found, just like before.

[NJRoadfan]

Musl will throw random errors when atalkd calls getservbyname() because the implementation only understands TCP/IP as valid network types (it doesn't know what to do with DDP as network family, unlike glibc). These can be ignored as AppleTalk still works assuming you have the kernel module loaded.

Also, afpstats is not going to show AppleTalk connected clients, only those via TCP/IP. It also requires Perl.

[NJRoadfan]

AppleShareIP (AFP-over-TCP) requires no additional kernel modules.

[rdmark]

@APCCV Apologies for my ignorance, but what function would LToUPD serve in this context?

I've attempted to capture what's needed to connect to an AFP server at this wiki page: https://netatalk.io/docs/Connect-to-AFP-Server

68k Macs can use AppleShare IP if they run a new enough AppleShare Client (3.7.0 or later.)

However, even AppleShare IP capable AppleShare Clients on pre-OSX leverage AppleTalk (NBP) for service discovery. So without AppleTalk, you won't see available servers listed in the Chooser. You will have to enter the IP address manually. This is the main reason I recommend AppleTalk to everyone running OS9 or earlier.

[APCCV]

Sorry to bring in LToUDP, as I don't quite understand it and probably makes no sense w/this. I no longer have my //e and my old Mac... I'm grasping at straws trying to find a way:

1. Test DDP and AppleTalk: to test atalkd running on OpenWrt (the server), from a macOS 9 PPC VM (the client) inside a linux host on WiFi... issues...

• VM needs to route outside host. SLIRP doesn't help. A tap interface does, but can't bridge that to WiFi. NAT is on IP.
• DDP is layer III so need a single broadcast domain, I somehow need to find a way to have the VM adapter bridged to WiFi (will never work), or go wired just for testing

2. Test AppleTalk IP... I understood, from the above and your page, that is just AFP with afpd, IP based and not need the kernel extension.

• haven't managed to get NAT working on the VM host. Almost there. That's all I need. Should run without atalkd.

3. Make a case for the appletalk kernel extension to make it back on the OpenWrt distro. Ideally the two tests above would help me understand exactly when it is needed.

[rdmark]

Netatalk comes with a CLI tool nbplkup that can inquire the local network for running AppleTalk services (Netatalk or Mac OS.) In the absence of a an old Mac (real or emulated) this can give you a pretty good idea that everything is working. If you, say, start atalkd first and then netatalk you should then see an "AFPServer" AppleTalk service via nbplkup.

[APCCV]

Thank you. I'll look at that.

The plot thickens tho... there's 2 modules involved! On loading appletalk.ko, it is in use by ipddp.ko.
https://www.kernelconfig.io/config_ipddp

So that's AppleTalk-IP! It's and IP package inside a DDP package. (Which baffles me to no end, as I expected it the other way around). Guess it's a mechanism for AppleTalk (DDP) only systems on LocalTalk infra (or some early Ethernet stuff prior to 10BaseT... AAUI ports... I had forgotten those) to exchange IP traffic. Weird. Interesting. Not useful for what I need, but interesting nevertheless. Maybe (if I get the tap/eth bridge as tap/wifi won't bridge) this is how EtherTalk will work for a VM. Super weird to think of a network adapter with no IP address though... Anyways.

ipddp module is already being built in OpenWrt, which is a good thing. Good leverage.

And maybe this mess I'm in it's because I'm trying to understand AppleTalk DDP on an IP backbone and that doesn't exist. What I need is an atalkd on every network node including the VM host, and no IP on Mac OS 9. Let's see how that goes.

[NJRoadfan]

No, actually its not. You do not want IPDDP compiled as a module at all. It prevents macipgw from working. Its a moot point starting with kernel 6.7 as IPDDP was completely removed (good riddance!)

[APCCV]

Shucks.... and I thought I was making progress...
I just rebuilt on OpenWrt 23 as it's stable, so that's why I saw it. I guess if I try deal with Snapshot which I think runs 6.8 it won't be there.
So good stuff in that I don't need it. There goes the leverage.

[APCCV]

Progress! Not with what matters, but I'll take it. I managed to get the qemu VM talking to atalkd on the host.

$ bin/nbp/nbplkup @bridge
                         Zoinks:netatalk                           4.4:128
                         Zoinks:AFPServer                          4.4:128
                        Jeepers:LaserWriter                        4.4:128
                       MacOS922:  Power Macintosh                  4.152:251
                       MacOS922:Workstation                        4.152:4
$ bin/nbp/nbplkup @wifi
                            Nyx:Workstation                        4.4:128
                          Chaos:netatalk                           4.4:128
                          Chaos:AFPServer                          4.4:128
                         Erebus:LaserWriter                        4.4:128
                         banana:fruit                              4.4:128

atalkd is not routing between the VM's tap/bridge and the wireless adapter. It's weird because the "wifi" zone has registered services and those don't show up. I also don't have quite right the idea of a "network" and a "zone"... 'wifi' should be 2.x...
Clearly I'm not doing something right... but it's progress.

Routing on my LAN promises to be extremely painful if I need to load the appletalk module to each access point and the router. I should just give up and plug in directly to the OpenWrt box.

What registers afpd to atalk? The netatalk binary? It is not used in OpenWrt (yet?) to start services for whatever historical reason. What registration should it have? AFPServer? netatalk? both? something else?

[NJRoadfan]

NBP registrations can be weird if you have two non-routed interfaces and services running on the same machine. Post your atalkd.conf. Also, do you have any other routers on your network seeding zones?

The afpd binary does the NBP registration for AppleTalk. The netatalk daemon was introduced in 3.0 and handles things like mDNS registration. Besides starting and stopping afpd, it also controls starting and stopping the CNID services (this was a separate daemon in 2.x).

[APCCV]

Well, this is super weird.

This is the setup. Really sweet and simple. Boiled it down to the basics. No WiFi, direct ethernet between laptop running Ubuntu and the OpenWrt box which is an ARM router with WiFi disabled.

       ┌──────────────────────────────┐         ┌────────────────┐  
       │         Ubuntu Host          │         │    OpenWrt     │  
       │                              │         │                │  
       │ ┌─────────┐      ┌───┐       │         │                │  
       │ │ OS9 VM  │      │   │       │         │       ┌──────┐ │  
       │ │    ┌───┐│┌───┐ │ b │ ┌───┐ │   LAN   │ ┌───┐ │      │ │  
       │ │    │NIC┼┼┼tap┼─┼ r ┼─┼eth┼─┼─────────┼─┤br-│ │ AFPd │ │  
       │ │    └───┘│└───┘ │ 0 │ └───┘ │         │ │lan│ │      │ │  
       │ └─────────┘      │   │       │         │ └───┘ └──────┘ │  
       │                  └───┘       │         │    ┌────────┐  │  
       │                              │         │    │ atalkd │  │  
       │                              │         │    └────────┘  │  
       └──────────────────────────────┘         └────────────────┘  

atalkd runs on OpenWrt with a simple config:
br-lan -router -phase 2 -net 2000 -addr 2000.152 -zone "openwrt" (all eth ports are bridged in this device)

Doesn't work. Neither Ubuntu nor the OS 9 VM see anything.

nbprgstr works on OpenWrt. nbplkup displays back whatever I register. atalkd is running with -d and spewing packages to stdio. That looks healthy.

Nothing on Ubuntu. Nada.

Now, if I start an atalkd -d on the Ubuntu side like this (either routing as shown before or just against the bridge as set above knowing that will cause a conflict):

     ┌──────────────────────────────┐         ┌────────────────┐    
     │         Ubuntu Host          │         │    OpenWrt     │    
     │                              │         │                │    
     │ ┌─────────┐      ┌───┐       │         │                │    
     │ │ OS9 VM  │      │   │       │         │       ┌──────┐ │    
     │ │    ┌───┐│┌───┐ │ b │ ┌───┐ │   LAN   │ ┌───┐ │      │ │    
     │ │    │NIC┼┼┼tap┼─┼ r │ │eth┼─┼─────────┼─┤eth│ │ AFPd │ │    
     │ │    └───┘│└───┘ │ 0 │ └─┬─┘ │         │ └───┘ │      │ │    
     │ └─────────┘      │   │   │   │         │       └──────┘ │    
     │                  └┬──┴───┼─┐ │         │    ┌────────┐  │    
     │                   │ atalkd │ │         │    │ atalkd │  │    
     │                   └────────┘ │         │    └────────┘  │    
     └──────────────────────────────┘         └────────────────┘    

with this config br0 -router -phase 2 -net 4000 -addr 4000.152 -zone "ubuntu" with eth in bridge (or eth out of bridge, first line with seed instead of router, and a second seed config line for eth)
then I can see it spew packages of discovery, it's own 4000's, and the 2000's from OpenWrt.
The OS 9 VM complains that there are two routers conflicting on the network and to contact myself.

I never see 4000's on OpenWrt.

Same behaviour when I was running on WiFi and not wired Ethernet. I never saw a DDP packet make it back to OpenWrt from atalkd/nbplookup running on Ubuntu. Ubuntu atalkd sees packages coming in from OpenWrt, but never the other way around.

It's not firewall on OpenWrt; it's disabled. No firewall in Ubuntu.

Tried running two atalkd in OpenWrt on different interfaces. Doesn't work.

It's not terribly messed up because if I set IP addresses properly, Ubuntu, OpenWrt and OS 9 ping each other happily.

I can get a second OpenWrt device and check if they can talk to each other. Lot of work that will be but would eliminate Ubuntu as the issue. It's either that or the atalkd build is bad. Don't know what else to try.

My last hope is for you go 'yeah, no incoming traffic is because you forgot to do an ./arcanecommand withcrazyparams that you missed because you did not RTFM'. If that's the case don't hold back; I can take it.

[APCCV]

Alright. Got into it and set up two OpenWrt boxes back to back.

 ┌────────────────┐   ┌────────────────┐ 
 │    OpenWrt1    │   │    OpenWrt2    │ 
 │ ┌──────┐ ┌───┐ │   │ ┌───┐ ┌──────┐ │ 
 │ │atalkd│ │nic├─┼───┼─┤nic│ │atalkd│ │ 
 │ └──────┘ └─┬─┘ │   │ └───┘ └──────┘ │ 
 └────────────┼───┘   └────────────────┘ 
              └────LAN                   

OpenWrt1 config: br-lan -router -phase 2 -net 6400 -addr 6400.152 -zone "64openwrt"
OpenWrt2 config: br-lan -router -phase 2 -net 6300 -addr 6300.152 -zone "63openwrt"

Boxes can ping each other (to the point I can ssh from one to the other) they are definitely connected at IP level.

Ran atalk -d on both. Both display packages.
OpenWrt1 only displays 6400 packages like this:

packet from 6400.152 on br-lan (5fa) 1 (12)
01 19 00 08 98 19 00 80 19 00 82 19 00 80 19 00 	................
82                                              	.               
(end)

OpenWrt2 only displays 6300 packages:

packet from 6300.152 on br-lan (5fa) 1 (12)
01 18 9C 08 98 18 9C 80 18 9C 82 18 9C 80 18 9C 	................
82                                              	.               
(end)

So they are clearly oblivious to each other.
The syslog looks boringly identical in both:

Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: Set syslog logging to level: debug
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: restart (4.0.4)
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: rtmp: service unknown
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: nbp: service unknown
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: echo: service unknown
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: zip: service unknown
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: rtmp: service unknown
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: nbp: service unknown
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: echo: service unknown
Thu Nov 14 13:58:37 2024 daemon.info atalkd[5649]: zip: service unknown
Thu Nov 14 13:58:38 2024 daemon.info atalkd[5649]: zip_getnetinfo for br-lan
Thu Nov 14 13:58:48 2024 daemon.info atalkd[5649]: zip_getnetinfo for br-lan
Thu Nov 14 13:58:58 2024 daemon.info atalkd[5649]: zip_getnetinfo for br-lan
Thu Nov 14 13:59:08 2024 daemon.info atalkd[5649]: as_timer configured br-lan phase 2 from seed
Thu Nov 14 13:59:08 2024 daemon.info atalkd[5649]: /etc/atalkd.conf not writable, won't rewrite
Thu Nov 14 13:59:08 2024 daemon.info atalkd[5649]: ready 0/0/0

If I run a third atalk -d on my ubuntu laptop (on Wifi on that LAN) it sees itself and the other two:

packet from 6300.152 on wlp0s20f3 (51a) 1 (12)
01 18 9C 08 98 18 9C 80 18 9C 82 18 9C 80 18 9C 	................
82                                              	.               
(end)
packet from 2.2 on wlp0s20f3 (51a) 6 (9)
06 05 00 00 00 00 00 00                         	........        
(end)
packet from 6400.152 on wlp0s20f3 (51a) 1 (12)
01 19 00 08 98 19 00 80 19 00 82 19 00 80 19 00 	................
82                                              	.               
(end)

The Ubuntu instance stops after 5 or 6 2.2 packets as it sees the link is already seeded. OpenWrt1 and 2? They just keep going, endlessly in their blissful ignorance of each other (or the ubuntu instance).
So... it's either:

• some OpenWrt weirdness is dropping incomming DDP packages
• the atalkd build screwed up something and the ARM build on this device is deaf.

Any suggestions of what I can poke into? I'll bash OpenWrt a bit in case something obvious comes up.

[NJRoadfan]

You don't need multiple routers on the network. Only one machine needs the -router switch with network and zone information to seed the other machines. The other machine should just have br-lan on its atalkd.conf, it will pick up the rest of the network information from the router with a GetNetInfo broadcast.

You can also run completely routerless with no zones or assigned networks. Just put in br-lan in atalkd.conf on all the machines.

[APCCV]

Yes, I get that. I put two together to force the error. Three even, counting Ubuntu. Ubuntu behaves as you expect. OpenWrt doesn't
If I set br-lan in atalkd nothing happens after 3 packages. Network doesn't work. Each OpenWrt atalkd instance sees 3 packets. Ubuntu sees 9.

The cause so far for this is that atalkd in OpenWrt never sees incoming packages. Either OpenWrt is dropping incoming DDP or atalkd is ignoring it.

[NJRoadfan]

Make sure multicast is running on the br-lan interface. AppleTalk requires it. You should be seeing incoming broadcast packets addressed to 09:00:07:FF:FF:FF. You should also be seeing AARP traffic on the network with devices announcing themselves and requesting address mapping.

[NJRoadfan]

When atalkd launches, it should send out a burst of AARP broadcast packets checking if an address is on the network. If it receives no response, it assumes it is available and assigns itself that address.

[APCCV]

Hrmm....
I see the burst from the Ubuntu instance. 10 packages.
I don't see the burst from OpenWrt instances.
I'll stop it and start it again.

Thank you for your patience.

[APCCV]

Yeah, OpenWrt instances send 10 AARP when they start too.
Those don't show up on stdout when running atalkd -d. But they all hit the bridge.

What does show up are the other packages.
This:

0:40:17.229393 <mac>:77 > 09:00:07:ff:ff:ff, 802.3, length 37: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Appletalk (0x080007), pid Appletalk (0x809b), length 29: 
	0x0000:  aaaa 0308 0007 809b 001d efa6 0000 189c  ................
	0x0010:  ff98 0101 0118 9c08 9818 9c80 189c 8218  ................
	0x0020:  9c80 189c 82                             .....

Results in this in stdio:

packet from 6300.152 on br-lan (5fa) 1 (12)
01 18 9C 08 98 18 9C 80 18 9C 82 18 9C 80 18 9C 	................
82                                              	.               
(end)

But that is the key symptom of the problem.
This:

20:40:26.499465 <mac>:c9 > 09:00:07:ff:ff:ff, 802.3, length 37: LLC, dsap SNAP (0xaa) Individual, ssap SNAP (0xaa) Command, ctrl 0x03: oui Appletalk (0x080007), pid Appletalk (0x809b), length 29: 
	0x0000:  aaaa 0308 0007 809b 001d 492c 0000 1900  ..........I,....
	0x0010:  ff98 0101 0119 0008 9819 0080 1900 8219  ................
	0x0020:  0080 1900 82                             .....

is not showing up on atalkd -d stdout. Not in OpenWrt. It does in Ubuntu. That is why Ubuntu works and OpenWrt instances don't.

[APCCV]

Just a wild guess...
What's #ifdef NO_DATA_LINK_PASSTHROUGH?

[NJRoadfan]

A dead ifdef from FreeBSD since removed from the codebase, shouldn't be set on Linux.

[APCCV]

I am rebuilding and testing on OpwnWrt 23.05, the stable version.
If you don't mind... this is the interesting bit of the build log for netatalk the SDK cross compiling for an ARM ipq806x device. Does anything here hint to what might be causing the issue?
netatalk-build.txt

[APCCV]

I should be happy... but now I don't know how to tackle this.
So... clean build everything, OpenWrt 23.05. No tweaks or anything... and it works! Yaaay!

Haven't tested it fully yet, but at least the two atalkd instances see each other. atalkd -d lists packages both generated locally and from the other instance. Next step... qemu VM on one end, afpd on the other.

Which means... OpenWrt snapshot (and the soon like in 3 months to be released 24.10) is broken. Hopefully it is royally screwed and the multicasting issues are not just related to AppleTalk.

OpenWrt 24/Snapshot moved from swconfig to DSA for switch management... I assume that would be transparent to AppleTalk but... is it? What do you think?

Edit: oops = bad markup

[NJRoadfan]

If the switch management involves layer 2, then yes, its possible they broke non-IP traffic.

[APCCV]

Alright. File sharing works on OpenWrt 23. This involved a single broadcast domain over bunch of different physical media.

• the qemu OS 9 VM in ubuntu on a tap adapter (no IP addressing - pure AppleTalk)
• an atalkd routing between the Ubuntu bridge where the tap landed and the wireless adapter
• wireless link to an access point
• Access point that does not run the appletalk kext
• LAN segment to the main router
• switch on main router, which does not run the kext either
• LAN segment to an unmanaged switch, the switch, lan segment to OpenWrt "server"
• OpenWrt 23.5 hosting atalkd and afpd

Appletalk behaves while going through WiFi, non-AppleTalk aware access point and main router, and L2 unmanaged switches.
Pretty impressive, what you have managed to support with Netatalk v4.

I'll leave this here for posterity.

[rdmark]

Very well done, impressive work! This feels particularly satisfying because commercial WiFi router firmware has been mangling AppleTalk traffic for 25 years. And now AppleTalk is being routed "natively" on such hardware!

[APCCV]

Thanks!
It's interesting to see a small outdated router (TP-Link DIR 835) with a USB hard disk and (to be tested in the future now that I tamed qemu) USB printer working as a fully functional AppleTalk server. If I still had my souped-up //e, my IIci and my Quadra 650 this thing would fit in right beside them. I assume that with (also to test in the future) macipg then such //e could have IP access. Guess that's what you were after when AppleTalk made it back into netatalk.

It's going to be a while before OpenWrt has fully working AppleTalk, if I don't get told to get lost.

Opened a PR to have the appletalk kernel module built again (it was taken out six years ago). Once (if) it merges it will need backporting to 24.10.
openwrt/openwrt#16979

Opened an issue regarding the inbound traffic problem I saw.
openwrt/openwrt#16983

Also have a backport of Netatalk into the stable version but that for sure I'm going to be told to take a hike.
openwrt/packages#25262

I'll leave them here for reference. With a lot of luck when OpenWrt 24.10 goes out (in January? February?) this will be in.

I will give this a break, at least until I hear of progress on any of those 3 tickets.
Cheers!

[NJRoadfan]

OpenWRT based WiFi access points (and others based on Linux like DD-WRT) work fine with AppleTalk (they don't mangle AARP packets when converting them from 802.11 to Ethernet frames). You can thank the Linux kernel for getting that part right.

[APCCV]

Stumbled upon this...
https://gist.github.com/VinDuv/4db433b6dce39d51a5b7847ee749b2a4

Would that explain the weird bridge behaviour I see on kernel 6.6.81?

With basic configuration atalkd starts like this:

root@TestWrt-65:~# atalkd -d
lo -phase 2 -net 0 -addr 0.0 -caddr 0.0
br-lan -phase 2 -net 65280-65534 -addr 0.0 -caddr 65280.0
packet from 65280.67 on br-lan (12) 6 (9)
06 05 00 00 00 00 00 00                         	........        
(end)

Is the loopback information and issue above causing incoming traffic not to reach atalkd?

It is not possible to just build the appletalk module on OpenWrt... if I figure out a way to patch the build process to include as above suggests I could test it. If you think it's completely irrelevant please stop me from an exercise in futility.

Edit: yeah, futile. No change. My guess is this is DSA related which unfortunately might mean changes to the kernel module. Let's see.

[APCCV]

The investigation about DSA and Appletalk continues. "Frodo lives!" someone wrote.
To be honest, I am not sure if this will end up in a solution. Might as well mean AppleTalk is not supported in OpenWrt (or DSA-enabled systems).
Good news to share is that for now this looks like some incompatibility with 802.3 frames and DSA. It's all in kernel code... net/802, net/llc, and steps before.
Bad news, well, if it's kernel code (mainstream kernel, not even appletalk module) then it is not clear what it would take to fix and when it would be. Although if all 802.3 LLC is broken we should have some leverage.
For now I'll keep working on it on an active thread at openwrt.org and let's see if something comes out of it.