maxtherabbit
Veteran Member
Dunno about ODI, but I've definitely used NDIS packet shims with mTCP and everything works 100%
- VCF South West - June 14 - 16, Davidson-Gundy Alumni Center at University of Texas at Dallas
- VCF West - Aug 2 - 3, Computer History Museum, Mountain View, CA
- VCF Midwest - Sept 7 - 8 2024, Schaumburg, IL
- VCF SoCal - Mid February 2025, Location TBD, Southern CA
- VCF East - April 2025, Infoage Museum, Wall NJ
-
Please review our updated Terms and Rules here
Bring out your dead! (Looking for mTCP bugs)
- Thread starter mbbrutman
- Start date
Chuck(G)
25k Member
Just to be clear - your NICs were PCI-based and came with real-mode NDIS drivers?
maxtherabbit
Veteran Member
No, I never said a thing about PCI. ISA cards
Caluser2000
Banned
But that is what Chucks query was about....PCI nics that had packet drivers available for them.
Not need to get offended at all. Maybe you should have mention you ment ISA nics.
I also thought WFT? And maybe some other members did as well.....
Last edited:
Chuck(G)
25k Member
For yucks, I'll see if I can get the NDIS driver working any better than the ODI one--if it doesn't, no matter, as I've got the Netgear card working.
BloodyCactus
Experienced Member
Ive tried 3com 3c905B-TX + 3c905C-TX PCI nic packet drivers are fine. no ndis, no odi, just packet driver loaded high!
Chuck(G)
25k Member
Yeah, I've got one of those in one of my systems. I preferred those when I was still buying NICs because of the NE2000 compatibility. You can find drivers for that everywhere.
That picture was taken when the web server was first started on the machine on March 31st. It's been running *continuously* since then, and that's about 1510 ten hours (63 days) now. It's been exposed to whatever comes across port 80 on my internet connection, including weird JSON from crypto mining pools, malformed HTML, and script-kiddie attacks. It has served over 71000 objects (HTML files, images, etc.) handled 4 million incoming Ethernet packets and sent 2.4 million packets. It has survived at least 3 power failures, including one lasting 2 hours. (It's on a UPS.)
I think it's reliable enough. ;-0
I need to setup a few more of these behind load balancers and start offering my own cloud-based PC XT class web hosting service.
-Mike
I've been using mTCP a lot and it works really well on my 286. Thank you, Mike!
However, when trying to build mTCP using Open Watcom 1.9 on Linux, the build breaks because of file name issues. mTCP is very inconsistent in its usage there. For example, TCPLIB/ARP.CPP includes "timer.h" (lower-case), TCPLIB/TIMER.CPP includes "Timer.h" (mixed-case) and APPS/DHCP/MAKEFILE references both "..\..\TCPLIB" (upper-case) and "..\..\utils" (lower-case) in its rules.
These inconsistencies make it very hard to cross-compile mTCP from a Linux host and require major patches throughout the system. So I humbly ask if you could standardize on either upper-case or lower-case in the future to make life easier for other users.
The ZIP file itself (mTCP-src_2023-03-31.zip) contains upper-case file names, but "unzip -L" can be used to extract lower-case instead. (There is also a stray TCPLIB/.UTILS.CPP.swp included.)
That being said, mTCP is still a great piece of software.
However, when trying to build mTCP using Open Watcom 1.9 on Linux, the build breaks because of file name issues. mTCP is very inconsistent in its usage there. For example, TCPLIB/ARP.CPP includes "timer.h" (lower-case), TCPLIB/TIMER.CPP includes "Timer.h" (mixed-case) and APPS/DHCP/MAKEFILE references both "..\..\TCPLIB" (upper-case) and "..\..\utils" (lower-case) in its rules.
These inconsistencies make it very hard to cross-compile mTCP from a Linux host and require major patches throughout the system. So I humbly ask if you could standardize on either upper-case or lower-case in the future to make life easier for other users.
The ZIP file itself (mTCP-src_2023-03-31.zip) contains upper-case file names, but "unzip -L" can be used to extract lower-case instead. (There is also a stray TCPLIB/.UTILS.CPP.swp included.)
That being said, mTCP is still a great piece of software.
I'm surprised that I'm hearing about this problem for the first time; I suspect not many people are actively working with the source code. After years of sweating the details I got lazy and somebody has now noticed ...
My development environment used to be DOS and now it's Windows so I don't have the upper/lower case problem that you describe. I'll scrub that for the next release, but in general it should be safe to force everything to lower case.
Are you making anything interesting?
My development environment used to be DOS and now it's Windows so I don't have the upper/lower case problem that you describe. I'll scrub that for the next release, but in general it should be safe to force everything to lower case.
Are you making anything interesting?
Thank you. I think most users use DOS/Windows as well, so they won't notice, either.
I'd like to get TLS 1.2/1.3 working on my 286/12. Since the TLS apocalypse, internet access with older machines has become useless. Even sites hosting old drivers and using simple layouts only respond with an HTTPS redirect, as they will be cut off from search engines otherwise. The hard part is doing the handshake before the server closes the connection. Encryption won't be fast, and security isn't even an option.
Eventually, I'd like to get something in between MicroWeb and Arachne. But that is a long shot. I did port Arachne to SDL2, but its code quality is... not great.
Also having an interest in this, though I've focused on SSH, on anything below a 386 I think you're going to end up writing a small server to offload the asymmetric cryptography calculations (ECDH/ECDSA/RSA/Ed25519) to another machine on the local network, and return the results of the calculation to the 286/8088 machine (such that it can proceed with the handshake) in order to achieve anything tolerable.
A fast 386 is tolerable (i.e., negotiating SSH in under 30 seconds) and a fast 486 can calculate through modern crypto without any issue (negotiating SSH in under 10 seconds).
Have you thought of which TLS library to use? MbedTLS appears the most promising, though perhaps it needs some conversion for 8086 memory models, stack usage, and such.
We should talk sometime. I blew a few hours a few weeks ago doing a simple proxy that accepts HTTP connections and converts them to HTTPS. It's smart enough to scan the headers on the response and convert redirects from HTTPS back to HTTP so that the source browser doesn't get a redirect it can't use. I was able to force Firefox to login in and interact with my PCjr web forum (which requires HTTPS) using it which demonstrates the idea is sound, but it needs a lot of work.
In principle it's similar to SSLSTRIP, which was used for man-in-the-middle attacks. Now the technique is suitable for keeping old machines connected.
I think the proxy idea is the most general purpose and workable idea, but the problem we're going to have is that old browsers will still have a hard time with modern sites even if you take care of the encryption problem. Microweb is never going to be able to use the modern web unless something else does a lot of heavy lifting or rewriting, and by that point you might as well be running a modern web browser headless and accessing it via VNC or something like that.
Side note: happy enough to discuss mTCP here, but I'd really like to migrate this type of conversation to https://groups.google.com/g/mtcp. (I'm running out of time/energy to keep tabs on many different forums.)
In principle it's similar to SSLSTRIP, which was used for man-in-the-middle attacks. Now the technique is suitable for keeping old machines connected.
I think the proxy idea is the most general purpose and workable idea, but the problem we're going to have is that old browsers will still have a hard time with modern sites even if you take care of the encryption problem. Microweb is never going to be able to use the modern web unless something else does a lot of heavy lifting or rewriting, and by that point you might as well be running a modern web browser headless and accessing it via VNC or something like that.
Side note: happy enough to discuss mTCP here, but I'd really like to migrate this type of conversation to https://groups.google.com/g/mtcp. (I'm running out of time/energy to keep tabs on many different forums.)
I was planning to hand-roll the crypto, removing security for speed. So far, I have primitives for aes128 (16-bit), aes256 (16-bit), base64 (8-bit), curve25519 (64-bit), sha256 (32-bit) and hmac-sha256 (32-bit). With a precomputed private key, a TLS 1.2 handshake should be doable with a single curve25519 multiplication, which currently takes about 30 seconds. I hope that a 16-bit assembly implementation can reduce this by 25%, making the handshake possible. Maybe it will be tolerable when paired with HTTP Keep-Alive.
Obviously, modern sites will never work. Arachne is surprisingly usable (but very slow on a 286), while Microweb doesn't even attempt to render 'ö' and cannot download files. Somewhere inbetween a sweet spot should exist. Some BBSes offer telnet-over-tls, and there is also a working Slack client for Windows 3.1, but it requires a TLS proxy to handle encryption. I'd like to get away without one.
I've never used Google Groups, but we can continue the discussion in a separate topic (or private messages) here, if you'd like.
The machine is coming up on 5,000 hours of continuous runtime ...
- 24.7 million packets received on the Ethernet (12.1 million of them for TCP/IP)
- 14.3 million packets sent (11.1 million of them for TCP/IP)
- 639,000 TCP/IP connections
- 581,720 files, images or error messages served
- A handful of small power outages that I know of. (Thank you UPS!)
- A live-patching the executable in memory session to disable the logging to disk to conserve disk space.
Caluser2000
Banned
Good on ya Mike.
Wait, what? How did you do this?
JAXVintagePC
Experienced Member
I can recommend PCI PCBs with the RTL8209(AS) chip. Those work great with mTCP. Both on RJ45 and BNC (even with RG59/RG6).
Well done Mike! I really enjoy mTCP!
Well done Mike! I really enjoy mTCP!
I added a "shell" to DOS keyboard shortcut, figuring that it might be useful for a long run. I was using it to check the disk space and when the Tom's Hardware story came out, the disk space usage increased dramatically.
By then the executable was about 3 months old so I didn't have listing files for it. But I was able to get "close enough" to what I was running on the machine, and then I started searching for the correct variables or code to zap using debug. My first few attempts using a VM failed because Open Watcom obfuscated the code too much. (I was just going to jump around the fwrite call.) Eventually I found an if check that I could modify instead.
So technically the machine still has the debug log open. It's just not writing anything to it. When it comes time to shut it down I'll undo the modification so that I can get the final stats in the log file.