Trixter
Veteran Member
I just got back from traveling, but will definitely do this for you in the next day or two. Thanks for helping to locate the problem.
- 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
EtherDFS - an ethernet drive for DOS
- Thread starter Pepinno
- Start date
keenerb
Veteran Member
Seems to be working fine for me.
I haven't been having packet issues; should I enable debug?
I haven't been having packet issues; should I enable debug?
The consensus, currently, seems to be that EtherDFS is safe to use, unless you have a flaky hardware (like a flaky ethernet card or a flaky parallel port attached to a Pocket Ethernet Adapter). Given that all retro-hardware is past its expected life expectancy, it means...
...that YMMV.
Anyway, EtherDFS looks to me as a major breakthrough in DOS/PC retro-computing. Any machine can now easily transfer files if it has a ethernet NIC or a parallel port with a Pocket Ethernet Adapter - no more sneakernet or ad-hoc serial cables to do it "laplink-style".
Stone
10k Member
Hey... any machine with a parallel port -- period! That's it. Full parallel network accessibility has been around for over 25 years!
No Pocket Ethernet Adapter is necessary.Hey... any machine with a parallel port -- period! That's it. Full parallel network accessibility has been around for over 25 years!
A parallel port by itself is a problem, as modern machines usually don't have one to interface with your retro PC, whereas modern machines tend to have some kind of ethernet in them.
mateuszviste
Experienced Member
I understand you tested the EtherDFS "test" (0.8.1) version, and it works for you. There is no point in activating debug if all works fine for you, really. And it would be surprising if the test version did not work for you while the "normal" (0.8) was doing fine
The test version only adds a checksum on frames and validates everything it receives from ethersrv. It detects sneaky corruptions that might happen elsewhere than on the Ethernet wire itself (for example bits that would flip on the LPT port, if the NIC is LPT-connected, or bytes that go missing). Unfortunately I didn't get any feedback from Trixter, so I can only hope it solves the problem on his hardware. Soon I will release a formal v0.8.1 with this patch. It will make EtherDFS slightly slower, but I guess it's worth it, even if only for the 0.1% of people that run it on flaky hardware.
Er, Novel Netware, FTP, NFS and MS style file and printer sharing have existed for a long time on PC class hardware. Let's not go overboard with the superlatives ...
keenerb
Veteran Member
It's also only 7k memory.
It deserves a few superlatives for that. Smallest alternative I've seen was around 50k.
Novell Netware's IPX is a layer of complexity over raw ethernet, FTP and NFS run over TCP/IP which is two layers of complexity over raw ethernet, LAN Manager/NetBIOS is a layer of complexity over raw ethernet. Those layers of complexity eat up scarce conventional memory on old PCs, and slow them down.
EtherDFS is just the sweet spot: nimble, fast, easy, modern-world compatible, and open-source.
I don't know about you, but I am breaking the champagne about it!
This doesn't take away from EtherDFS, but EtherDFS by definition is a layer of complexity over raw Ethernet too ... Otherwise, we would just call it Ethernet.
keenerb
Veteran Member
I really like that I can still apparantly use mtcp over it. I've FTP'd data from an external server directly onto my mapped drive, which is neat.
keenerb
Veteran Member
It's not working with a Xircom pocket ethernet for me either, I just set up a test
I tried to run a simple text game on my mapped drive.
"type angdos.cfg"
Code:
Received frame of 80 bytes (cksum = ENABLED)
00 0C 29 0A 26 B3 00 80 C7 2E 64 C6 ED F5 00 00 | ..).&... ..d.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 8A D9 82 11 02 1B 13 5C 47 41 | ........ .....\GA
4D 45 53 5C 44 4E 44 5C 44 4E 44 2E 3F 3F 3F 00 | MES\DND\ DND.???.
CHECKSUM MISMATCH! Computed: 0x6CC5h Received: 0xD98Ah
Received frame of 80 bytes (cksum = ENABLED)
00 0C 29 0A 26 B3 00 80 C7 2E 64 C6 ED F5 00 00 | ..).&... ..d.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 8A D9 82 11 02 1B 13 5C 47 41 | ........ .....\GA
4D 45 53 5C 44 4E 44 5C 44 4E 44 2E 3F 3F 3F 00 | MES\DND\ DND.???.
CHECKSUM MISMATCH! Computed: 0x6CC5h Received: 0xD98Ah
Received frame of 80 bytes (cksum = ENABLED)
00 0C 29 0A 26 B3 00 80 C7 2E 64 C6 ED F5 00 00 | ..).&... ..d.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 8A D9 82 11 02 1B 13 5C 47 41 | ........ .....\GA
4D 45 53 5C 44 4E 44 5C 44 4E 44 2E 3F 3F 3F 00 | MES\DND\ DND.???.
CHECKSUM MISMATCH! Computed: 0x6CC5h Received: 0xD98Ah
Received frame of 80 bytes (cksum = ENABLED)
00 0C 29 0A 26 B3 00 80 C7 2E 64 C6 ED F5 00 00 | ..).&... ..d.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 8A D9 82 11 02 1B 13 5C 47 41 | ........ .....\GA
4D 45 53 5C 44 4E 44 5C 44 4E 44 2E 3F 3F 3F 00 | MES\DND\ DND.???.
CHECKSUM MISMATCH! Computed: 0x6CC5h Received: 0xD98Ah
Received frame of 80 bytes (cksum = ENABLED)
00 0C 29 0A 26 B3 00 80 C7 2E 64 C6 ED F5 00 00 | ..).&... ..d.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 8A D9 82 11 02 1B 13 5C 47 41 | ........ .....\GA
4D 45 53 5C 44 4E 44 5C 44 4E 44 2E 3F 3F 3F 00 | MES\DND\ DND.???.
CHECKSUM MISMATCH! Computed: 0x6CC5h Received: 0xD98AhI tried to run a simple text game on my mapped drive.
Code:
Received frame of 92 bytes (cksum = ENABLED)
00 0C 29 0A 26 B3 00 80 C7 2E 64 C6 ED F5 00 00 | ..).&... ..d.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 65 64 82 2C 02 2E 00 00 01 01 | ......ed .,......
00 00 5C 47 41 4D 45 53 5C 41 4E 47 42 41 4E 44 | ..\GAMES \ANGBAND
5C 41 4E 47 44 4F 53 2E 43 46 47 00 | \ANGDOS. CFG.
CHECKSUM MISMATCH! Computed: 0xB232h Received: 0x6465h
Received frame of 92 bytes (cksum = ENABLED)
00 0C 29 0A 26 B3 00 80 C7 2E 64 C6 ED F5 00 00 | ..).&... ..d.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 65 64 82 2C 02 2E 00 00 01 01 | ......ed .,......
00 00 5C 47 41 4D 45 53 5C 41 4E 47 42 41 4E 44 | ..\GAMES \ANGBAND
5C 41 4E 47 44 4F 53 2E 43 46 47 00 | \ANGDOS. CFG.
CHECKSUM MISMATCH! Computed: 0xB232h Received: 0x6465h
Received frame of 92 bytes (cksum = ENABLED)
00 0C 29 0A 26 B3 00 80 C7 2E 64 C6 ED F5 00 00 | ..).&... ..d.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ........ ........
00 00 00 00 00 00 65 64 82 2C 02 2E 00 00 01 01 | ......ed .,......
00 00 5C 47 41 4D 45 53 5C 41 4E 47 42 41 4E 44 | ..\GAMES \ANGBAND
5C 41 4E 47 44 4F 53 2E 43 46 47 00 | \ANGDOS. CFG.
CHECKSUM MISMATCH! Computed: 0xB232h Received: 0x6465h"type angdos.cfg"
Trixter
Veteran Member
I finally got around to testing this, but I'm afraid the results were worse than before. I am limiting my testing to one platform to keep things simple and consistent for troubleshooting. I compiled the 0406 version with debugging on, downloaded and ran the beta client, and now I cannot copy files. At the DOS side, I see this:
Code:
c:\tdl.net>copy g:\tdl\titles.idx
File not found - G:\TDL\TITLES.IDX
0 file(s) copiedOn the server side, I get the following output which is attached.
Based on the error output, I suspect your checksum routine has an error?
mateuszviste
Experienced Member
If it would, it would be buggy in all situations, with all hardware, not only with the PE3 gimmick.
Brian already sent me his results off-forum yesterday, and from these I noticed that for some reason the PE3 appears to append an additional 1-byte to the frame. I have no clue why it does that, but when I recomputed by hand the checksums based on the debug output Brian sent me, the checksum magically started to match. Long story short, I uploaded a new test version today, that is able to detect when a frame is padded, and trim the additional garbage. The latest test version requires ethersrv-linux version 20170415. Since I don't have a PE3 myself, I count on you guys to test it out
http://mateusz.viste.fr/temp/etherdfs-test/
If it would, it would be buggy in all situations, with all hardware, not only with the PE3 gimmick.
Brian already sent me his results off-forum yesterday, and from these I noticed that for some reason the PE3 appears to append an additional 1-byte to the frame. I have no clue why it does that, but when I recomputed by hand the checksums based on the debug output Brian sent me, the checksum magically started to match. Long story short, I uploaded a new test version today, that is able to detect when a frame is padded, and trim the additional garbage. The latest test version requires ethersrv-linux version 20170415. Since I don't have a PE3 myself, I count on you guys to test it out
http://mateusz.viste.fr/temp/etherdfs-test/
You are blaming the Xircom PE3? That's a pretty bold move ... they were in use all over the place in the mid 90s on corporate networks, which was a pretty expensive environment at the time. If the PE3 was adding extra bytes to a packet it would have never been sold.
I don't have anything in the mTCP code that deals with padding on packets, except for ensuring that all packets that I send are a minimum of 60 bytes long to make Intel gigabit adapters happy. (And I think that number probably should be 62, not 60, so I might fix it after re-investigating it.)
Can you post or send me your source code? I wouldn't mind looking for the off-by-one error no matter where it is.
mateuszviste
Experienced Member
I am sure of nothing, and since I cannot reproduce the problem at hand, I have to rely on assumptions. Note, that "adding an extra byte" is not as bad as it sounds - in most cases it's totally harmless, since IP doesn't care anyway, as it knows exactly the length of payload to read.
What I do know, is that:
- EtherDFS works perfectly with all NICs and packet drivers I could test
- It's reported as "not working" with PE-3
- On the PE-3 thing, based on the ethersrv debug output provided by both Brian and Jim, I see that EtherSRV seem to receive one extra byte of data
Clearly the above observations aren't enough to lead to a "PE3 sends one extra byte" conclusion, but the fact that the problem appears so far only with this one NIC makes it suspect.
Not only gigabit adapters, there are more stuff that expects >= 60 bytes frames. My WiFi bridge doesn't tolerate anything less than 60 bytes, which was very troublesome with WatTCP, as the latter tends to generate smaller frames sometimes (the workaround I used is activating the TCP timestamp option in WatTCP configuration to force the segments to be bigger - adding the 14-bytes long TCP timestamp is enough to pass the 60-bytes Ethernet barrier).
Of course. EtherDFS is an open-source project, and its source code is publicly available on the project's SVN:
https://sourceforge.net/p/etherdfs/code/HEAD/tree/
keenerb
Veteran Member
Everything seems to be working OK on a XIrcom PE-3 test system.
As a presumably separate issue, I have also noticed that EtherDFS does NOT like multiple clients attached to same server, very strange things seem to happen like "MKDIR TEMP" actually made TEMP6, and "mkdir ASDF" failed completely.
This debug output on my server was during a time when both my Tandy 1000TL and my Tandy 2500SX were attempting to access the same C drive share. This is probably just something that I shouldnt' be doing to begin with, but it happened and I got some error output so it can't hurt to mention it.
As a presumably separate issue, I have also noticed that EtherDFS does NOT like multiple clients attached to same server, very strange things seem to happen like "MKDIR TEMP" actually made TEMP6, and "mkdir ASDF" failed completely.
This debug output on my server was during a time when both my Tandy 1000TL and my Tandy 2500SX were attempting to access the same C drive share. This is probably just something that I shouldnt' be doing to begin with, but it happened and I got some error output so it can't hurt to mention it.
Code:
CHECKSUM MISMATCH! Computed: 0xC6BDh Received: 0x8CFDh
CHECKSUM MISMATCH! Computed: 0xC6BDh Received: 0x8CFDh
CHECKSUM MISMATCH! Computed: 0xC6BDh Received: 0x8CFDh
CHECKSUM MISMATCH! Computed: 0xC6BDh Received: 0x8CFDh
CHECKSUM MISMATCH! Computed: 0xD312h Received: 0xA427h
CHECKSUM MISMATCH! Computed: 0xD252h Received: 0xA427h
CHECKSUM MISMATCH! Computed: 0xD312h Received: 0xA427h
CHECKSUM MISMATCH! Computed: 0xD252h Received: 0xA427h
CHECKSUM MISMATCH! Computed: 0xD312h Received: 0xA427h
CHECKSUM MISMATCH! Computed: 0x47D4h Received: 0x8F2Ah
CHECKSUM MISMATCH! Computed: 0x47D4h Received: 0x8F2Ah
CHECKSUM MISMATCH! Computed: 0x47D4h Received: 0x8F2Ah
CHECKSUM MISMATCH! Computed: 0x47D4h Received: 0x8F2Ah
CHECKSUM MISMATCH! Computed: 0x47D4h Received: 0x8F2Ah
CHECKSUM MISMATCH! Computed: 0xCDC4h Received: 0x9A3Bh
CHECKSUM MISMATCH! Computed: 0xCE1Ch Received: 0x9A3Bh
CHECKSUM MISMATCH! Computed: 0xCDC4h Received: 0x9A3Bh
CHECKSUM MISMATCH! Computed: 0xCE1Ch Received: 0x9A3Bh
CHECKSUM MISMATCH! Computed: 0xCDC4h Received: 0x9A3Bh
CHECKSUM MISMATCH! Computed: 0xA10Fh Received: 0x4021h
CHECKSUM MISMATCH! Computed: 0xA10Fh Received: 0x4021h
CHECKSUM MISMATCH! Computed: 0xA10Fh Received: 0x4021h
CHECKSUM MISMATCH! Computed: 0xA10Fh Received: 0x4021h
CHECKSUM MISMATCH! Computed: 0xA10Fh Received: 0x4021h
MKDIR Error: Invalid argument
CHDIR Error (/mnt/dosdisk//asdf?): No such file or directory
MKDIR Error: Invalid argument
CHDIR Error (/mnt/dosdisk//templ): No such file or directory
MKDIR Error: Invalid argument
RMDIR Error: No such file or directory
MKDIR Error: Invalid argument
MKDIR Error: Invalid argument
CHDIR Error (/mnt/dosdisk//temp5): No such file or directoryTrixter
Veteran Member
This sounds very much like my reproducible issue of a random junk byte being appended to frames.
keenerb
Veteran Member
Did you have multiple clients connected? When I terminated all other clients it functioned normally.
mateuszviste
Experienced Member
Good. So trimming out the extra byte makes it work.
As Jim pointed out already, this does look very much like still the same problem: a garbage byte trailing the query and not trimmed. There shouldn't be any problem with running multiple clients on the same drive (that's one of the goals behind EtherDFS after all). Three questions:
- are both Tandy PCs running a PE3 adapter?
- when things stop working, do they stop working for one of the PCs, or both?
- are you 100% sure that you run the latest "test" EtherDFS release on both PCs? (old EtherDFS clients will still work with ethersrv, but without the data-validation features)