IP networking under FreeDOS

[chschnell]

I have a FreeDOS image with V86 network support using mTCP. mTCP is under active development and comes shipped with FreeDOS.

Both UDP and TCP are working, so far I've tested DHCP and DNS packets as well as raw TCP streams. For TCP I've used a simple nc (netcat) which is part of mTCP. I'm using DHCP for auto-IP setup when FreeDOS boots, it works out of the box.

Is anyone interested in this or is this nothing new and networking under FreeDOS has already been done before?

My local V86 network relay is WispServerCpp.

Currently I'm using a RTL8029AS network driver I found on the internet, not sure if that is neccessary (I'll try to switch to one of the drivers that comes with FreeDOS). Is there a recommended DOS packet driver for V86? EDIT: The generic NE2000 driver that is distributed with FreeDOS works, too (given the right arguments: C:\NET\FDNET\NE2000.COM 0x60 0xA 0x300).

Getting this to work involves a patch to src/browser/fake_network.js (add UDP checksum in write_udp()).

Here's the response for a HTTP GET-Request to http://www.osdever.net/FreeVGA/home.htm using nc:

freedos-nc-osdever_net.webm

The HTTP Request is not echoed here, so you directly see the response after connect and a short pause, the "Bad Request" at the end is me pressing Ctrl+D.

[SuperMaxusa]

Wow, cool!

I'm using DHCP for auto-IP setup when FreeDOS boots, it works out of the box.

It's a mTCP 2024-10-20?
I tested mTCP about 2 months ago (not on wisp, only for default WebSocket relay and fetch-based network), but in dhcp.exe I always got the "Your DHCP lease expires in less than 3600 seconds" error.

After some tests, I found that the DOSLynx' network stack works well, you can try it at https://copy.sh/v86?profile=msdos, run C:\TOOLS\NETWORK\SETNE2K.BAT and C:\TOOLS\NETWORK\DOSLYNX\DOSLYNX.EXE.

[SuperMaxusa]

And if I would change it to one year (8760 hours) plus one hour:

dhcp-range=10.5.0.2,10.5.254.254,255.255.0.0,8761h

then it would skip the lease time check in mTCP alltogether?

I checked now and yes, DHCP worked for me.

I'm using a boot floppy from MicroWeb, so mTCP version can be outdated.
As expected, also HTTP works fine:

My problem is that I don't know how to apply these modifications and then restart the docker file locally. Sorry to ask, but would you happen to know how to do this? I don't know much about docker installations and need help.

Don't worry, you can do it in minutes:

0. Install Docker, if you don't have it: https://docs.docker.com/engine/install/

1. Load tun module, it can be done like this:

sudo modprobe tun

2. Clone repository with proxy:

git clone https://github.com/benjamincburns/websockproxy.git

3. Modify files that you need.

4. Build a new image for the container, you can use any tag name:

docker build . --rm --tag websockmodified

5. Run new container (in v86, you need to use ws://localhost:8080 as "Networking proxy"):

docker run --privileged -p 8080:80 --name relay websockmodified

6. If you need change something again, stop and delete container, then go to step 3.

docker stop relay
docker rm relay

Can't say how it works with WSL (in theory, WSL2 can use tun/tap). but on a virtual machine or real Linux, it should works.

I want to test https://github.com/krishenriksen/node-relay later to see what could actually be causing this problem.

[SuperMaxusa]

After few tests, can confirm that it's problem in mTCP, not in relay.
Even with the SLiRP network stack on QEMU, which has 86400 seconds of lease time, the DHCP request failed.

[chschnell]

My problem is that I don't know how to apply these modifications and then restart the docker file locally. Sorry to ask, but would you happen to know how to do this? I don't know much about docker installations and need help.

Don't worry, you can do it in minutes:

Brilliant!

Thanks to your instructions I got it up running immediately, patched the throttling out and a 72h lease time (259200 seconds) in. mTCP's DHCP client under FreeDOS now works with websocketproxy when booting the image, here's the relevant excerpt from the log:

Packet driver for NE2000, version 11.4.3
Packet driver skeleton copyright 1988-93, Crynwr Software.
This program is freely copyable; source must be available; NO WARRANTY.
See the file COPYING.DOC for details; send FAX to +1-315-268-9201 for a copy.

System: [345]86 processor, ISA bus, Two 8259s
Packet driver software interrupt is 0x60 (96)
Interrupt number 0xA (10)
I/O port 0x300 (768)
My Ethernet address is 00:22:15:E1:19:DA
mTCP DHCP Client by M Brutman (mbbrutman@gmail.com) (C)opyright 2008-2020
Version: Mar  7 2020

Timeout per request: 10 seconds, Retry attempts: 3
Sending DHCP requests, Press [ESC] to abort.

DHCP request sent, attempt 1: Offer received, Acknowledged

Good news everyone!

IPADDR 10.5.212.11
NETMASK 255.255.0.0
GATEWAY 10.5.0.1
NAMESERVER 10.5.0.1
LEASE_TIME 259200 seconds

Settings written to 'C:\FreeDOS\MTCP.CFG'

mTCP's DNSTEST.EXE works. HTGET.EXE works, too, although a bit sluggish, but then it completely falls apart with NC.EXE (netcat). It stalls for long stretches of time, I ran out of patience to see if it ever completes.

These mixed results are quite a mystery to me. When I'm using WISP (with PR #1178) all these things work reliable, but with websocketproxy it falls apart. I am aware of the architectural differences between the two, but I would have thought websocketproxy works better (if anything) than WISP.

Anyways thanks once more for the docker instructions, you really helped me out there, I really need to finally work through some docker tutorial to get up to pace there.

[SuperMaxusa]

HTGET.EXE works, too, although a bit sluggish, but then it completely falls apart with NC.EXE (netcat). It stalls for long stretches of time, I ran out of patience to see if it ever completes.

Hmm, maybe the server's keepalive (if you use a nc for HTTP connections) could cause this behaviour?

By the way, I finally found the cause that problem: if you use a mtcp.cfg file from sample.cfg template, the old timestamp value might be there.
According to this DHCP logic, it always marked your lease time as expired. To fix this, delete the TIMESTAMP ( ... ) line (usually the second line in the file) in your config.

[chschnell]

Hmm, maybe the server's keepalive

The response starts coming in within seconds, I believe keepalives shouldn't really come into play here. TCP keepalives usually come in after a minute of silence.

To fix this, delete the TIMESTAMP ( ... ) line (usually the second line in the file) in your config.

Great, I will keep this in the back of my mind, the situation under FreeDOS is a bit different for me.

Nevertheless, the list of mTCP bugs and workarounds keeps growing...

[chschnell]

I think I found the reason why HTGET.EXE (mTCP's HTTP GET command line client) in mTCP hangs at the end!

To clarify, HTGET.EXE does not crash, it prints nicely to stdout while data is coming in but then sits there waiting for what appears to be the last chunk of data. HTGET.EXE responds to user input and can be exited normally.

After some digging I came to the conclusion that TCP's graceful close handshake in fake network is incomplete. The required TCP state values are defined but hardly used, some details of the TCP state machine are missing.

Then I found this FIN-related bug in TCPConnection.pump(): the second if can never be true given the first if statement (this.send_buffer.length remains unchanged between the two ifs), so in this specific case the FIN flag (which marks the sender's last package) never gets send to the guest's TCP stack.

When I changed the second if to:

if(this.send_buffer.length - data.length < 1) reply.tcp.fin = true;

it made HTGET.EXE work!

Everything else using TCP broke though (which makes sense, with this hack any TCP connection is getting the FIN bit set as soon as it runs out of data to send), but this is a significant clue as to where the hanging connections in HTGET.EXE come from.

I will try to properly complete the TCP state-related code in fake_network.js. I'm aiming at full support for all mTCP binaries under FreeDOS. mTCP's FTP server and their new NetDrive look really interesting.

WispServerCpp works great, I run it inside a Debian VM on my Windows Desktop (VirtualBox) which gives me a local high-speed WISP server. I've installed a whole Debian 12 into V86 with network support using WISP, including apt and lynx and everything, works really reliable.

[basicer]

Nice catch! I never got around to getting the four way close handshake fully implemented because it seemed to work alright on Linux just doing what I had.

[chschnell]

Thanks for your feedback and confirmation regarding the unfinished TCP close handshake!

I think fake_network.js is an unpolished gem, over the weekend I took the liberty to make some efficiency improvements to its write()-related code (meaning code that deals with data flowing towards the guest OS), see PR #1178 from this morning.

Seeing how involved you were with this code in the past, I'd be very interested in your opinion and if you have any ideas left regarding the codes efficiency.

Last night I hit 26 MBit/s download speed using speedtest-cli under V86/WISP/Debian. Later today I'll make a before/after test using open-source LibreSpeed as it gives me a more predictable test setup (it allows me to setup my own local test server).

[chschnell]

The problem with HTGET.EXE is fixed!

When I run HTGET.EXE http://copy.sh/v86/ the HTTP response is downloaded very fast via WISP and is mostly buffered in RAM by TCPConnection.write().

The response content gets forwarded chunk by chunk (1460 bytes each) from RAM to the application running under the guest OS by TCPConnection.pump(). The misbalance in bandwidth between the two sides is very important to understand what is going on here.

Directly after the last call to TCPConnection.write() (when the WISP download is complete) TCPConnection.close() gets called, potentially (long) before the buffered response content has been forwarded to the guest. Closing the TCP connection by setting the FIN flag when we still have buffered data to send must be delayed until the send buffer is empty, only the last buffered package we forward to the guest must have its FIN flag set (that's how this flag is defined).

That turned out to be very easy to fix, mTCP's HTGET.EXE now works just fine together with all the other TCP things.

[chschnell]

Here are some network performance statistics that I now feel confident about. Even though they were created using Debian they are also relevant for FreeDOS.

Test setup

• Desktop: Windows 10, Firefox
• Desktop VM: Debian 12 (10.0.0.44, runs CORS-enabled Apache2, websocketproxy and wisp-js)
• V86 Guest OS: Debian 12 (32 bit), network: virtio
• Websocket proxy: websockproxy (patched: unthrottled, lease time=72h or 259200 seconds)
• WISP server: wisp-js
• V86 must be patched with PR improve fake network write() efficiency #1178 for this

For reproducible download speed tests I wrote bash script speedtest.sh, it tests download performance using a HTTP server in the local network:

# FD13-LiveCD.zip: 374M
URL="http://10.0.0.44/download/FD13-LiveCD.zip"
curl -L -o /dev/null "$URL" 2>&1 | tr "\r" "\n"

It prints nice statistics to stdout and discards downloaded data to the null device.

Test results

Test	websocketproxy	fetch (curr)	fetch (new)	WISP
apt update	~260 kB/s	n/a 1	n/a	~1,770 kB/s
speedtest.sh	1,466k (00:04:21)	2,941k (00:02:10) 2	6,323k (00:00:59) 3	6,592k (00:00:58)

wisp- and fetch-based networking have about the same performance (both use V86's fake network), whereas websocketproxy-based is quite far behind.

A lesson learned: Always prefer network device "virtio" over "ne2k" if you can, ne2k dies midflight under sustained load.

EDIT: replaced WISP server WispServerCpp with wisp-js, updated WISP results.

EDIT 2: @SuperMaxusa replied to this with his excellent fetch benchmark results

Footnotes

1. apt fails with fetch-based networking ↩

2. 0k/s flat up until 00:01:10, then sustained ~6500k/s until the download is finished; reason: fetch-based networking first prefetches the entire HTTP response into RAM before forwarding it into the fake network ↩

3. new fetch-based networking with chunked body forwarding (no prefetching) ↩

[SuperMaxusa]

@chschnell Thanks for the idea! I was thinking about replacing it on xterm.js, which works better than <textarea>, but your implementation looks nice too.

[chschnell]

I was thinking about replacing it on xterm.js, which works better than <textarea>, but your implementation looks nice too.

Uhh, XtermJs is nice, I had been thinking about that. Well, mostly about terminal emulation, but that is so much better.

So now I have two Terminal implementations which can be used interchangeably: my old class DumbTerminal and a new class XtermJsTerminal.

XtermJs works absolutely perfectly out of the box, and it should be super-easy to grow that into a full interactive terminal connected to V86's serial port.

[SuperMaxusa]

For interest, I tried test a networking in examples/two_instances.html with the well-known buildroot-bzimage68.bin to minimize affect from ws/wisp relay or fetch relay.
After few tests, I got an average download speed of about 1800-1970k, regardless of browser and network card.

Here is a one-line HTTP server using socat and dd that sends 32M file:

socat TCP-L:80,crlf,fork system:'echo HTTP/1.1 200 OK;echo;dd if=/dev/zero bs=1M count=32 status=none'

[chschnell]

For interest, I tried test a networking in examples/two_instances.html with the well-known buildroot-bzimage68.bin to minimize affect from ws/wisp relay or fetch relay. After few tests, I got an average download speed of about 1800-1970k, regardless of browser and network card.

Here is a one-line HTTP server using socat and dd that sends 32M file:

socat TCP-L:80,crlf,fork system:'echo HTTP/1.1 200 OK;echo;dd if=/dev/zero bs=1M count=32 status=none'

Hehe, what a lovely server ;)

I had to change your example to use bzimage: buildroot-bzimage68.bin (instead of cdrom: linux4.iso which doesn't include socat) and crank it up to a 256M file, but then I got around 9000k (Firefox).

Isn't it surprising that it performs below wisp and fetch?

I used curl -L http://10.5.0.2/ -o /dev/null for the client, I believe I compared correctly.

EDIT: On a second thought, I now believe it's most likely the fact that the browser has to run two V86 instances here.

[SuperMaxusa]

EDIT: On a second thought, I now believe it's most likely the fact that the browser has to run two V86 instances here.

Yes, I think so. I tried using the demo with Broadcast API (#1196) and got these results:

Firefox:
ne2k - 865k (second time - 1035k)
virtio - 942k (second time - 1348k)

Chrome:
ne2k - 1483k (second time - 1499k)
virtio - 1854k (second time - 1898k)

*the second time means that on the same running pages with server and client, I run again curl 10 seconds after the first attempt.

[chschnell]

More benchmarks, comparing wsproxy, wisp and fetch (rows) under buildroot and debian (columns):

EDIT: Benchmarks are fully automated, see here for the HTML source file. If you want to use it you'll need to edit the URL of libv86.js at the top, and the entire "Local configuration" section.

[chschnell]

I finally figured out how to properly run Chrome in my local test setup. Tested with Chrome 131.0.6778.86 (Windows/MSYS2):

chrome.exe --disable-web-security --ignore-certificate-errors --allow-running-insecure-content --user-data-dir=/tmp/test

The reason I need all that is because I test against a local Apache2 server with a cheap, self-signed SSL certificate.

For some reason Chrome fails to load the Debian image (probably too large at 2047MB), and the WISP test breaks down in the middle, that's all work in progress, however here the first results:

Things to note:

• On the top-left is websockproxy (unthrottled), it performs exactly like under Firefox. This means that the browser's share in network performance is currently neglectable in the case of websockproxy.
• Top-right is normal fetch, it is about 25% faster than under Firefox.
• Bottom-left is fetch with my PHP CORS proxy, it is basically as fast as without the proxy (which is good).

One last note: In general, the behaviour of websockproxy is a bit strange. In my previous benchmarks, websockproxy is noticably slower under buildroot than under Debian, whereas in fetch and WISP it's the opposite. And it seems to underperform.

[ProgrammerIn-wonderland]

I wonder if this is related to mtu settings? That's the only thing which j can think of which might affect performance this much

[ProgrammerIn-wonderland]

Just curious, what is the issue with wisp? A big one I was facing recently was it trying to check the congestion level of a stream that was already closed, as I forgot to add safety checks around that originally but I think that's fixed in your PR

[SuperMaxusa]

I wonder if this is related to mtu settings? That's the only thing which j can think of which might affect performance this much

Do you mean using jumbo frames instead of default?

[ProgrammerIn-wonderland]

Yeah

[SuperMaxusa]

Correct me, but I'm not sure that Jumbo is supported by the version of Ethernet (IIRC it's Ethernet II) that the fake network stack is based on.

Currently, the MTU value is hardcoded on default 1500 bytes:

v86/src/browser/fake_network.js

Line 45 in 298da23

const ETH_PAYLOAD_SIZE = 1500;

...and for virtio-net too:

v86/src/virtio_net.js

Lines 182 to 184 in 298da23

	bytes: 2,
	name: "mtu",
	read: () => 1500,

[chschnell]

I spent the last couple of evenings attempting to reimplement websockproxy, it's called wstap and I just got it to work for the first time, yay! So I ran a test through the benchmark from before:

It is the fastest network backend I've measured so far, and since it operates on OSI layer 2 (full ethernet packets) it is practically universal.

I'm setting up the TAP device on the linux host exactly like @benjamincburns, I believe his setup is conceptually hard to beat, but I'm no TAP expert, though I plan to read up on this subject.

The proxy is also written in Python, but in python 3 and I'm only using the sans-io WebSocket protocol implementation from the websockets library as an external dependency. Internally I run a single epoll loop on all sockets and the TAP device.

The python proxy server does not support TLS (wss), for that I use Apache2 as a frontend (it handles the SSL and proxies the websocket connection to my server). Note that the results from above go through Apache2 (relay URL wss://build-v86/wstap).

It is still in a very early stage, I will release it as soon as it is presentable.