vmnet helper
rb6502 opened this issue · comments
Hi Kelvin,
I'd like to borrow vmnet_helper (and the MAME-side interface glue) for stock MAME. As you probably noticed, pcap on macOS pretty much only works with wired Ethernet connections and so I've been unable to use or work on any network emulation since I switched daily driving to my MacBook Pro. I can go the QEMU route and just require running MAME as root for networking, but having an external helper running as root is a much cleaner idea.
Ok. I'm trying your plain vmnet where I do run MAME as root before getting into any potential weirdness with vmnet_helper and it's sending packets OK as far as I can see but nothing is ever received. (I'm running an emulated Mac with the Fetch FTP client trying to connect to a server on my LAN). Any ideas on that?
Are you using a static IP address? vmnet requires DHCP. Most packets are blocked until DHCP negotiation. I can't recall if I ever tested the plain vmnet so it's also possible there's a bug in there. When vmnet starts up, it creates a bridge100 interface so you can use wireshark or tcpdump to monitor that (inbound packets have checksum errors but that's fine). If that's ok, FTP would probably have to be in passive mode it isn't already.
Yeah, I was using static IP. I changed to DHCP and it requests an address and gets a response but it doesn't acknowledge it, it just keeps requesting an address. Maybe Mac OS does care about the checksum? What's an easy way to test on the A2?
I haven't tested with MacOS networking. I'll try to set that up and look into it. The IP checksums are fixed at some point after wireshark sees them so they're correct by the time they make it into MAME.
For the Apple II, The ip65 disk will work with -sl3 uthernet
Never mind, that was user error :-) I got DATE65.SYSTEM to get the time and date correctly.
For the macintosh, are you using MacTCP, OpenTransport, or something else?
I'm running maciivx -nbe enetnb with 7.6.1 that's been upgraded with Open Transport 1.3.1 (you can get the 1.3 installer and 1.3.1 upgrade from Macintosh Garden).
Related to this, I've added this section: https://wiki.mamedev.org/index.php/Driver:Mac_68K#How_do_I_get_files_into_the_emulation.3F
Would be cool if Ample had a drop box for files to send to the Mac and could run hdiutil for you and set it as the -cdrom, but that's pie-in-the-sky and it's not super hard to do manually.
I was able to track down the Open Transport DHCP issues and it was my fault (and checksum related). Here is the updated file.
Works great! I was able to connect to both the FTP and netatalk servers on my home server and copy files back and forth.
I'll clean this stuff up and submit it sometime after the next release is locked down.
Bonus screenshot: https://rbelmont.mameworld.info/wp-content/uploads/2023/09/0000.png
So Open Transport works great now, but MacTCP uses BootP instead of DHCP. I assume there's no way to tell it otherwise? I understand a lot of modern routers won't bother with it either so it's very much a problem people with physical machines have too.
As far as google would tell me, MacTCP is bootp only. It's not practical, but vmnet might support bootp (I say might because bootp gives it an IP address but I haven't tested an actual connection).
bootp support is disabled by default. There's an /etc/bootpd.plist which vmnet/Mac Internet Sharing create (so it tends to get wiped out). After it's created, the bootp_enabled key needs to be set to true. If /usr/libexec/bootpd is already running, I think a sighup should reload the config.
There's also an /etc/bootptab file which has a list of mac addresses / ip addresses. This would need to be updated with the vmnet mac and the ip address.
man bootpd and man bootptab have more info.
With those files updated, bootp will give the ip address.
Oh, interesting. That's cool that vmnet still supports it. Someone at Apple must understand the use cases for vmnet aren't all VMWare types of stuff.
QEMU filed a radar with Apple in 2021 that you shouldn't need root to use vmnet, but I don't expect anything to happen. https://openradar.appspot.com/radar?id=5007417364447232 I believe they were working on some kind of server app similar to vmnet-helper but I don't know where they're at with it.
I suspect it's more of accident that bootp still works.
I found one more checksum bug - ksherlock/mame@2152bec
Thanks! I'm told 'networksetup -setbootp (interface name)' is the more Apple-approved way to enable it, but I haven't tried any methods yet.
Fair warning: MAME 0.259 will lock up when reading 3.5" disks. There's a hot fix at mamedev/mame@cf510ad
Thanks for the heads up. I've cherry-picked it into a new build.
I think the networksetup is for controlling the settings as a client (in system settings -> network -> ... configure IPv4 ... On my 10.14 Mac, bootp is still an option but on 13.5 it's gone).
This was pointed out to me the other day which is similar but uses a unix domain socket. Maybe it's better, maybe it's not. I haven't tried but I don't understand how it can work without using the mac address vmnet assigns. It could be that bridged mode (added in 10.15) is more lenient about that.
I chased down bootp to /System/Library/LaunchDaemons/bootps.plist where it's disabled and SIP won't allow you to change it even as root. Supposedly you can get launchd to override that by putting your own version in /Library/LaunchDaemons and/or ~/Library/LaunchDaemons but I lack the macOS-foo to get it to work.
Any idea if there's anything in vmnet either on the MAME side or the Apple side that would block AppleTalk traffic? I installed the latest netatalk 2.2.10 on my Linux systems and the nbplkup utility shows that they're advertising a server but MAME doesn't see it even when the host Mac is connected with wired Ethernet (WiFi is known to interfere with AppleTalk).
I can connect to the server directly with the newer AppleShare client where you can enter a DNS name or IP address of a server. So AFP over TCP works fine, but just trying to see available servers in the Chooser doesn't show anything (AARP/NBP/the other components of AppleTalk).
Bad news... It looks like the Ethertalk packets generated over open transport use a logical link control / subnetwork access protocol (LLC/SNAP) ethernet header that vmnet does not like. (The Use 802.3 checkbox in the TCP/IP control panel enables the SNAP/LLC header for TCP as well and vmnet doesn't like that either). If we remove the SNAP/LLC header the packets still don't make it into vmnet so I think it must be filtering out everything except ARP and IP.
That sucks, and arguably most for the IIgs emulation, although System 6 and pre-030 Macs that can't run Open Transport also get hurt. I guess the long-term solution will be to adopt a compatible built-in LocalTalk bridge like Mini vMac and GSPlus/GSPort have. Vas wants to do it differently though: have the 8530 speak the correct bit-serial encoding and then a separate device class similar to the existing bitb for serial does the rest. The Mac guys have done some interesting stuff along those lines recently for real machines ( https://68kmla.org/bb/index.php?threads/releasing-airtalk-wireless-plug-and-play-localtalk-dongle.43838/ for example).
I also might look into if vmnet_common can do bootp/DHCP translation so MacTCP can get online. It seems like it wouldn't be hard, but I need to wrap up the initial integration first.
Here's the current status of the cleanup/integration, not including that I want to do something about the network module selection: rb6502/mame@99bfb0d
I might be biased but it looks good to me. The vmnet_common stuff should probably be in a namespace.
bootp/dhcp translation shouldn't be that hard and would be handy.
Someone on 68KMLA is writing a router that converts between LToUDP (LocalTalk over UDP, which vMac, Basilisk, and GSPort/GSPlus speak) and EtherTalk. They said they're using VMNet in 'bridged' mode instead of 'shared' for their router and it obviously passes EtherTalk packets.
The post about it is here: https://68kmla.org/bb/index.php?threads/developing-a-portable-user-land-appletalk-stack.34622/page-4#post-475509 and I asked them for clarification about the VMNet mode further down the thread.
I tried changing VMNET_SHARED_MODE to VMNET_BRIDGED_MODE and recompiled vmnet_helper and it just hangs when you run it (and makes the parent MAME hang too), so obviously there's something else that needs to change :)
Interesting. VMNET_BRIDGED_MODE didn't exist when I originally wrote the helper. I'll try to play with it this weekend.
For bridged mode, we need to specify the interface that is bridged, eg:
xpc_dictionary_set_uint64(dict, vmnet_operation_mode_key, VMNET_BRIDGED_MODE);
xpc_dictionary_set_string(dict, vmnet_shared_interface_name_key, "en1");
vmnet_start_interface return NULL if there's an error, which it was doing, so that should exit immediately since the status callback will never be executed and it will otherwise hang forever.