The latest UniPCemu commit has some new overrides for the support of the COM0COM signed driver.
So far managed to use the emulated modem (within UniPCemu used from a serial port on Windows 10) to connect to the server within the same application.
I see it negotiating LCP at least, but somewhere after that it fails? Using the terminal window inside Windows 10 to make it wait for the opening message before it starts sending PPP automatically fixes the PPP starting properly at least (due to Windows 10 not receiving all data once it starts doing that, thus the server can't start PPP properly because it can't start waiting for input because it's still in the output-only startup phase (asking for the username)).

The emulated serial modem seems to run at least (at least the sending to the packet server).
Edit: It seems to properly authenticate on the PPP server. But it doesn't seem to negotiate any networking protocols (Error 720)?
Edit: It seemed some weird behaviour of a (corrupted) MiniPort driver. Fixed by removing all from device manager and detecting them again.
I now see it properly authenticate and connect to the server, reaching the final state of being connected with a proper IP address on the private network (did setup the server to perform a local network for simplicity atm, but internet access and other host access (w/o broadcast addressing) is possible as well if configured for the actual network adapter of the host that connects to the real network).

Although atm for said functionality you'll have to compile the latest commit yourself (as it isn't released yet, the last release was just a few days ago after all). The only thing that changed so far is the improved PSP-style face button inputs and direct serial bugfix (it was always detecting the control port as having a value instead of detecting if it is actually set to a valid value(non-empty)) as well as this improvement (allowing detecting COM0COM without having to build the driver yourself and run windows in unsafe(unsigned) driver mode. So you can use it with Visual Studio community and build it (and SDL2+SDL2_net) yourself. Or do the same with the MinGW+MSYS2 toolchain until it's released sometime in the future.
Edit: Downgrading the COM0COM serial driver to 2.2 last version signed seems to fix installation on newer Win10 hardware (because of TPM?). The issue with the 720 error re-emerges? Perhaps I'm forgetting something else?

Edit: A FTP server works without issues. If properly configured on the machine, I can pull/put files and directories on the emulated machine from Windows 10 and change basically all files through FTP.
So a basic FTP server should work properly at least.

This is active in another forum, but I'll mention that I wrote a tool back in the 80's which I do find to be the simplest/best (for me) way to move files
on/off and between older DOS systems (real hardware and emulations):

DDLINK (available free from my site) is a tiny (16k) .COM which can move files between DOS systems over COM (serial), LPT (parallel), or LAN
(ethernet) ports.

It does not have to be "installed", does not need a NOS (or any other special software) to use LAN (it does require a Crynwr "packet driver" which are available for MANY NICs,
and are simple TSR .EXEs which can be loaded/unloaded "on the fly". It can even "bootstrap" itself to a new system over serial, requiring only the built in DOS CTTY command.

Although mainly designed as an interactive tool, after reading this thread, I've just added a new command line option to help facilitate non-interactive transfers
(ie: from BATCH files).

And though it is a DOS program, it does work well within DOSBOX, which makes it well suited to moving files to/from many more modern system types.

If you don't want the bulk of newer DOSBOX, there is an older/much-smaller one which works well - also on my site.

Dave Dunfield ::: https://dunfield.themindfactory.com
or: "Daves Old Computers" -> Personal (near bottom)

I appreciate the topic subject is about injecting into a running 86Box machine but for those who end up here (as I did) and don't really mind having to do a virtual machine reboot the simplest option is to mount the hard drive.

• On a Mac double-click the hard drive image in the Users/MacBox/disks folder within Finder to mount the drive.
• Copy around what you need to on that drive (being sure to use DOS 8.3 filenames etc as required).
• Once you've copied stuff around, eject the drive from the Mac finder and return to 86Box.
• You'll be able to see the changed stuff straight away in your DOS command line but accessing it will probably give a severe-looking disk error.
• Restart your virtual machine and all will be good.

I use this method for getting game files onto the hard disk without needing to worry about floppy/cd image files.

There's also EtherDFS (EtherDFS - a network drive for DOS ).
Managed to get this working connected to UniPCemu (git latest) as a dial-up packet server, with the local linux (Ubuntu) network hosting a drive for it to access. I used my PPP EtherDFS driver to connect to the local network using an EDFSCP driver I adjusted from lsppp (PPP EtherDFS driver). Optionally, you can use SLEEP (Ethernet II inside SLIP, previously callee EtherSLIP protocol in current releases) as well for this setup for the same effect (tho I don't know any drivers that support it). I was able to perform directory listing using it, even connect two clients directly over dial-up (Hayes modem) to list both sides' shared drives (an addition I added to the packet driver). Although MS-DOS cannot host and client at the same time (a current limitation on then EtherDFS server itself). If the issues with it (EtherDFS for MS-DOS) are fixed, it could be a viable alternative.

There is also the ETHFLOP tool, which emulates a floppy drive, with floppy images served up through "raw" ethernet. (So I guess it wouldn't need a TCP/IP stack to be loaded for it to work?)

You gotta have networking enabled in your PCEM/86Box machine. It's the easiest way to transfer/inject files into a running guest. On the host I setup HFS then drag the files I want to transfer to HFS's main window.

I then download on the guest using the web browser (Windows 98 SE). This is probably the fastest way to inject files into a running guest.

I recommend 86Box over PCEM because of support for 100Mb versus PCEM's 10Mb. Transfer speeds were dismal in PCEM using the same setup making this useful only for transferring small files.

DOS 6.22/Mtcp FTP in PCEM.

.

Otherwise you have to shut down the guest and use a tool such as WinImage to inject the files.