Search results

I simplified the TashRouter config (no explicit network or zone for the tap0 interface), since atalkd has already associated net 3 with tap0 and should be handling it. Unfortunately Mini vMac still can't see the server on net 2. It also no longer sees zones, just like the physical Mac. router =...

Yup, atalkd is now working fine by itself. On the wire, I see a ZIP GNI request and reply, RTMP broadcasts are coming from 2.22 (via vioif0 on the VM), as well as NBP advertising the netatalk server's name: Zone Information Protocol Function: GetNetInfo request (5) Pad (0): 00 Pad...

Hmmm... yes, with TashRouter shut down and restarting atalkd, I now see RTMP coming from 2.22 on vioif0! And there is also RTMP coming from 3.33 on tap0! It's definitely using Netatalk 4.0.9dev. I checked that /etc/rc.d/atalkd pointed to the correct place (/usr/local/sbin/atalkd) and executing...

Running Wireshark on the Ethernet network with the atalk filter, I see the 3 initial ZIP GNI requests when atalkd is starting up, and a bit later, a ZIP GNI reply: Zone Information Protocol Function: GetNetInfo reply (6) 101. .... = Flags: 0x5, Zone invalid, Only one zone 1...

They do indeed: vioif0 -router -phase 2 -net 2 -addr 2.234 -zone "EtherTalk Network" 11:37:01.612518 AT 2.103.253 > 2.234.nis: nbp-brRq 255: "=:AFPServer@EtherTalk Network" 11:37:01.612875 AT 2.234.nis > 0.nis: nbp-lkup 255: "=:AFPServer@EtherTalk Network" [addr=2.103.253] 11:37:01.612932 AT...

That's the odd part. The Mini vMac client *does* see AppleTalk zones when TashRouter is running, and it looks like TashRouter is correctly routing the incoming lookup from LToUDP and writing the AppleTalk nbp-lkup packet to the tap0 interface. But there is no lookup reply, even though the...

Clarification: it isn't actually sending replies. It's now broadcasting RTMP packets from a distinct node. Still not seeing replies for name lookups. 00:48:15.593462 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25 00:48:15.595532 AT 3.147.rtmp > 0.rtmp: at-rtmp 25 <-- this...

OK, a light just went on for me. The intent of TashRouter's TapPort class is to open a tap device, not a tun device. I was confused because the Linux code opens '/dev/net/tun', but the ioctl actually sets IFF_TAP to indicate a tap device (and IFF_NO_PI to indicate no packet info). Changing the...

That sample output tells me that there should be two different nodes registered, one for atalkd and one for TashRouter, but it looks like TashRouter isn't writing any AppleTalk packets to the tap0 interface. I only see AT packets coming from atalkd (3.17) in my case. If I kill TashRouter and...

Current atalkd.conf: tap0 -router -phase 2 -net 3 -addr 3.17 -zone "EtherTalk Network" Startup of atalkd emits these log messages: Dec 17 17:20:37 arm64 atalkd[10038]: Set syslog logging to level: debug Dec 17 17:20:37 arm64 atalkd[10038]: restart (4.0.9dev) Dec 17 17:20:39 arm64 atalkd[10038]...

Thanks, that makes sense and got me past the "can't assign requested address" errors. Yes, I'm creating the tap interface as root and running TashRouter as root. Tried this. Initially atalkd wasn't happy with the single interface specification and kept rewriting my atalkd.conf file as follows...

I had tried your approach (putting both the NIC interface and the tap interface in atalkd.conf, as well as @finkmac 's approach of creating a bridge interface and only including that interface in atalkd.conf. Yours got me further down the path, in that I could see activity on both the LToUDP and...

I am trying to get TashRouter to work in a NetBSD 10.0 VM using QEMU. vmnet bridged networking is used so the VM can be reached directly from other machines. Netatalk 4 is running in the VM with atalk enabled on the interface. Physical machines can see the Netatalk server in the Chooser, so...

The good news is that Netatalk 4.0.9dev is working fine on arm64, running in a NetBSD 10.0 VM (with rebuilt kernel) on a macOS Apple Silicon host. From a PowerBook G3 on the same physical network, connected via AppleTalk-over-Ethernet, I can see the server and copy files to the shared volume...

Excellent, thank you for the pointer! I did not know that had been added to QEMU. This invocation now automagically sets up both the virtual interface and the bridge interface on the host, where en4 is the physical Ethernet interface on the Mac that's hosting the VM: qemu-system-aarch64 \...

Good idea. I updated the AppleTalk section of the NetBSD wiki page to cover this. Today I built and installed Netatalk 4 from the main branch. There's no going back to earlier versions now; full steam ahead! arm64# /usr/local/sbin/atalkd -V atalkd 4.0.9dev - AppleTalk Network Manager Daemon...

Just to confirm, I pulled down cdn.netbsd.org/pub/NetBSD/NetBSD-10.0/source/sets/syssrc.tgz and had a look at /usr/src/sys/arch/evbarm/conf/GENERIC.common. Sure enough, the option for NETATALK is commented out. If I compare with /usr/src/sys/arch/amd64/conf/GENERIC, the NETATALK option is *not*...

That's my guess as well. Using the same QEMU virtual machine parameters, a Debian arm64 installation successfully loads the appletalk module. Yay!! Yes, I am running arm64 (aarch64) VMs on Apple Silicon hardware, so QEMU can take advantage of HVF acceleration. Next step: build and run 4.0.8...

I'm wondering if NetBSD still supports AppleTalk in the kernel "out of the box" as the docs suggest. In the past I've had success building netatalk and running afpd on current macOS systems (which provides AFP over TCP only), but couldn't get atalkd running because there was no kernel support...

That depends. The history of Jasmine with Rodime drives is not great. I had a 20MB Jasmine drive that didn't last all that long. Jasmine itself didn't survive into the '90s. There is a sad coda to Ray Lynch's story. Apparently his home and studio burned down in 2015 and he lost all his...