AppleTalk...again....

[tkaiser]

9 hours ago, fraveydank said:

I'm actually working on fixing some of the routing stuff in netatalk 2.2.5+ (several important patches in git from 2014 that never made it into a release, wonder if they'll ever do a 2.2.6)

 

If not done already simply ask on netatalk-devel list. If you prepare the stuff in a finished state I don't believe Ralph has any objections against releasing a 2.2.6 with fixes applied.

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