UPDATE* ME from the future, I was ind of right in that something was missing, nothing was eating the trafic, rather 86box only had the all MAC broadcast address set as a filter, and older protocols like NetBEUI instead use magical protocol-based multicast/broadcast addresses. Hopefully in an upcoming release of 86box it’ll be updated!
I don’t know what is going on, other than it feels like something is filtering me on either Windows 10 or 11. I have a Windows 2000 server with NetBEUI running under Hyper-V, and trying to map to it from OS/2 using the Lan Manager 2.2 disks floating around (you have to merge them as some stuff is missing like #2 driver disks), lets you map directly but finding each-other seems to be difficult. Even trying to rebuild on the same machine using either a MS Loopback interface, or a VMware interface also has endless weirdness, or in the capture above they can be seen on Wireshark speaking but not hearing each-other. I thought it was LAN drivers, or the old friends, IO/IRQ/DMA channel issues, but after trying various configs, I tried TCP/IP and..
They find each-other right away. Instantly, it just works. Have we hit the point where there is silent filters screwing up non TCP/IP protocols using pcap injection on Windows? Am I going insane?
Speaking of OS/2 weirdness, I was doing some SQL installs, and I came across disk images for 4.1A, and in there is the graphical tools for Windows & OS/2! Although I didn’t think Microsoft ever did port the graphical tools to OS/2, and I’d be right. However on setup disk 2 is WLO/Porthole! Turns out this was used in a shipping product! Unlike the one for Excel 3.0, or the applettes, this installs into the C:\OS2\DLL directory! So, this is the real deal!
I could logon to my Windows 2000 server from OS/2, but the opposite would never work. On the capture I just see it endlessly trying to find by name, but OS/2 is silent.
I must be missing something obvious somewhere.
I’m hoping to be building this towards something, so I’ll update later.
For better or for worse, Microsoft has a consistent and steady history of dogfooding their more abstract ideas right within their main product lines!
I’m just guessing here since it’s been a REALLY long time since I fooled around with NETBEUI/NETBIOS and Windows, but I suspect your Windows 2000 server needs to connect to a WINS server to resolve the NETBEUI name of the OS/2 system. I’m probably wrong though.
For using the TCPIP transport, yes but NetBEUI is flat.. I can see them announce but they just don’t talk.
I wasted an hour installing NT to see if it could join a NT Lan manager domain. It cannot.
Do they use different Ethernet frames? tcp/ip uses Ethernet II but there’s 802.3, 802.2… (remember all the old Netware binding stuff).
That’s more so for IPX, NetBEUI uses snap 4, DLC traffic. I can ‘map drives’ but they just cannot ‘see’ eachother for some reason. I’m going to have to setup some real machines I suppose.
It’s kind of funny that normally this kind of thing ‘just works’…
When I changed it to TCP/IP it immediately worked, I just haven’t tried old stuff like this in ages.
Hyper-V have a filtering engine on the virtual switch.
Try to add some allow rules for netbui: https://learn.microsoft.com/en-us/windows-server/virtualization/hyper-v-virtual-switch/create-security-policies-with-extended-port-access-control-lists#bkmk_tcp
Ill have to check it tomorrow but back in the day if you had enough people running NetBEUI it’d do announcement storms like crazy! And the worst part about type 0x4 is that it’s the same snap to talk to the mainframes! And god forbid a few hundred machines start an election and it spills over to the front end processor running at 4Mbit!
I’ve had decent luck using VirtualBox with bridged networking with non-IP traffic, namely AppleTalk (which is 802.3 SNAP packets). The bridge needs to be to wired Ethernet, no WiFi here! I just tested Windows 98SE with NetBEUI installed and I’m seeing packets…… including the browsing for MAILSLOTs!
NetBIOS Frames look like they are 802.2 (DSAP/SSAP 0xf0) under Windows 9x. Looks like 3com had a funky version that used Ethernet II framing and a couple of Ethertypes. Did IBM ever use Ethernet II framing for NBF?
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 ?
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
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.
I sent you an email so hopefull you have the capture now?
I don’t get it.
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.
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.
Since you’ve already enabled TCP/IP on both systems, have you tried enabling NetBeui over TCP/IP on the Windows system? Then you “should” be able to connect to the OS/2 system using something like the following from the command prompt: net use X: \\ip_address_of_OS2-box\share_name
I know that’s not an ideal solution but maybe that way you can at least share drives?
A PR was merged to fix this problem, so the next release should be fixed.
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.
Yeah good point! I’ll have to do an update! I only really tested it talking to my NT Macintosh File/Print!
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.