NE2000 in macOS Big Sur - pcap_open_live to_ms value

[mikeypdev]

I was able to get the NE2000 network adapter working in Win98 hosted on macOS Big Sur (M1) by making the one-line change in the ne2000 source as mentioned here:

Just forgot to mention... for NE2000, you have to change a line to make it work with macOS (Mojave only? IDK): https://www.vogons.org/viewtopic.php?p=734565#p734565 Originally posted by @brunocastello in #859 (comment)

The mentioned one-line patch changes the to_ms parameter of pcap_open_live from -1 to 2250. Looking at the man page for pcap_open_live on macOS as well as linux, it appears that this parameter should not be a negative value. https://www.tcpdump.org/manpages/pcap_open_live.3pcap.html

I'm not sure of the significance of choosing 2250ms over any other timeout value, but based on the man page, should a non-negative value be the default instead of -1?

[Wengier]

We are currently improving the NE2000 feature and adding slirp support. Let's see if the new NE2000 feature will work with macOS too (it probably will).

[Jookia]

Looks like this is a very old bug indicating this has been broken on macOS for a long time: https://stackoverflow.com/questions/46569127/what-does-to-ms-1-do-on-winpcap-and-linux-libpcap explains how it's probably due to bad WinPcap documentation. It seems WinPcap tolerates this, libpcap tolerates this but macOS' pcap implementation doesn't. I think a timeout of 3000 (3 seconds) should be fine.

I suggest updating this immediately rather than waiting for my PR. :)

[Jookia]

I made a PR. @mikeypdev I don't have a Mac to test this, if you could compile it and test I would be thankful.

[mikeypdev]

Thanks @Jookia, the PR builds and runs successfully on an M1 mac. (I'm not able to test on an intel mac.)

[brunocastello]

I would test with my Intel Mac, but for now I am waiting for a version with the dynamic core working with Windows 98 (Hey, I can dream).

However, I’ve set up a dosbox-x (previous version) for my dad on his Intel Mac, so he could play SimCity 2000 in all its glory and nostalgia. Was a nice xmas gift for him.

[Wengier]

@brunocastello The dynamic core (dynamic_x86) does work here with Windows 98 and it seems to work reliably. So far I have not yet found the exact reason why it may not work properly for others.

Screenshot:

[joncampbell123]

@Wengier Problems with dynamic core and Windows 95/98/ME often have to do with page fault handling and preemptive multitasking.

It's possible everything seems to work fine because Windows has yet to make any moderate to serious use of the swap file.

The way I test reliability is by starting DOSBox-X with as little RAM as necessary for Windows 98 to run. This forces Windows 98 to page fault and use the swap file a lot, and that can help reveal any page fault handling problems with the CPU core of your choice.

The problem DOSBox SVN, and DOSBox-X dynamic core have, is that the page fault handling is written to assume the page fault exception handler will do it's thing and then return right back to the location the fault occurred. The problem is that in Windows 95 onwards, the preemptive multitasking can switch tasks while userspace is processing a page fault, thus the assumptions fall apart and emulation gets itself crossed up with inconsistent CPU state and eventually Windows 9x/ME crashes.

DOSBox-X solved this issue with normal core by making a guest page fault a C++ exception that the CPU core throws and the normal execution loop catches, and by modifying all normal core instruction handling so that the instruction either completes, or leaves CPU state as it was at the start if interrupted by a page fault (solving the corrupted CPU state issues).

Unfortunately C++ exceptions do not work with dynamic core because most platforms, including Linux, have static data structures that the C++ runtime uses to determine how to handle an exception. None of those structures define how to deal with the code generated by dynamic core, so 99% of the time the C++ runtime aborts DOSBox-X as if nobody had any catch { } statements (even if functions higher up did!). It happens to work with 32-bit Windows because of how Win32 defined C++ exceptions through the Thread Information Block via the FS: segment register, but that's the only known exception.

[brunocastello]

Interesting read! But that page fault issue with dynamic core was exactly the reason why months ago I went after QEMU and UTM, but QEMU itself needs patches to support 3dfx/Glide (unlikely, given how the dev of the patch isn’t too keen in working out for an easier way to the general public to use it), while DosBox-X does run it and also emulates a voodoo 1 if I am not mistaken.

It all started when I was looking for a Dosbox solution with Networking and found Dosbox-x, three or four years ago, even the one-line solution mentioned here for NE2000 was given to me by someone (Jokia, was it you?) on VOGONS forums back in 2019.

I still haven’t found a libGlide library for macOS (no U2 pun intended here), and it’s unlikely that I will find one by the time I get an Apple Silicon Mac. But probably even with normal core, the M1 could be quite fast enough for DosBox-X running FIFA 99/Counter-Strike 1.5 on Windows 98 and Voodoo emulation or Glide, for example.

Then there is PCem, Sarah has been doing amazing things with it, but PCem performance on my 2013 Intel Mac isn’t strong enough, even though I can run Win98 with an emulated Voodoo 2. PCem can also probably benefit from M1, if one can compile a binary for macOS on M1 (and without errors). My attempts with an Intel Mac binary had issues when shutting down the machine and with performance.

Enough with the Full circle around emulators here, I still think DosBox-X has more potential because of its simplicity to use and extra features. Heck, even my 60 yr old dad is using it without much hassle to play his favorite game from 30 yrs ago. Thanks Jonathan, for that! I have always been following the repo and the news here, while keeping an eye here for when I get the M1, so I can try again.

For now I am sticking with UTM and DOSPad (iDOS2) on my iPad Pro, because I needed mobility and play my retro games while I travel (or when the pandemic ends, hopefully God will help us all).

[Jookia]

Sounds like this is fixed?

[mikeypdev]

Looks like the PR was merged, so I'll close this issue now (assuming that's the correct process). Thank you for the fix!

[Wengier]

Yes, it has been merged. Thanks for the fix!

EDIT: One comment above was a duplicate to another so I removed one of them.

[Wengier]

@Jookia I noticed that a read timeout value of 3000 for pcap does not work very well for Windows, so I am adding a pcaptimeout config option in my PR which by default will default to -1 on Windows and 3000 otherwise. Hopefully this will makes it more flexible for different platforms.

[Jookia]

Please do NOT set it to -1. This is invalid. Set it to something shorter. This will work on macOS too.

…

On Sun, Jan 10, 2021 at 11:08:34PM -0800, Wengier wrote: @Jookia I noticed that a read timeout value of 3000 for pcap does not work very well for Windows, so I am adding a pcaptimeout config option in my PR which by default will default to -1 on Windows and 3000 otherwise. Hopefully this will makes it more flexible for different platforms. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #2150 (comment)

[Wengier]

@Jookia A value of 3000 may freeze the Windows system when it starts, but -1 will work on Windows. According to the following discussion a timeout value of -1 means “non-blocking mode”, but it probably not work on all platforms such as macOS, which is why the default value has been changed to 3000 for macOS.

https://stackoverflow.com/questions/4275740/zero-read-timeout-for-pcap

[brunocastello]

Please do NOT set it to -1. This is invalid. Set it to something shorter. This will work on macOS too.
…

For macOS what consistently has worked for me since that post on VOGONS forums mentioned above was 2250. Since then I have been compiling my own macOS build with that value until now. This PR will save me some valuable time.

[Wengier]

I would however propose to change to a different default value when possible. Perhaps 2250 for macOS, and perhaps another (smaller) value for Windows, after confirming they indeed work on these systems.

[mikeypdev]

On my Mac mini M1, both 2250ms and 3000ms worked fine.

It does indeed look like the behavior varies across platforms and implementations. Note the "at least on some platforms" comment in the official docs: https://www.tcpdump.org/pcap.html

to_ms is the read time out in milliseconds (a value of 0 means no time out; on at least some platforms, this means that you may wait until a sufficient number of packets arrive before seeing any packets, so you should use a non-zero timeout).

(Also, should I reopen this issue?)

[Jookia]

Okay. Weird, but okay. I'm sorry for not testing this on Windows- I had assumed by timeout it meant timeout, not 'time to just do nothing'.