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 ([email protected]) (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.

Footnotes

1. still need to setup a fetch proxy to access the open internet ↩

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) ↩

[ading2210]

If I only want to close my half of the TCP connection (stop sending but keep receiving from the server)

@chschnell

Assuming you mean this, it isn't possible. Wisp deals with higher level TCP/UDP sockets and doesn't care about the specifics of the underlying TCP protocol. Think of it as a multiplexed SOCKS5 proxy over websockets.

[FoxMoss]

Being completely earnest WispServerCpp should not be used. I'm sorry you have had to deal with debugging it.

I'm curious, why do I observe traffic loss with WispServerCpp under high load, and is there anything I can do about it?

The reason WispServerCpp preforms poorly under high load is twofold, it leaks memory constantly, and it has thread contention issues likely dropping packets. Both of these problems are fixable given enough time, but it might be quicker to just rewrite the project from scratch.

There's an existing fork of wisp which does this called wispnet, created by foxmoss I believe and only supported in wispservercpp (correct me if I'm wrong @FoxMoss ) but without the webrtc. Applications can request a hostname and all connections to that hostname, the server forwards to the application.

Yes, I wrote the draft of the protocol, https://github.com/MercuryWorkshop/wispnet-protocol/ a few months ago. It's less of a fork then a backwards compatible extension of the protocol. The reference implementation like the rest of WispServerCpp is very unstable and poorly designed, though I stand by the protocol in cases where WebRTC is impractical.

Sick project though!

[chschnell]

@ProgrammerIn-wonderland @r58Playz @ading2210 @FoxMoss - thanks to all of you for your replies.

I understand the problems surrounding server sockets, I was only insufficiently thinking of an exclusive, local WISP server. A protocol extension is a good idea to cover that.

However I think that it would be worth for any TCP proxy server to support half-closed TCP connections, it's a feature.

I can't put it in better words than I found in this comment, I just edited a little:

The problem you're facing is that you're acting as a proxy between the [V86 guest] client and the application [external TCP server]. You need a way to let the application know that the client indicated that it stops sending, and only the application can decide if it's an indication of end of transfer or of client abort. Sometimes the application will decide that both are equivalent and that's fine. [...] But really any network-based application must be able to tell the difference between half-closed and full-closed otherwise it's deemed to either abusively close on regular half-close or ignore real closes sometimes.

In practice people tend to see TCP as a bidirectional stream while it's in fact two independent unidirectional streams. The only link between the two are the ACK numbers passed along packets to confirm receipt. But FTP servers for example are well used to seing half-closed connections since the data channel can be half-closed during the whole transfer.

This has no urgency whatsoever from my part, just meant for your consideration.

[ProgrammerIn-wonderland]

I think this is the first time most of us are hearing about TCP half closing, it's the first I'm hearing about it atleast.

[chschnell]

I think this is the first time most of us are hearing about TCP half closing, it's the first I'm hearing about it atleast.

Let's look at it from the perspective of the TCP client application that is executed in V86.

The client application may call shutdown(sockfd, SHUT_WR) on the TCP socket before calling close(sockfd).

A call to close() causes a TCP packet with active RST flag to be emitted by the client's TCP stack, while a call to shutdown() causes a packet with active FIN flag.

These two cases (RST and FIN) can be easily distinguished in fake_network.js.

Note that only close() releases the local resources associated with the socket, the call to shutdown() merely changes the way the socket can be used after the call.

So shutdown(SHUT_WR) causes a half-closed TCP connection until the other end closes (which the client waits for before closing), and close() causes a full teardown of the TCP connection. Using shutdown() before close() is often called a graceful shutdown.

Now my problem is, how to map RST (close()) and FIN (shutdown()) to the WISP protocol. It has become clear that WISP frame type CLOSE with reason 0x02 (I write that as CLOSE/0x02) maps to RST, but FIN is missing. The current workaround is to map both RST and FIN to CLOSE/0x02, but that is not exactly correct.