AppleTalk...again....

[op1tjaap]

I feel like I have been here before..... I'm trying to get Netatalk working on my OrangePiOne and OrangePiPC. No luck again

 

I have build a custom kernel with only appletalk extra as a module ( appletalk.ko) and used the then created package:

linux-image-dev-sun8i_5.24_armhf.deb

to install this over an image of the beta images site for an orangepizero.

Armbian_5.24.161226_Orangepizero_Ubuntu_xenial_4.9.0.img

The OrangePi boots perfect and I see the new kernel active:

Linux orangepizero 4.9.0macippi-sun8i-g21ddf78-dirty #2 SMP Fri Jan 6 20:08:41 UTC 2017 armv7l armv7l armv7l GNU/Linux

Installed Netatalk after this and it is running fine...only no appletalk or AFP over DDP... very frustrating!!

 

I can aecho to its own address, but not to other Macintosh

root@orangepizero:~# nbplkup
                   orangepizero:netatalk                           65280.235:4
                   orangepizero:Workstation                        65280.235:4
root@orangepizero:~# aecho 65280.235
14 bytes from 65280.235: aep_seq=0. time=0. ms
14 bytes from 65280.235: aep_seq=1. time=0. ms
14 bytes from 65280.235: aep_seq=2. time=0. ms
14 bytes from 65280.235: aep_seq=3. time=0. ms
14 bytes from 65280.235: aep_seq=4. time=0. ms 

root@orangepizero:~# aecho 65280.129
^C
----65280.129 AEP Statistics----
4 packets sent, 0 packets received, 100% packet loss

Wit tcpdump I see a lot of tuncated packages / errors:

23:08:58.212531 AT 65395.129.253 > 0.nis:  nbp-lkup 25: "=:AFPServ[|atalk]
23:08:58.722110 AT 65395.129.253 > 0.nis:  truncated-nbp 9
23:08:59.038331 AT 65395.129.253 > 0.nis:  nbp-lkup 25: "=:AFPServ[|atalk]
23:08:59.860710 AT 65395.129.253 > 0.nis:  nbp-lkup 25: "=:AFPServ[|atalk]
23:08:59.874674 AT 65280.235.nis > 0.nis:  nbp-lkup 1: "=:=@*" [addr=65280.235.128]
23:09:00.685779 AT 65395.129.253 > 0.nis:  nbp-lkup 25: "=:AFPServ[|atalk]
23:09:01.521082 AT 65395.129.253 > 0.nis:  nbp-lkup 25: "=:AFPServ[|atalk]
23:09:01.876643 AT 65280.235.nis > 0.nis:  nbp-lkup 1: "=:=@*" [addr=65280.235.128]
23:09:15.188213 AT 65395.129.253 > 0.nis:  truncated-nbp 9
23:09:16.029066 AT 65395.129.253 > 0.nis:  truncated-nbp 9

On my older image with adjusted kernel 4.6.0 and appletalk  everything is working fine. At nbplkup looks like this:

|  \/  | __ _  ___|_ _|  _ \ _ __ (_)
| |\/| |/ _` |/ __|| || |_) | '_ \| |
| |  | | (_| | (__ | ||  __/| |_) | |
|_|  |_|\__,_|\___|___|_|   | .__/|_|
                            |_|

Welcome to ARMBIAN Debian GNU/Linux stretch/sid 4.6.0-rc1-macipgw-op1-sunxi
Made possible on an OrangePiOne
System load:   0.56             Up time:       1 min
Memory usage:  14 % of 495Mb    IP:            192.168.178.67
Usage of /:    82% of 3.4G

Last login: Sun Jan  8 00:02:14 2017 from 192.168.178.14
root@orangepione:~# nbplkup
                    OrangePiOne:AFPServer                          65280.223:129
                     172.16.2.1:IPGATEWAY                          65280.223:72
                    orangepione:netatalk                           65280.223:4
                    orangepione:Workstation                        65280.223:4
                     BasiliskII:AFPServer                          65395.129:249
                     172.16.2.4:IPADDRESS                          65395.129:72
                     BasiliskII:PPCToolBox                         65395.129:251
                     BasiliskII:  Macintosh                        65395.129:252
                     BasiliskII:Workstation                        65395.129:4
           AsantéTalk 940863E7:Asant▒Talk                         65330.7:252

tcpdump looks also more healty:

root@orangepione:~# tcpdump -i eth0|grep AT
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:41:37.351701 AT 65395.129.253 > 0.nis:  nbp-lkup 134: "=:=@*"
00:41:37.351896 AT 65280.223.nis > 65395.129.253:  nbp-reply 134: "OrangePiOne:AFPServer@*"(0) 129 "172.16.2.1:IPGATEWAY@*" 72 "orangepione:netatalk@*"(2) 4 "orangepione:Workstation@*"(3) 4
00:41:38.192129 AT 65395.129.253 > 0.nis:  nbp-lkup 134: "=:=@*"
00:41:38.192306 AT 65280.223.nis > 65395.129.253:  nbp-reply 134: "OrangePiOne:AFPServer@*"(0) 129 "172.16.2.1:IPGATEWAY@*" 72 "orangepione:netatalk@*"(2) 4 "orangepione:Workstation@*"(3) 4
00:41:39.039719 AT 65395.129.253 > 0.nis:  nbp-lkup 134: "=:=@*"
00:41:39.039852 AT 65280.223.nis > 65395.129.253:  nbp-reply 134: "OrangePiOne:AFPServer@*"(0) 129 "172.16.2.1:IPGATEWAY@*" 72 "orangepione:netatalk@*"(2) 4 "orangepione:Workstation@*"(3) 4
00:41:39.886361 AT 65395.129.253 > 0.nis:  nbp-lkup 134: "=:=@*"
00:41:39.886524 AT 65280.223.nis > 65395.129.253:  nbp-reply 134: "OrangePiOne:AFPServer@*"(0) 129 "172.16.2.1:IPGATEWAY@*" 72 "orangepione:netatalk@*"(2) 4 "orangepione:Workstation@*"(3) 4
00:41:42.250885 AT 65395.129.253 > 0.nis:  nbp-lkup 135: "=:AFPServer@*"
00:41:42.251074 AT 65280.223.nis > 65395.129.253:  nbp-reply 135: "OrangePiOne:AFPServer@*"(0) 129
00:41:43.088403 AT 65395.129.253 > 0.nis:  nbp-lkup 135: "=:AFPServer@*"
00:41:43.088539 AT 65280.223.nis > 65395.129.253:  nbp-reply 135: "OrangePiOne:AFPServer@*"(0) 129

The log file from this one can be found here:

 

http://sprunge.us/JAEI

 

 

 

Nothing to see from my Basilisk II emulator too. Should be....

 

 

 

I hoped that with a newer kernel the Ethernet problems of the Orange Pi where solved,

See my armbianmonitor -u output on:

 

http://sprunge.us/XEca

 

 

I love to have a working ethernet card WITH Apple talk for my project "The MacIPpi". See all about it on:

 

https://forum.armbian.com/index.php/topic/932-appletalk-on-an-orange-pi-one/

[fraveydank]

No, I don't think he does; I'm mostly planning on submitting it as an SF pull request, which should be easiest to integrate. Given the other patches (which address serious issues with running an AppleTalk server, which is the only reason one would use 2.x anymore) are from 2014, I have to imagine a 2.2.6 release would be useful just as an intended-final release of 2.x.

 

Now that I think about it, I may have conversed with you on the netatalk-devel lists before; I never put the names together. :-)

[op1tjaap]

 

I will use Netatalk 2.2.6 definitely on the MacIPpi project when it is released.
For now I’m finishing the new MacIPpi version 4. With dwmac-sun8i driver on board.
No more RX errors and 24x7 uptime.

I have posted the armbianmonitor –u outcome here:
http://sprunge.us/ZFQA

I see some errors but not sure if they are vital / fatal:

 [    9.954710] Generic PHY stmmac-0:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=stmmac-0:01, irq=-1)
[    9.956413] dwmac-sun8i 1c30000.ethernet eth0: No MAC Management Counters available
[    9.956423] dwmac-sun8i 1c30000.ethernet eth0: PTP not supported by HW
[    9.956618] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   11.841029] NET: Registered protocol family 5
[   11.999219] dwmac-sun8i 1c30000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   11.999262] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[28319.318710] ------------[ cut here ]------------
[28319.318740] WARNING: CPU: 0 PID: 0 at kernel/time/tick-sched.c:791 __tick_nohz_idle_enter+0x251/0x368
[28319.318743] Modules linked in: appletalk binfmt_misc evdev sun8i_codec_analog snd_soc_core snd_pcm_dmaengine snd_pcm uio_pdrv_genirq uio cpufreq_dt thermal_sys gpio_keys
[28319.318781] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-next-20170424-macippi-sun8i #1
[28319.318784] Hardware name: Allwinner sun8i Family
[28319.318804] [<c010b98d>] (unwind_backtrace) from [<c0108f37>] (show_stack+0xb/0xc)
[28319.318818] [<c0108f37>] (show_stack) from [<c045cc6f>] (dump_stack+0x67/0x74)
[28319.318832] [<c045cc6f>] (dump_stack) from [<c0117db9>] (__warn+0xa9/0xbc)
[28319.318842] [<c0117db9>] (__warn) from [<c0117e37>] (warn_slowpath_null+0x13/0x18)
[28319.318852] [<c0117e37>] (warn_slowpath_null) from [<c016a5ed>] (__tick_nohz_idle_enter+0x251/0x368)
[28319.318865] [<c016a5ed>] (__tick_nohz_idle_enter) from [<c011ba6f>] (irq_exit+0x9f/0xdc)
[28319.318876] [<c011ba6f>] (irq_exit) from [<c015103b>] (__handle_domain_irq+0x3f/0x7c)
[28319.318887] [<c015103b>] (__handle_domain_irq) from [<c010133f>] (gic_handle_irq+0x3b/0x70)
[28319.318897] [<c010133f>] (gic_handle_irq) from [<c01097a5>] (__irq_svc+0x65/0x94)
[28319.318901] Exception stack(0xc0b01f40 to 0xc0b01f88)
[28319.318910] 1f40: 00000001 00000000 00000000 c0114201 c0b00000 c0b03d0c c0b03cac c0a57278
[28319.318918] 1f60: c0b01f98 00000000 00000000 00000000 00000000 c0b01f90 c0106881 c0106882
[28319.318922] 1f80: 400f0033 ffffffff
[28319.318933] [<c01097a5>] (__irq_svc) from [<c0106882>] (arch_cpu_idle+0x22/0x24)
[28319.318945] [<c0106882>] (arch_cpu_idle) from [<c0143a3d>] (do_idle+0x105/0x160)
[28319.318955] [<c0143a3d>] (do_idle) from [<c0143c5f>] (cpu_startup_entry+0x13/0x14)
[28319.318967] [<c0143c5f>] (cpu_startup_entry) from [<c0a00a09>] (start_kernel+0x2f3/0x2fe)
[28319.318971] ---[ end trace d57c8857527abe92 ]---
[29501.280692] NET: Unregistered protocol family 5

 

[fraveydank]

Interestingly, it looks like the AppleTalk routing issue is actually an issue in the kernel AppleTalk layer; at some point, it stopped finding the correct socket for broadcast packets received and just went with the first socket with a matching port (ignoring the receive interface's address ranges).  Working on fixing that now... no idea how long that's been in the kernel, though I suspect it's been quite a while.

 

Even if it doesn't involve a new patch, I'll probably still suggest a 2.2.6 release because the latest post-2.2.5 patches are critical to anyone using real AppleTalk.

 

One of these days, I want to make a userland daemon that just runs on BPF for platforms which no longer support AppleTalk natively, especially if it can be made to share metadata with netatalk 3.x.  Alas, I'm short on round tuits...

[tkaiser]

5 hours ago, fraveydank said:

it looks like the AppleTalk routing issue is actually an issue in the kernel AppleTalk layer

 

Not that surprising. IIRC some critical AppleTalk fixes never made it into the Linux kernel. But this has been long ago (IIRC even prior to Netatalk 2.0 release and that was IIRC in 2004). On production machines we tried to avoid Linux back at that time if AppleTalk was involved (only needed for printing any more) so we ended up with Solaris as host, SuSE when trying to use AppleTalk (since their kernel contained loads of AppleTalk related stuff) or an OS X machine accessible through IPP speaking PAP with old printers (printer proxy).

[fraveydank]

Well, in good news, after a few days of thinking on it (because I haven't had time to actually work on it), it ended up being just a two line addition.

 

When finding the correct socket to deliver to, if the destination address is broadcast net and node, the Linux implementation just delivers to the first socket it finds open with the correct port. This is, obviously, problematic for routers, since they have a bunch of sockets open (one for each interface) on specific ports. Thus I was getting all sorts of weird AppleTalk errors because the initial probes were only getting responded to half the time (when they weren't broadcast messages). A little bit of extra checking to make sure that the socket net is within the range of the receiving interface's network range takes care of the problem and now my multi-zone, routed network is happy again. :-)

 

The Linux AppleTalk layer really is messy, inefficient garbage, though. Fortunately, barely anyone is likely to be using it for more than a few Mbps at a time these days (I'd be really surprised if anyone is managing whole campus AppleTalk backbones now), so that's unlikely to be a roadblock to anyone. But I'll still submit my pull request upstream, see what happens.

[fraveydank]

In any case, if you want a patch, I'll be happy to supply it, since I have no idea how long it'll be until it's mainlined. It's only of interest if you're using multiple interfaces, though, which is low-likelihood for your particular use case.