fraveydank

Members
  • Content Count

    15
  • Joined

  • Last visited


Reputation Activity

  1. Like
    fraveydank got a reaction from op1tjaap in AppleTalk...again....   
    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...
  2. Like
    fraveydank got a reaction from op1tjaap in AppleTalk...again....   
    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. :-)
  3. Like
    fraveydank got a reaction from op1tjaap in AppleTalk...again....   
    I don't know of any extant, no. It woudn't be the hardest thing in the world, though doing the DPLL for the serial decoding isn't the most pleasant thing in the world. The PSoC is probably easier to get started on and has easier tools, but the CPLD/FPGA is the "right" way.
     
    It's also worth noting that most small micros are way more than powerful enough to do AppleTalk routing at a scale that could handle reasonably large networks. You might find the ESP32 with something tied on to do the LocalTalk decoding to be an ideal platform; it's well more powerful than most AppleTalk routers that existed out in the world short of the high end Cisco multiprotocol routers and such (and even then, it's only smaller RAM, still a faster CPU). But you'd have to write the AppleTalk stack from scratch, most likely. It's something I have way back on my queue whenever I plow through the pile of projects currently on my plate.
  4. Like
    fraveydank got a reaction from op1tjaap in AppleTalk...again....   
    I'm also active on mac68k.info (more interested in the low-level stuff the cover, and can't keep up with the forum traffic on 68kmla).  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); the routing is broken and it's screwing up my home network, which also encompasses a VAX and an Alpha running VMS (with Pathworks for Mac).
     
    FWIW, while I like the idea of small ARM boards as AppleTalk routers/MacIP gateways, I wish there was a better way to get LocalTalk signals through. The rather high-speed serial decoding must be super ugly to do on the Linux GPIO layer, but a small CPLD/FPGA or a PSoC or similar might do the trick connected over SPI. Relying on something like an Asante bridge seems just about as problematic. :-)