TashRouter: An AppleTalk Router

shirsch · Oct 16, 2024

I'm running Tashrouter on an RPi under Debian Bullseye. What is the best approach for making it start automatically at boot?

finkmac · Oct 16, 2024

I set up a systemd service for tashrouter. I posted about it earlier in the thread.

shirsch · Oct 16, 2024

Ack - nevermind. I found a suggested systemd unit file in an earlier post. That seems to have done the trick..

Heh - we crossed in the wires. That is working - thanks.

NJRoadfan · Nov 3, 2024

Note for those running Linux kernel 6.9 or newer. It appears that a regression has been introduced that NBPReply packets are being duplicated and sent out with a source address of 0.0 whenever netatalk replies to NBP Requests. These packets will crash TashRouter and leave it running in an unrecoverable state since it can't currently handle packets when an origin of 0.0. I have submitted a pull request that fixes this here: https://github.com/lampmerchant/tashrouter/pull/9

The patch simply drops these packets since an address of 0.0 is not valid on an extended network.

slipperygrey · Nov 4, 2024

NJRoadfan said:
Note for those running Linux kernel 6.9 or newer. It appears that a regression has been introduced that NBPReply packets are being duplicated and sent out with a source address of 0.0 whenever netatalk replies to NBP Requests. These packets will crash TashRouter and leave it running in an unrecoverable state since it can't currently handle packets when an origin of 0.0. I have submitted a pull request that fixes this here: https://github.com/lampmerchant/tashrouter/pull/9

The patch simply drops these packets since an address of 0.0 is not valid on an extended network.

Have you escalated this to the kernel devs?

NJRoadfan · Nov 4, 2024

I did post a note on the patch author's gist regarding the issue. I am trying to determine the source of the problem first before escalating.

NJRoadfan · Nov 4, 2024

This maybe a bug in Netatalk. I "unpatched" the kernel module and looked at the logs. Netatalk sends out duplicate NBP Reply packets even with the unpatched module, the difference is that the origin address in the DDP header is all the same. Its sending out one for each interface on the machine, including the loopback which has an address of `0.0`.

thecloud · Dec 17, 2024

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 connectivity is working. But Mini vMac v37 instances can't see the server, and so something that routes to LToUDP is needed.

Code:

router = Router('router', ports=(                                                                                                 
  LtoudpPort(seed_network=1, seed_zone_name=b'LToUDP Network'),                                                                   
#  TapPort(tap_name='tap0', hw_addr=b'\xF2\x0B\xA4\xE1\xF9\x2E'),                                                                 
#  TapPort(tap_name='tap0', hw_addr=b'\xF2\x0B\xA4\xE1\xF9\x2E', seed_network_min=3, seed_network_max=5, seed_zone_names=[b'EtherTalk Network']),                                                                                                                     
  TapPort(tap_name='vether0', hw_addr=b'\xF2\x0B\xA4\x41\x01\xC4', seed_network_min=3, seed_network_max=5, seed_zone_names=[b'EtherTalk Network']),                                                                                                                 
))

After creating a tap0 interface, the first issue I ran into is that TapPort initialization tries to open a tun device at '/dev/net/tun'. Since this is BSD, the tun device is at '/dev/tun0'. I tried changing that line and was able to open the tun device, but the ioctl call on the next line fails. Commenting it out allows TashRouter to come up without errors and create zones successfully. But I suspect commenting out the ioctl is the wrong thing to do.

Code:

arm64$ ifconfig -a
vioif0: flags=0x8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x1<VLAN_MTU>
        ec_enabled=0x1<VLAN_MTU>
        address: 52:54:00:f0:0d:01
        status: active
        atalk 65280.111 phase 2 range 1 - 65534 broadcast 65280.255
        inet6 fe80::5054:ff:fef0:d01%vioif0/64 flags 0 scopeid 0x1
        inet6 fd7c:c94b:1296:3149:d476:7e:b20c:e5b/64 flags 0x40<AUTOCONF>
        inet 192.168.11.248/24 broadcast 192.168.11.255 flags 0
lo0: flags=0x8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 33624
        status: active
        atalk 0.0 phase 2
        inet6 ::1/128 flags 0x20<NODAD>
        inet6 fe80::1%lo0/64 flags 0 scopeid 0x2
        inet 127.0.0.1/8 flags 0
tap0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
        ec_enabled=0
        address: f2:0b:a4:e1:f9:2e
        status: no carrier
        inet6 fe80::f00b:a4ff:fee1:f92e%tap0/64 flags 0x8<DETACHED> scopeid 0x3
bridge0: flags=0x41<UP,RUNNING> mtu 1500
        status: active
tun0: flags=0x10<POINTOPOINT> mtu 1500
        status: down
vether0: flags=0x8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x5<VLAN_MTU,JUMBO_MTU>
        ec_enabled=0x1<VLAN_MTU>
        address: f2:0b:a4:41:01:c4
        status: active
        inet6 fe80::f00b:a4ff:fe41:1c4%vether0/64 flags 0 scopeid 0x6

vioif0 is the interface with the IPv4 address that's visible from the network.
tap0 was manually created.
bridge0 was also manually created (combining tap0 and vioif0). I was trying to use that initially but atalkd barfs if I try to specify the bridge0 interface in atalkd.conf.
tun0 is opened by TashRouter as part of TapPort setup. It's down because TashRouter isn't running at the moment.
vether0 was also manually created. It's supposed to be the replacement for tap interfaces in NetBSD 10.0:

Code:

In NetBSD 10.0 and later, it will become necessary to use vether instead of tap as a bridge endpoint. vether is unavailable in previous releases.

I've read this long thread multiple times and realize that most folks seem to be using Debian Linux instead of NetBSD, but I feel like I'm probably missing something simple and it shouldn't be too difficult to get this working.

NJRoadfan · Dec 17, 2024

Save yourself the hassle and use atalkd to route between your host network interface and the tap interface. Yes, that involves an extra hop over a virtual bridge, but it will save your sanity of VM routing. In A2SERVER, I have tashrouter linked to atalkd using a tap interface called tash0. In atalkd.conf, I have two lines, one for the host NIC (eth0) and one for the tap interface (tash0).

thecloud · Dec 17, 2024

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 tap0 interfaces, but neither are sending packets back for incoming LToUDP queries.

atalkd.conf

Code:

vioif0 -seed -phase 2 -net 2 -addr 2.222 -zone "EtherTalk Network"
tap0 -seed -phase 2 -net 3 -addr 3.141 -zone "EtherTalk Network"

route.py (snippet)

Code:

router = Router('router', ports=(                                                                                                 
  LtoudpPort(seed_network=1, seed_zone_name=b'LToUDP Network'),                                                                   
#  TapPort(tap_name='tap0', hw_addr=b'\xF2\x0B\xA4\xE1\xF9\x2E'),                                                                 
  TapPort(tap_name='tap0', hw_addr=b'\xF2\x0B\xA4\xE1\xF9\x2E', seed_network_min=3, seed_network_max=5, seed_zone_names=[b'EtherTalk Network']),                                                                                                                     
))

With this configuration, if TashRouter is not running, then atalkd starts up fine and I subsequently can start netatalk and it all works, except LToUDP obviously can't see my netatalk server. If TashRouter is running when I start up atalkd, then I get these errors and atalkd exits:

Code:

Dec 16 19:49:39 arm64 atalkd[1466]: zip_getnetinfo for vioif0
Dec 16 19:49:39 arm64 atalkd[1466]: zip_getnetinfo for vioif0
Dec 16 19:49:39 arm64 atalkd[1466]: zip_getnetinfo for vioif0
Dec 16 19:50:10 arm64 atalkd[1466]: as_timer configured vioif0 phase 2 from seed
Dec 16 19:50:10 arm64 atalkd[1466]: as_timer: can't route 2.222 to loop: File exists
Dec 16 19:50:10 arm64 atalkd[1466]: difaddr(0.0): Can't assign requested address

Alternatively: if atalkd.conf is empty, and I start atalkd with TashRouter already running, then the Mini vMac v37 instances see the two zones and opening AppleShare in the Chooser causes this activity:

Code:

2024-12-16 21:42:08,239 DEBUG: frame in              LToUDP 254  32  type 01          b'\x00\x1a\x02\xfe\x02\x11\r\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-16 21:42:08,241 DEBUG: in to 1.254           LToUDP  0 0.254 0.32    2 254 2  b'\x11\r\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-16 21:42:08,242 DEBUG: out to LToUDP Network LToUDP  0 0.255 1.254   2   2 2  b'!\r\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-16 21:42:08,242 DEBUG: frame out             LToUDP 255 254  type 01          b'\x00\x1a\x02\x02\x02!\r\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-16 21:42:09,775 DEBUG: out broadcast         LToUDP  0 0.255 1.254   1   1 1  b'\x00\x01\x08\xfe\x00\x00\x82\x00\x03\x80\x00\x05\x82'
2024-12-16 21:42:09,777 DEBUG: frame out             LToUDP 255 254  type 01          b'\x00\x12\x01\x01\x01\x00\x01\x08\xfe\x00\x00\x82\x00\x03\x80\x00\x05\x82'
2024-12-16 21:42:09,777 DEBUG: out broadcast         tap0    0 0.255 3.141   1   1 1  b'\x00\x03\x08\x8d\x00\x03\x80\x00\x05\x82\x00\x01\x00'
2024-12-16 21:42:09,777 DEBUG: frame out             tap0   090007FFFFFF F20BA4583A2A b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00\x1a\xb4\xf6\x00\x00\x00\x03\xff\x8d\x01\x01\x01\x00\x03\x08\x8d\x00\x03\x80\x00\x05\x82\x00\x01\x00'

No response ever comes back with the AFP server name. Presumably that's expected because with an empty atalkd.conf, the server is running in vioif0 and there is no connection with the tap0 interface. The light hasn't come on for me yet.

Tashtari · Dec 17, 2024

thecloud said:
But I suspect commenting out the ioctl is the wrong thing to do.

Actually, it may not be the wrong thing to do... memory's a little hazy on the details but I think the way Linux works with tun/tap is that you open /dev/net/tun and then use TUNSETIFF to select the specific device to use - and pass the IFF_NO_PI flag to disable an extra frame header of some kind. If BSD has you open the device directly and just provides unadorned raw frames by default, what you describe may be the right approach. Might be sensible to add support for that to TapPort in the codebase since NetBSD's support for AppleTalk means a lot of potential TashRouter users will be using it...

NJRoadfan · Dec 17, 2024

thecloud said:
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 tap0 interfaces, but neither are sending packets back for incoming LToUDP queries.

No response ever comes back with the AFP server name. Presumably that's expected because with an empty atalkd.conf, the server is running in vioif0 and there is no connection with the tap0 interface. The light hasn't come on for me yet.

Set TashRouter's seed_network_max=3. The seed configuration between the two routers has to match (network range 3-3, zone name "EtherTalk Network"). Also, you likely have to create the tap interface as root and run TashRouter as root. This was the case under Linux.

Optionally, you can setup atalkd with just tap0 on the second line, and let TashRouter be the only seed router.

thecloud · Dec 17, 2024

NJRoadfan said:
Set TashRouter's seed_network_max=3. The seed configuration between the two routers has to match (network range 3-3, zone name "EtherTalk Network").

Thanks, that makes sense and got me past the "can't assign requested address" errors.

NJRoadfan said:
Also, you likely have to create the tap interface as root and run TashRouter as root. This was the case under Linux.

Yes, I'm creating the tap interface as root and running TashRouter as root.

NJRoadfan said:
Optionally, you can setup atalkd with just tap0 on the second line, and let TashRouter be the only seed router.

Tried this. Initially atalkd wasn't happy with the single interface specification and kept rewriting my atalkd.conf file as follows:

Code:

vioif0 -phase2 -net 1-65534 -addr 65280.183

but I got it to keep the tap0 interface by adding the -router option:

Code:

tap0 -router -phase 2 -net 3 -addr 3.141 -zone "EtherTalk Network"

TashRouter configuration:

Code:

router = Router('router', ports=(
  LtoudpPort(seed_network=1, seed_zone_name=b'LToUDP Network'),
  TapPort(tap_name='tap0', hw_addr=b'\xF2\x0B\xA4\x58\x3A\x2A', seed_network_min=3, seed_network_max=3, seed_zone_names=[b'EtherTalk Network']),
))

The Netatalk server is running on net 3, node 141 as specified in atalkd.conf:

Code:

Dec 17 13:41:34 arm64 afpd[8910]: Puppet Head:AFPServer@* started on 3.141:128 (4.0.9dev)
Dec 17 13:41:34 arm64 afpd[8910]: Netatalk AFP/TCP listening on 192.168.11.248:548

arm64# nbplkup
                    Puppet Head:AFPServer                          3.141:128
                          arm64:netatalk                           3.141:4
                          arm64:Workstation                        3.141:4

But still no luck. Opening the Chooser and selecting AppleShare from a Mini vMac v37 instance on a different machine causes the following repeating activity in TashRouter, but the AFP server never appears.

Code:

2024-12-17 13:58:30,891 DEBUG: frame in                 LToUDP 254  32  type 01          b'\x00\x1a\x02\xfe\x02\x11<\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-17 13:58:30,892 DEBUG: in to 1.254              LToUDP  0 0.254 0.32    2 254 2  b'\x11<\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-17 13:58:30,893 DEBUG: out to EtherTalk Network tap0    0 0.255 3.48    2   2 2  b'!<\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-17 13:58:30,894 DEBUG: frame out                tap0   0900070000A6 F20BA4583A2A b'\xaa\xaa\x03\x08\x00\x07\x80\x9b\x00"k\xab\x00\x00\x00\x03\xff0\x02\x02\x02!<\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-17 13:58:30,894 DEBUG: out to EtherTalk Network LToUDP  0 0.255 1.254   2   2 2  b'!<\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
2024-12-17 13:58:30,894 DEBUG: frame out                LToUDP 255 254  type 01          b'\x00\x1a\x02\x02\x02!<\x00\x01 \xfe\x00\x01=\tAFPServer\x01*'
(sequence repeats until Chooser is closed)

Does this output look expected, or should there be more messages here when a lookup for AFPServer takes place? My node is at 3.141 so what is 3.48? Sorry if these are dumb questions. I know Debian would probably Just Work but I'm learning lots here.

NJRoadfan · Dec 17, 2024

Something isn't working still. Maybe TashRouter still needs tweaking to work with a tap interface on NetBSD. If everything was working properly, atalkd should have sent a ZIP GetNetInfo packet over the tap interface, and TashRouter would have responded with the setup information. Running something like tcpdump or equivalent should show periodic RTMP packets coming from both atalkd and TashRouter advertising their routes.

thecloud · Dec 18, 2024

NJRoadfan said:
Something isn't working still. Maybe TashRouter still needs tweaking to work with a tap interface on NetBSD. If everything was working properly, atalkd should have sent a ZIP GetNetInfo packet over the tap interface, and TashRouter would have responded with the setup information. Running something like tcpdump or equivalent should show periodic RTMP packets coming from both atalkd and TashRouter advertising their routes.

Current atalkd.conf:

Code:

tap0 -router -phase 2 -net 3 -addr 3.17 -zone "EtherTalk Network"

Startup of atalkd emits these log messages:

Code:

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]: zip_getnetinfo for tap0
Dec 17 17:21:10 arm64 atalkd[10038]: as_timer configured tap0 phase 2 from seed
Dec 17 17:21:10 arm64 atalkd[10038]: ready 0/0/0

Output of tcpdump -i tap0 as atalkd starts up:

Code:

17:20:36.277053 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25
17:20:37.549041 aarp probe 3.17 tell 3.17
17:20:37.763866 aarp probe 3.17 tell 3.17
17:20:37.979615 aarp probe 3.17 tell 3.17
17:20:38.193062 aarp probe 3.17 tell 3.17
17:20:38.411792 aarp probe 3.17 tell 3.17
17:20:38.627214 aarp probe 3.17 tell 3.17
17:20:38.839966 aarp probe 3.17 tell 3.17
17:20:39.053254 aarp probe 3.17 tell 3.17
17:20:39.268254 aarp probe 3.17 tell 3.17
17:20:39.486144 aarp probe 3.17 tell 3.17
17:20:39.706853 AT 3.17.zip > 0.zip:  at-#6 7
17:20:47.111155 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25
17:20:50.559316 AT 3.17.zip > 0.zip:  at-#6 7
17:20:57.963401 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25
17:21:00.485033 AT 3.17.zip > 0.zip:  at-#6 7
17:21:08.799109 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25
17:21:10.488840 AT 3.17.rtmp > 0.rtmp:  at-rtmp 16
17:21:10.513663 AT 3.17.nis > 0.nis:  nbp-lkup 1: "arm64:Workstation@EtherTalk Network" [addr=3.17.129]

NJRoadfan · Dec 18, 2024

atalkd is emitting the right packets. When you fire up TashRouter, does anything pop up? You should see a burst of AARP probes from TashRouter at a minimum, then eventually periodic RTMP packets roughly every 10 seconds. You will see them from both atalkd's address (3.17) and TashRouter's address.

NJRoadfan · Dec 18, 2024

Here is a sample output from one of my test VMs with A2SERVER. I manually started TashRouter (6502.183) and then atalkd (6502.16).

Code:

21:20:22.418742 aarp probe 6502.183 tell 6502.183 <-- TashRouter AARP Probe
21:20:22.622576 aarp probe 6502.183 tell 6502.183
21:20:22.823363 aarp probe 6502.183 tell 6502.183
21:20:23.030881 aarp probe 6502.183 tell 6502.183
21:20:23.249912 aarp probe 6502.183 tell 6502.183
21:20:42.228050 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13 <-- TashRouter RTMP Broadcast
21:20:49.534324 aarp probe 6502.16 tell 6502.16 <--atalkd AARP Probe
21:20:49.644321 aarp probe 6502.16 tell 6502.16
21:20:49.754553 aarp probe 6502.16 tell 6502.16
21:20:49.863303 aarp probe 6502.16 tell 6502.16
21:20:49.974067 aarp probe 6502.16 tell 6502.16
21:20:50.081714 aarp probe 6502.16 tell 6502.16
21:20:50.206146 aarp probe 6502.16 tell 6502.16
21:20:50.322874 aarp probe 6502.16 tell 6502.16
21:20:50.432162 aarp probe 6502.16 tell 6502.16
21:20:50.537790 aarp probe 6502.16 tell 6502.16
21:20:50.674464 AT 6502.16.zip > 0.zip:  at-#6 7 <-- atalkd broadcasts ZIP GetNetInfo
21:20:50.674743 AT 6502.183.zip > 6502.16.zip:  at-#6 23 <-- TashRouter ZIP GNI Reply
21:20:52.769330 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13
21:21:00.694437 aarp who-has 6502.183 tell 6502.16 <-- atalkd AARP probe for TashRouter's MAC
21:21:00.694542 aarp reply 6502.183 is-at aa:bb:cc:dd:11:22 (oui Unknown) <-- AARP Reply
21:21:00.694545 AT 6502.16.zip > 6502.183.zip:  at-#6 6 <-- Zone list queries between routers
21:21:00.694803 AT 6502.183.zip > 6502.16.zip:  at-#6 13<-|
21:21:00.694816 AT 6502.183.zip > 6502.16.zip:  at-#6 13<-|
21:21:02.775702 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13
21:21:12.778709 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13
21:21:21.480525 AT 6502.16.nis > 0.nis:  nbp-lkup 1: "debtest:Workstation@A2SERVER" [addr=1.232.129]
21:21:21.480536 AT 6502.16.nis > 5.0.nis:  nbp-0x41  1 (34)
21:21:22.803635 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13
21:21:24.186877 AT 6502.16.nis > 0.nis:  nbp-lkup 1: "debtest:Workstation@A2SERVER" [addr=1.232.129]
21:21:24.186890 AT 6502.16.nis > 5.0.nis:  nbp-0x41  1 (34)
21:21:27.039251 AT 6502.16.nis > 0.nis:  nbp-lkup 1: "debtest:Workstation@A2SERVER" [addr=1.232.129]
21:21:27.039262 AT 6502.16.nis > 5.0.nis:  nbp-0x41  1 (34)
21:21:30.428495 AT 6502.16.nis > 0.nis:  nbp-lkup 1: "debtest:netatalk@A2SERVER" [addr=1.232.129]
21:21:30.428505 AT 6502.16.nis > 5.0.nis:  nbp-0x41  1 (31)
21:21:30.820757 AT 6502.16.rtmp > 0.rtmp:  at-rtmp 16 <-- atalkd RTMP broadcast
21:21:32.702748 AT 6502.16.nis > 0.nis:  nbp-lkup 1: "debtest:netatalk@A2SERVER" [addr=1.232.129]
21:21:32.702759 AT 6502.16.nis > 5.0.nis:  nbp-0x41  1 (31)
21:21:32.822130 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13
21:21:35.927102 AT 6502.16.nis > 0.nis:  nbp-lkup 1: "debtest:netatalk@A2SERVER" [addr=1.232.129]
21:21:35.927113 AT 6502.16.nis > 5.0.nis:  nbp-0x41  1 (31)
21:21:39.936714 AT 6502.183.zip > 6502.16.zip:  at-#6 4
21:21:39.936742 AT 6502.16.zip > 6502.183.zip:  at-#6 13
21:21:40.682334 AT 6502.16.rtmp > 0.rtmp:  at-rtmp 16 <--- Everything is configured, both routers broadcast periodic RTMP packets when idle.
21:21:42.831792 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13
21:21:52.138134 AT 6502.16.rtmp > 0.rtmp:  at-rtmp 16
21:21:52.843334 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13
21:22:00.791387 AT 6502.16.rtmp > 0.rtmp:  at-rtmp 16
21:22:02.852991 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13
21:22:11.672702 AT 6502.16.rtmp > 0.rtmp:  at-rtmp 16
21:22:12.856078 AT 6502.183.rtmp > 0.rtmp:  at-rtmp 13

thecloud · Dec 18, 2024

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 then start it back up with atalkd still active, I see the following activity:

Code:

22:08:36.987646 AT 3.17.rtmp > 0.rtmp:  at-rtmp 16
22:08:41.748276 IP dhcp248.home.lan > 239.192.76.84: igmp v2 report 239.192.76.84
22:08:42.025056 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 7
22:08:42.309347 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 7
22:08:42.593435 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 7
22:08:42.805688 IP dhcp248.home.lan > 239.192.76.84: igmp v2 report 239.192.76.84
22:08:42.870485 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 7
22:08:43.148159 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 7
22:08:43.429073 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 7
22:08:43.711635 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 7
22:08:43.993659 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 7
22:08:46.922837 AT 3.17.rtmp > 0.rtmp:  at-rtmp 16
22:08:52.565172 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25
22:08:56.951258 AT 3.17.rtmp > 0.rtmp:  at-rtmp 16
22:09:03.386542 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25
22:09:06.955787 AT 3.17.rtmp > 0.rtmp:  at-rtmp 16
22:09:14.244027 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25

The UDP packets are from TashRouter and presumably are LToUDP traffic since they're on port 1954 (abr-api). The 7 byte ones are the AARP probe burst and the 25-byte ones are the periodic RTMPs. I see the same periodic UDP packets being sent on the vioif0 interface as well. But no AppleTalk from TashRouter. Hmmm.

By the way, 6502 is the perfect net number for an A2SERVER.

thecloud · Dec 18, 2024

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 code to directly open the tap device on NetBSD causes TashRouter to get registered on that device and send AppleTalk replies!

The issue is still not completely solved, since TashRouter is still not handling LToUDP traffic on tap0 correctly, and I don't see my Netatalk server in Mini vMac yet. I think there is probably a different ioctl that I need for BSD, and will look through the source for libtuntap tomorrow.

In-progress diff (there is undoubtedly a better way to structure this):

Code:

diff --git a/tashrouter/port/ethertalk/tap.py b/tashrouter/port/ethertalk/tap.py
index eb0fba6..2eb8f86 100755
--- a/tashrouter/port/ethertalk/tap.py
+++ b/tashrouter/port/ethertalk/tap.py
@@ -13,6 +13,9 @@ from . import EtherTalkPort
 class TapPort(EtherTalkPort):
   '''Port driver for EtherTalk using TUN/TAP.'''
  
+  TUNTAP_LINUX = 0
+  TUNTAP_NETBSD = 1
+
   SELECT_TIMEOUT = 0.25  # seconds
  
   TUNSETIFF = 0x400454CA
@@ -40,8 +43,11 @@ class TapPort(EtherTalkPort):
   __repr__ = short_str
  
   def start(self, router):
-    self._fp = os.open('/dev/net/tun', os.O_RDWR)
-    ioctl(self._fp, self.TUNSETIFF, struct.pack('16sH22x', self._tap_name.encode('ascii') or b'', self.IFF_TAP | self.IFF_NO_PI))
+    if self.TUNTAP_LINUX == 1:
+      self._fp = os.open('/dev/net/tun', os.O_RDWR)
+      ioctl(self._fp, self.TUNSETIFF, struct.pack('16sH22x', self._tap_name.encode('ascii') or b'', self.IFF_TAP | self.IFF_NO_PI))
+    elif self.TUNTAP_NETBSD == 1:
+      self._fp = os.open('/dev/' + self._tap_name, os.O_RDWR)
     super().start(router)
     self._reader_thread = Thread(target=self._reader_run)
     self._reader_thread.start()

thecloud · Dec 18, 2024

thecloud said:
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 code to directly open the tap device on NetBSD causes TashRouter to get registered on that device and send AppleTalk replies!

Clarification: it isn't actually sending replies. It's now broadcasting RTMP packets from a distinct node. Still not seeing replies for name lookups.

Code:

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 is TashRouter
00:48:15.595539 AT 3.147.rtmp > 0.rtmp:  at-rtmp 25
00:48:16.964990 aarp who-has 3.147 tell 3.17
00:48:16.967535 AT 3.17.rtmp > 0.rtmp:  at-rtmp 16  <-- this is atalkd
00:48:16.968163 aarp reply 3.147 is-at f2:0b:a4:58:3a:2a (oui Unknown)
00:48:16.968168 aarp reply 3.147 is-at f2:0b:a4:58:3a:2a (oui Unknown)

TashRouter: An AppleTalk Router

Well-known member

NORTHERN TELECOM

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

PIC Whisperer

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Well-known member

Similar threads