I’ve done the update, let me know if it is still broken? Or what is the destination for the Zone Multicast so I can see if there is a pattern that encapsulates it, or worst cast just plain add it in.

Yeah good point! I’ll have to do an update! I only really tested it talking to my NT Macintosh File/Print!

This also helped me discover a bug in Cockatrice III and likely Basilisk II if the code is the same. Turns out that it ignores packets addressed to the AppleTalk “Zone Multicast” address range between 09:00:07:00:00:00 to 09:00:07:00:00:FC. One wouldn’t have a problem with this on a small routerless network, but routers like my Shiva Fastpath do calculate and send out NBP requests using this zone broadcast range.

Looked at the dumps, and I see nothing wrong. Limiting the emulator’s packet capture to just FF:FF:FF:FF:FF:FF and the target’s MAC will certainly break things… like all multicast traffic. This would break AppleTalk as well since EtherTalk uses specific multicast addresses too.

Looks like someone needs to submit a PR to allow all multicast traffic into the emulated NIC. Just check for LSB=1 in the first octet of the destination MAC.

86box sets a capture for the direct mac & all one’s but other protocols broadcast on different addresses, thats why they can scream but not see eachother.

I sent you an email so hopefull you have the capture now?

I don’t get it.

I know that’s not an ideal solution but maybe that way you can at least share drives?

I have found that fake network interfaces like the msloopback avoid a lot of those hairpin issues. I did get the SNA working in this manner.

I’ll have to do the captures tomorrow, as I’m beat for the moment.

Put up the complete dump of one of the NetBIOS packets from each machine. I’m curious as to what the Ethernet frames look like. They should be 802.2 with DSAP/SSAP type 0xf0. If one of the machines is outputting Ethernet_II for some reason (likely the OS/2 one), it could be one reason for the non-communication.

Also, how are your VMs networked? If they are both running on the same host and both are injecting packets pcap style to the same NIC, they won’t be able to “see” each other. The packets only go out to your switch. You need something called “hairpin routing” for it to work (basically the switch reflects the pcap injected packets back to your NIC).

Oh, there is also this KB that may be relevant: https://support.microsoft.com/en-us/topic/a-virtual-machine-that-is-configured-to-use-the-dlc-protocol-does-not-connect-to-an-sna-host-on-hyper-v-server-2012-or-hyper-v-server-2012-r2-eef382a9-65f2-f22f-ecd2-dc88ac6c9f2c

It’s more like people used the IBM types to work over existing networks.

It’s odd as my SNA stuff was with the same setup.

Unless there is something else going on ?