TashRouter: An AppleTalk Router

NJRoadfan

Well-known member
TashRouter is now working over AppleTalk, the AARP lookup/reply shows that. LToUDP traffic shouldn't be going over the tap interface at all. On Linux, TashRouter's LToUDP always seems to correctly select the main NIC and send out packets in my setup.

I do have the problem with Minivmac on Windows though. It always seems to pick the wrong interface on first run and since there is no network configuration option, I force it to the right adapter by temporarily disabling other interfaces before launch.

If TashRouter is broadcasting over the main NIC, a Minivmac client should see AppleTalk zones at a minimum.
 

thecloud

Active member
TashRouter is now working over AppleTalk, the AARP lookup/reply shows that. LToUDP traffic shouldn't be going over the tap interface at all. On Linux, TashRouter's LToUDP always seems to correctly select the main NIC and send out packets in my setup.

I do have the problem with Minivmac on Windows though. It always seems to pick the wrong interface on first run and since there is no network configuration option, I force it to the right adapter by temporarily disabling other interfaces before launch.

If TashRouter is broadcasting over the main NIC, a Minivmac client should see AppleTalk zones at a minimum.
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 AFPServer is registered.
Code:
arm64# tcpdump -X -i tap0
...
09:54:48.835206 AT 3.147.nis > 0.nis:  nbp-lkup 150: "=:AFPServer@EtherTalk Network" [addr=1.32.254]
        0x0000:  0032 02e3 0000 0003 ff93 0202 0221 9600  .2...........!..
        0x0010:  0120 fe00 013d 0941 4650 5365 7276 6572  .....=.AFPServer
        0x0020:  1145 7468 6572 5461 6c6b 204e 6574 776f  .EtherTalk.Netwo
        0x0030:  726b                                     rk
09:54:48.835592 aarp who-has 3.147 tell 3.17
        0x0000:  0001 809b 0604 0001 f20b a458 3a2a 0000  ...........X:*..
        0x0010:  0311 0000 0000 0000 0000 0393            ............
09:54:48.836563 aarp reply 3.147 is-at f2:0b:a4:58:3a:2a (oui Unknown)
        0x0000:  0001 809b 0604 0002 f20b a458 3a2a 0000  ...........X:*..
        0x0010:  0393 f20b a458 3a2a 0000 0311 0000 0000  .....X:*........
        0x0020:  0000 0000 0000                           ......
09:54:48.836565 aarp reply 3.147 is-at f2:0b:a4:58:3a:2a (oui Unknown)
        0x0000:  0001 809b 0604 0002 f20b a458 3a2a 0000  ...........X:*..
        0x0010:  0393 f20b a458 3a2a 0000 0311 0000 0000  .....X:*........
        0x0020:  0000 0000 0000                           ......
09:54:49.629398 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 25
        0x0000:  4500 0035 0000 0000 0111 b103 c0a8 0bf8  E..5............
        0x0010:  efc0 4c54 07a2 07a2 0021 6d3a 0000 55f4  ..LT.....!m:..U.
        0x0020:  fffe 0100 1201 0101 0001 08fe 0000 8200  ................
        0x0030:  0380 0003 82                             .....
09:54:49.631170 AT 3.147.rtmp > 0.rtmp:  at-rtmp 25
        0x0000:  001a ccc2 0000 0003 ff93 0101 0100 0308  ................
        0x0010:  9300 0380 0003 8200 0100 0000 0000 0000  ................
        0x0020:  0000 0000 0000

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

arm64# nbplkup '=:AFPServer@EtherTalk Network'
                    Puppet Head:AFPServer                          3.17:128
 

Attachments

  • MinivMac+TashRouter.png
    MinivMac+TashRouter.png
    22.7 KB · Views: 13
Last edited:

NJRoadfan

Well-known member
Odd, but it may be a regression from fixes on Linux to prevent NBPReplies coming from the loopback. Can you setup atalkd as follows:
vioif0 -router -phase 2 -net 2 -addr 2.222 -zone "EtherTalk Network"
See if Macs on your main network trigger NBPReplys.
 

thecloud

Active member
Odd, but it may be a regression from fixes on Linux to prevent NBPReplies coming from the loopback. Can you setup atalkd as follows:

See if Macs on your main network trigger NBPReplys.
They do indeed:
Code:
vioif0 -router -phase 2 -net 2 -addr 2.234 -zone "EtherTalk Network"
Code:
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 2.234.nis > 2.103.253:  nbp-reply 255: "Puppet Head:AFPServer@*"(0) 128
The real Mac sees the server when atalkd is using vioif0, but it doesn't see any zones. The Mini vMac instances continue to see both zones, but no server.

Update: I changed back to a previous atalkd configuration that includes both vioif0 and tap0, and got a different error ("can't get zone for 1") when starting up atalkd. Still same behavior for clients.
Code:
vioif0 -seed -phase 2 -net 2 -addr 2.22 -zone "EtherTalk Network"
tap0 -seed -phase 2 -net 3 -addr 3.33 -zone "EtherTalk Network"
Code:
Dec 18 12:19:22 arm64 atalkd[16087]: restart (4.0.9dev)
Dec 18 12:19:25 arm64 atalkd[16087]: zip_getnetinfo for vioif0
Dec 18 12:19:25 arm64 atalkd[16087]: zip_getnetinfo for vioif0
Dec 18 12:19:25 arm64 atalkd[16087]: zip_getnetinfo for vioif0
Dec 18 12:19:55 arm64 atalkd[16087]: as_timer configured vioif0 phase 2 from seed
Dec 18 12:19:58 arm64 atalkd[16087]: zip_getnetinfo for tap0
Dec 18 12:19:58 arm64 atalkd[16087]: zip_getnetinfo for tap0
Dec 18 12:19:58 arm64 atalkd[16087]: zip_packet configured tap0 from 3.147
Dec 18 12:20:01 arm64 atalkd[16087]: rtmp_packet gateway 3.147 up
Dec 18 12:20:35 arm64 atalkd[16087]: as_timer can't get zone for 1
Dec 18 12:20:35 arm64 atalkd[16087]: ready -2/0/0

arm64# ifconfig -a
vioif0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ec_capabilities=0x1<VLAN_MTU>
        ec_enabled=0
        address: 52:54:00:f0:0d:01
        status: active
        atalk 2.22 phase 2 range 2 - 2 broadcast 2.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:58:3a:2a
        status: active
        atalk 3.33 phase 2 range 3 - 3 broadcast 3.255
        inet6 fe80::f00b:a4ff:fe58:3a2a%tap0/64 flags 0 scopeid 0x8
 

Attachments

  • Mac sees netatalk server but no zones.png
    Mac sees netatalk server but no zones.png
    22.5 KB · Views: 8
  • Mini vMac sees zones but no server.png
    Mini vMac sees zones but no server.png
    209.7 KB · Views: 8
Last edited:

NJRoadfan

Well-known member
Things seem to be communicating. Don't know what is causing the zone error, unless TashRouter isn't replying to the requests from atalkd for a zone list. On your Ethernet network, run Wireshark with the "atalk" filter. You should see the RTMP packets every 10 seconds, and expanding them should show the network tuples on atalkd's routing table. It should have three tuples. One for the LToUDP network (1), one for the tap (3) network, and one for the Ethernet (2) network.
 

thecloud

Active member
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:
Code:
Zone Information Protocol
    Function: GetNetInfo reply (6)
    101. .... = Flags: 0x5, Zone invalid, Only one zone
        1... .... = Zone invalid: True
        .0.. .... = Use broadcast: False
        ..1. .... = Only one zone: True
    Network start: 2
    Network end: 2
    Zone:
    Multicast length: 6
    Multicast address: 0900070000a6
    Default zone: EtherTalk Network

That might explain why the real Mac doesn't display any zones in the Chooser. Once AppleShare is selected, Wireshark sees a bunch of NBP lookups for object: '=', type: 'AFPServer', zone: 'EtherTalk Network', but never any replies. (UPDATE: the real Mac doesn't see the server anymore, after switching atalkd.conf to include two interfaces.)

There are apparently no RTMP packets being sent on the Ethernet network. I don't see any with Wireshark, or with tcpdump.

Using `tcpdump -i vioif0` in the VM, I see no RTMP packets there either, only the periodic UDP packets on port 1954 for LToUDP.

Using `tcpdump -i tap0` in the VM, I *do* see periodic RTMP traffic from two nodes, 3.33 and 3.213. The former is atalkd and the latter is TashRouter. Their RTMP broadcasts only have two tuples each:
Code:
Routing Table Maintenance Protocol
    Net: 3
    Node Length: 8
    Node: 213
    Tuple 1:  Range Start: 3  Dist: 0  Range End: 3  Version: 0x82
        Range Start: 3
        Distance: 0
        Range End: 3
        Version: 0x82
    Tuple 2:  Net: 1  Dist: 0
        Net: 1
        Distance: 0

Routing Table Maintenance Protocol
    Net: 3
    Node Length: 8
    Node: 33
    Tuple 1:  Range Start: 3  Dist: 0  Range End: 3  Version: 0x82
        Range Start: 3
        Distance: 0
        Range End: 3
        Version: 0x82
    Tuple 2:  Range Start: 2  Dist: 0  Range End: 2
        Range Start: 2
        Distance: 0
        Range End: 2

Reviewing the messages from TashRouter startup:
Code:
2024-12-18 12:59:17,032 INFO: starting LtoudpPort...
2024-12-18 12:59:17,033 INFO: LToUDP assigned network number 1
2024-12-18 12:59:17,034 DEBUG: router adding: RoutingTableEntry(extended_network=False, network_min=1, network_max=1, distance=0, port=LToUDP, next_network=0, next_node=0)
2024-12-18 12:59:17,034 DEBUG: router adding network range 1-1 to zone LToUDP Network (now default zone for this range)
2024-12-18 12:59:17,034 INFO: starting TapPort...
2024-12-18 12:59:17,035 INFO: tap0 assigned network number range 3-3
2024-12-18 12:59:17,035 DEBUG: router adding: RoutingTableEntry(extended_network=True, network_min=3, network_max=3, distance=0, port=tap0, next_network=0, next_node=0)
2024-12-18 12:59:17,035 DEBUG: router adding network range 3-3 to zone EtherTalk Network (now default zone for this range)
2024-12-18 12:59:17,036 INFO: all ports started!
2024-12-18 12:59:17,036 INFO: starting EchoService...
2024-12-18 12:59:17,036 INFO: starting NameInformationService...
2024-12-18 12:59:17,036 INFO: starting RoutingTableAgingService...
2024-12-18 12:59:17,037 INFO: starting RtmpRespondingService...
2024-12-18 12:59:17,037 INFO: starting RtmpSendingService...
2024-12-18 12:59:17,037 INFO: starting ZipRespondingService...
2024-12-18 12:59:17,037 INFO: starting ZipSendingService...
2024-12-18 12:59:17,038 INFO: all services started!
2024-12-18 12:59:19,534 INFO: tap0 claiming address 3.213
2024-12-18 12:59:19,568 INFO: LToUDP claiming node address 254
2024-12-18 12:59:25,928 DEBUG: router adding: RoutingTableEntry(extended_network=True, network_min=2, network_max=2, distance=1, port=tap0, next_network=3, next_node=33)

So the question seems to be: why isn't there any RTMP traffic on the vioif0 interface (i.e. from 2.22)? Should there be any, or does it all happen from the last-registered interface?
 
Last edited:

NJRoadfan

Well-known member
There should be RTMP traffic on vioif0, at a minimum it should be broadcasting two tuples for networks 2 and 3 that atalkd is setup for. TashRouter appears to be working correctly, its routing table has all three networks.

One last test, shut down TashRouter and restart atalkd. See if you are getting any RTMP traffic on vioif0.

Another thing, make sure that your copy of atalkd is actually the updated one from Netatalk 4.0 and not an old 2.2x version. The old versions had a bug that caused exactly this problem with RTMP packets. This may also be a NetBSD specific problem as well. Paging: @hauke
 
Last edited:

thecloud

Active member
One last test, shut down TashRouter and restart atalkd. See if you are getting any RTMP traffic on vioif0.
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!

Another thing, make sure that your copy of atalkd is actually the updated one from Netatalk 4.0 and not an old 2.2x version. The old versions had a bug that caused exactly this problem with RTMP packets. This may also be a NetBSD specific problem as well. Paging: @hauke
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 it with the -V flag shows 4.0.9dev.

I'll do some checking on whether ZIP, NBP, and RTMP look correct now on the Ethernet network before re-introducing TashRouter to the mix.
 
Last edited:

thecloud

Active member
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:
Code:
Zone Information Protocol
    Function: GetNetInfo request (5)
    Pad (0): 00
    Pad (0): 00000000
    Zone: *

Zone Information Protocol
    Function: GetNetInfo reply (6)
    101. .... = Flags: 0x5, Zone invalid, Only one zone
        1... .... = Zone invalid: True
        .0.. .... = Use broadcast: False
        ..1. .... = Only one zone: True
    Network start: 2
    Network end: 2
    Zone: *
    Multicast length: 6
    Multicast address: 0900070000a6
    Default zone: EtherTalk Network
Code:
Routing Table Maintenance Protocol
    Net: 2
    Node Length: 8
    Node: 22
    Tuple 1:  Range Start: 2  Dist: 0  Range End: 2  Version: 0x82
        Range Start: 2
        Distance: 0
        Range End: 2
        Version: 0x82
    Tuple 2:  Range Start: 3  Dist: 0  Range End: 3
        Range Start: 3
        Distance: 0
        Range End: 3
Code:
Name Binding Protocol
    Info: 0x21  Operation: lookup  Count: 1
    Transaction ID: 2
    Node 1
        Network: 2
        Node: 22
        Port: 129
        Enumerator: 0
        Object: Puppet Head
        Type: AFPServer
        Zone: EtherTalk Network
What's more, I can now see the Powerbook G3 from the VM:
Code:
arm64# nbplkup
                    Puppet Head:AFPServer                          2.22:128
                          arm64:netatalk                           2.22:4
                          arm64:Workstation                        2.22:4
                    Wall Street:  Macintosh PowerBook              2.187:250
                    Wall Street:Workstation                        2.187:4
So that is all good news for AppleTalk net 2, which is on Ethernet. But it would be great to have Mini vMac be able to see this network. Next step is to reintroduce TashRouter and not have it specify zones or net configuration for the tap interface this time.
 

thecloud

Active member
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.
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'),
))
This time there is RTMP from both 3.33 (atalkd) and 3.55 (TashRouter) on the tap0 interface. There are ZIP queries as well, though no replies. And there are no UDP port 1954 packets on tap0 this time. Those are all on vioif0 now, which I think was what we expected as correct behavior.

But. Those UDP port 1954 packets on vioif0 (LToUDP) are not getting routed into AppleTalk NBP lookups on either tap0 or vioif0. There is nothing happening on tap0 except the periodic RTMP maintenance updates.

Looking at the UDP packets that appear on vioif0 when the Chooser is opened in a Mini vMac instance, there are always pairs: the first is sent from the Mini vMac host (in this case, 192.168.11.105), and the second is sent from the NetBSD VM (192.168.11.248). The contents both appear to be NBP lookups for AFPServer, but no corresponding AppleTalk nbp-lkups or replies are showing up on any interface.
Code:
8    4.816357    192.168.11.105    239.192.76.84    UDP    75    1954 → 1954 Len=33

0000   54 26 17 7c fe 20 01 00 1a 02 fe 02 11 03 00 01   T&.|. ..........
0010   20 fe 00 01 3d 09 41 46 50 53 65 72 76 65 72 01    ...=.AFPServer.
0020   2a                                                *

9    4.818241    192.168.11.248    239.192.76.84    UDP    75    1954 → 1954 Len=33

0000   00 00 5f 4b ff fe 01 00 1a 02 02 02 21 03 00 01   .._K........!...
0010   20 fe 00 01 3d 09 41 46 50 53 65 72 76 65 72 01    ...=.AFPServer.
0020   2a                                                *
 

thecloud

Active member
After restoring the TashRouter config to provide explicit network and zone information for the tap0 port, I am seeing AppleTalk nbp-lkup queries appear again on tap0 when the Chooser is opened in Mini vMac, and I also see both zones in the Chooser. If I omit the seed_* parameters, then incoming LToUDP queries aren't routed to tap0. Still no idea why there is no reply to this nbp-lkup.
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']),
))
Code:
22:01:08.665469 aarp who-has 3.82 tell 3.33
22:01:08.666213 aarp reply 3.82 is-at f2:0b:a4:58:3a:2a (oui Unknown)
22:01:08.666214 aarp reply 3.82 is-at f2:0b:a4:58:3a:2a (oui Unknown)
22:01:09.595764 AT 3.82.nis > 0.nis:  nbp-lkup 20: "=:AFPServer@EtherTalk Network" [addr=1.32.254]
22:01:09.595771 AT 3.82.nis > 0.nis:  nbp-lkup 20: "=:AFPServer@EtherTalk Network" [addr=1.32.254]

The LToUDP behavior is a bit different here too. Instead of both the Mini vMac host and the NetBSD VM each generating a UDP packet looking for '=:AFPServer@*' as in my previous post, the Mini vMac host is now the only one originating these packets. The lookups are now specifically for '=:AFPServer@EtherTalk Network' instead of the wildcard zone. But unfortunately there are no replies.

Code:
9    8.100089    192.168.11.105    239.192.76.84    UDP    91    1954 → 1954 Len=49

0000   54 26 17 7c fe 20 01 00 2a 02 fe 02 11 2f 00 01   T&.|. ..*..../..
0010   20 fe 00 01 3d 09 41 46 50 53 65 72 76 65 72 11    ...=.AFPServer.
0020   45 74 68 65 72 54 61 6c 6b 20 4e 65 74 77 6f 72   EtherTalk Networ
0030   6b                                                k
Time to step away from this for a bit.
 

thecloud

Active member
One last update for tonight. I got multiple zones to appear on the Powerbook G3 by doing this:
Code:
atalkd.conf:
vioif0 -seed -phase 2 -net 2 -addr 2.22 -zone "EtherTalk Network"
tap0 -seed -phase 2 -net 3 -addr 3.33 -zone "Danger Zone"

route.py:
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'Danger Zone', b'EtherTalk Network']),
))

The server gets registered in net 2, which is the "EtherTalk Network" zone. Still no connectivity with LToUDP Network, but at least something new.
 

Attachments

  • Mac sees multiple zones.png
    Mac sees multiple zones.png
    17.1 KB · Views: 10
Last edited:

NJRoadfan

Well-known member
This is an invalid configuration. Both atalkd and TashRouter both need the same zone list configured on tap0. The atalkd line should be as follows in this case:
Code:
tap0 -seed -phase 2 -net 3 -addr 3.33 -zone "Danger Zone" -zone "EtherTalk Network"

Anyway, one more thing to try. TashRouter had a recent commit dealing with crashing with packets coming from node 0.0, try reverting the commit, or grab this revision and test: https://github.com/lampmerchant/tashrouter/tree/95dacac684e5cf45890f7daaa8444557ee3125f0
 

thecloud

Active member
This is an invalid configuration. Both atalkd and TashRouter both need the same zone list configured on tap0. The atalkd line should be as follows in this case:
Code:
tap0 -seed -phase 2 -net 3 -addr 3.33 -zone "Danger Zone" -zone "EtherTalk Network"
Ugh. Thanks for catching that. I updated both atalkd and TashRouter configs so the same two zones are listed in the same order. It seems to pick the first one listed as the default zone.
Anyway, one more thing to try. TashRouter had a recent commit dealing with crashing with packets coming from node 0.0, try reverting the commit, or grab this revision and test: https://github.com/lampmerchant/tashrouter/tree/95dacac684e5cf45890f7daaa8444557ee3125f0
I commented out the specific line that rejects datagrams based on source node:
Code:
       # invalid values for source node, ports will refuse to send it on; discard the Datagram
-      if datagram.source_node in (0x00, 0xFF): return
+      #if datagram.source_node in (0x00, 0xFF): return
       # we're not originating this datagram, so bump its hop count
Doesn't seem to make any difference. What I am noticing, though, is that if I run TashRouter first and then start up atalkd, I never see any AppleTalk RTMP packets on vioif0. There are only UDP packets sent on vioif0, which look like RTMP broadcasts from LToUDP. If I start up atalkd first, I see AppleTalk RTMP on both interfaces (from 2.22 on vioif0, and from 3.33 on tap0, plus another 3.xx node on tap0 once TashRouter starts), *and* I also see the UDP RTMP packets on vioif0, *and* I see incoming lookups from Mini vMac (LToUDP) showing up as AppleTalk nbp-lkup broadcasts on the tap0 interface. The problem is that those lookups go unanswered, which is the current issue I'm trying to understand.
Code:
(vioif0)
11:06:07.498273 AT 2.22.rtmp > 0.rtmp:  at-rtmp 16
11:06:12.219661 IP dhcp248.home.lan.abr-api > 239.192.76.84.abr-api: UDP, length 31
...
(tap0)
11:07:38.919459 AT 3.57.rtmp > 0.rtmp:  at-rtmp 25
11:07:38.919460 AT 3.57.rtmp > 0.rtmp:  at-rtmp 25
11:07:47.502204 aarp who-has 3.57 tell 3.33
11:07:47.503846 AT 3.33.rtmp > 0.rtmp:  at-rtmp 16
11:07:47.504262 aarp reply 3.57 is-at f2:0b:a4:58:3a:2a (oui Unknown)
11:07:47.504267 aarp reply 3.57 is-at f2:0b:a4:58:3a:2a (oui Unknown)
11:07:49.481776 AT 3.57.nis > 0.nis:  nbp-lkup 79: "=:AFPServer@EtherTalk Network" [addr=1.32.254]
11:07:49.481782 AT 3.57.nis > 0.nis:  nbp-lkup 79: "=:AFPServer@EtherTalk Network" [addr=1.32.254]
11:07:49.759277 AT 3.57.zip > 3.33.zip:  at-#6 25
11:07:49.759288 AT 3.57.zip > 3.33.zip:  at-#6 25
 

NJRoadfan

Well-known member
I think I know what might be going on. Change the MAC address used by TashRouter for the tap interface, it should not match the one NetBSD assigned the interface on creation. For A2SERVER, I just use a completely bogus address (AA:BB:CC: DD:11:22) since its a virtual interface anyway.

ie:
Code:
 TapPort(tap_name='tap0', hw_addr=b'\xAA\xBB\xCC\xDD\x11\x22', seed_network_min=3, seed_network_max=3, seed_zone_names=[b'Danger Zone', b'EtherTalk Network']),

Its likely when atalkd does an AARP lookup, it completely freaks out. It also may be filtering packets from TashRouter thinking it originated the packets since the MAC matches.
 

thecloud

Active member
I think I know what might be going on. Change the MAC address used by TashRouter for the tap interface, it should not match the one NetBSD assigned the interface on creation. For A2SERVER, I just use a completely bogus address (AA:BB:CC: DD:11:22) since its a virtual interface anyway.
YES!!!
That was it! Didn't realize it *wasn't* supposed to match the actual interface address. Thank you for all the help!

Now tap0 is showing all the expected communication between various nodes in net 1, net 2, and net 3. Mini vMac sees the Netatalk server, and the Powerbook G3 sees both Netatalk and Mini vMac shares. This is so cool!

Code:
(atalkd.conf)
vioif0 -seed -phase 2 -net 2 -addr 2.22 -zone "EtherTalk Network"
tap0 -seed -phase 2 -net 3 -addr 3.33 -zone "EtherTalk Network" -zone "Danger Zone"

(TashRouter)
router = Router('router', ports=(
  LtoudpPort(seed_network=1, seed_zone_name=b'EtherTalk Network'),
  TapPort(tap_name='tap0', hw_addr=b'\xDE\xAD\xBE\xEF\xCA\xFE', seed_network_min=3, seed_network_max=3, seed_zone_names=[b'EtherTalk Network', b'Danger Zone']),
))

I guess the next step is for me to add a PR to TashRouter for the BSD support. It would probably be easiest to do a runtime check to see whether /dev/net/tun is present, and take the BSD code path for opening the tap port if not.
 

Attachments

  •  Mini vMac Sees Netatalk!.png
    Mini vMac Sees Netatalk!.png
    22.9 KB · Views: 7
  • Mac sees both Mini vMac and Netatalk.png
    Mac sees both Mini vMac and Netatalk.png
    18 KB · Views: 6
  • Mini vMac sees entire network.png
    Mini vMac sees entire network.png
    101.4 KB · Views: 6

NJRoadfan

Well-known member
The PowerBook still isn't seeing all zones, but a complete shutdown of both TashRouter and atalkd and then restart should clear that up. Its completely normal for routers to develop stale zone tables when you are starting up and shutting down routers one at a time.
 

slipperygrey

Well-known member
This was an epic thread to follow. Great job both of you! I'm excited about NetBSD compatibility for TashRouter. It's worthwhile breaking out of the Linux monoculture every once in a while. :)
 
Top