• Please review our updated Terms and Rules here

EtherDFS - an ethernet drive for DOS

My answer seems to have to be checked by an admin before it appears, perhaps I'm still too new to the forum...
I will try to answer again (possibly this third answer will all come at the same time, but I cannot see the posts I tried to make).

Yes, I did MKFS.

I did fiddle around with read/write rights without success. Now, I'm out of ideas. Could it be that freedos, even listed as one of the working DOSes, does not work sometimes? Which other DOS version should I try?

I'm kind of out of empty 1.2M disks, and it is not that easy to try out new DOS versions, as I have no other computer with an 1.2 drive, so I'd rater be pointed in some direction what gives best success rate, if even this may be part of the problem or if it is completely on the server side. When I finally get the 5170 up and running, I will save some of the disks onto a modern computer and be able to exchange data more easily with this old system...
 
I have had zero luck using etherdfs and ethflop over wifi extenders. I've tried several. They don't seem to want to pass the data.
 
JohanLu said:
My answer seems to have to be checked by an admin before it appears, perhaps I'm still too new to the forum...
I will try to answer again (possibly this third answer will all come at the same time, but I cannot see the posts I tried to make).
Click to expand...

Yeah, unfortunately you're held hostage to admin approvals until you hit the 10 post mark.

Per keenerb's comment, EtherDFS will definitely only work over a network that fully bridges Layer2 packets; it operates directly on the ethernet frame level, it doesn't use wrap the data in standard TCP/IP headers. It works for me over an ethernet/powerline bridge that works on the layer2 level, but wifi extenders are often either layer3 devices (IE, the ethernet port(s) on a separate network from the one the wireless bridge joins and they NAT the clients behind them) or they do "clever" proxyarp bridging that might not recognize nonstandard protocols.
 
It's more than just extenders; etherdfs won't work on any wireless at all. Wireless bridges and extenders don't bridge layer 2. Found this out testing with a wireless bridge; had to connect a hard wire cable from my vintage gear to my switch to get etherdfs working.

A future rewrite to use standard, routable IP is an official feature request.
 
Trixter said:
It's more than just extenders; etherdfs won't work on any wireless at all.
Click to expand...

Has anyone tried it with a WDS-compliant bridge? In theory I think that *should* work, but I don't have one lying around to verify. Smaller bridges that act like "normal clients" won't, because the access points generally do not take kindly to multiple MACs on a single client. And there still might be some vendor variability. I remember back in the day Mac-in-folk complained at length that some Wifi access points filtered classic Ethertalk packets, which EtherDFS's traffic is broadly similar to.

On the *server* side it works for me at least to run ethersrv-linux on a wifi interface, but this might also potentially be an area where your mileage may vary.
 
Trixter said:
It's more than just extenders; etherdfs won't work on any wireless at all. Wireless bridges and extenders don't bridge layer 2. Found this out testing with a wireless bridge; had to connect a hard wire cable from my vintage gear to my switch to get etherdfs working.
Click to expand...

I moved both devices to the same physical network, though "behind" the wireless bridge... Thought it would work... But it did not. Guess that the traffic, at least some part of it, will go back on the wireless to the true network that handles the DHCP etc. The only places where I did finish the real physical network is down in the basement where cable modem, routers etc are placed and the kids rooms and to a WiFi AP and the TV. I just cannot risk to wake the kids up by suddenly in the middle of the night turn on an old 5170 with the kind of jet sound it produces - that might give them nightmares about old computers. Or disconnect the TV when wife is watching something... But I guess that I need to finish some physical LAN to more places in the house as my wife wants a physical connection when working from home - she has actually asked for it cause a lot more working from home now. At least that is a better excuse to get time to do it than to try to explain that the ancient 5170 needs it ;)
 
Eudimorphodon said:
I remember back in the day Mac-in-folk complained at length that some Wifi access points filtered classic Ethertalk packets, which EtherDFS's traffic is broadly similar to.
Click to expand...

Good to know, I'm collecting stuff to connect an old MacLC475 (with ethernet card) to a AppleTalk network with at least one MacPlus, to bridge the Plus to the outer world... But the LC475 seem to have TCP/IP already on the HDD. My mother used this Mac when working on the university. It even had a web-browser installed, so it is perhaps newer than the Mac EtherTalk?
 
JohanLu said:
But the LC475 seem to have TCP/IP already on the HDD. My mother used this Mac when working on the university. It even had a web-browser installed, so it is perhaps newer than the Mac EtherTalk?
Click to expand...

"Ethertalk" refers to Apple's method of packaging Appletalk DDP packets inside of Ethernet frames, IE, the protocol that Macs run on Localtalk connections with Ethernet headers wrapped around it. Under the "Classic" MacOS it's still generally the default for file and printer sharing (AFP, PAP) even if the machine is directly using TCP/IP for other tasks. Apple invented "Appleshare IP" as a method to encapsulate AFP inside of IP packets sometime during the System 7 era for better efficiency routing over large networks and over the internet. (Ethertalk doesn't scale well.) But DDP for file sharing was still around pretty much to the end of the System 9 era.

All the WiFi WAPs I've ever owned (and that I've actually tried it on) didn't have a problem with passing Ethertalk packets, but supposedly it could be a real problem. It *will* generally not pass through any kind of router or other layer3/proxied hop, like ethernet->wifi adapters.
 
keenerb said:
Yes. That's what I run on my 1000TL.
Click to expand...

Interesting. When I try to use it, for instance:

etherdfs :: C-E

It claims it mounts it but "dir e:" gives me an "invalid drive specified". Running the packet driver at the default 0x60. Tried force specifying the server's MAC and other variations on the theme with zero luck.
 
Eudimorphodon said:
Interesting. When I try to use it, for instance:

etherdfs :: C-E

It claims it mounts it but "dir e:" gives me an "invalid drive specified". Running the packet driver at the default 0x60. Tried force specifying the server's MAC and other variations on the theme with zero luck.
Click to expand...

Did you set lastdrive=E in config.sys? I want to think that was one hurdle I had with drdos.
 
keenerb said:
Did you set lastdrive=E in config.sys? I want to think that was one hurdle I had with drdos.
Click to expand...

I tried setting at several levels all the way up to Z, no dice.

The MTCP tools seem to work fine, and the DOS NFS client "xfs"... kind of works, I made another post about that, but etherdfs isn't liking it at all. Ironically it's behaving exactly like the mirror image of xfs under PC-DOS 7. (IE, under DOS 7 xfs would claim to mount a drive but I'd get invalid drive specification trying to dir it. It seems like I was able to fix that with setver, however.)
 
I verified it IS still working for me; I had upgraded my raspberry pi 3 in my little mac portable system to a 4. I'm using the :: c-d syntax, it just works fine.

screen.JPG

Are you sure your server and client version match?
 
keenerb said:
Are you sure your server and client version match?
Click to expand...

Pretty sure, and they do work under PC-DOS...

Hrm. I do see, though, that you're running Caldara DOS 7, not DR-DOS 6. Maybe that's the key? I was a little concerned from some of the slight amount of research I did before getting a bug in my bonnet to try dual-booting DR-DOS that version 7 might not be apropos for an XT. Maybe I should try seven and see if it works on a machine as humble as mine.

So far I'm kind of torn what I think of DR-DOS. I'm kind of impressed that just one line of HIDOS.SYS gave me almost as much free memory as a lot of painstaking pain-in-the-butt-ery with USE!UMBS and DOSMAX, and TASKMAX might very possibly be useful, but there are times where it's oddly slow compared to the Microsoft/IBM flavor.
 
Yeah it's the last DOS I used before Windows made it irrelevant. I use the task switcher fairly often actually...
 
I've been playing with the version 6 version a little and it's sure a heck of a lot better than that pathetic excuse MS/PC-DOS come with. (Which doesn't even work on Tandy 1000s, actually.) I enabled swapping to my one meg of EMS and it can task-switch *pretty darn fast*, but of course it can't actually multitask. Even swapped PC Painbrush configured for a CGA mode fine, but the results were of course predictable when I tried the same program configured for a Tandy 16 color mode.

Guess I'll see if I can upgrade to 7 and try etherdfs on that.
 
Stick it all on a floppy disk, no reason to re-install completely!

I have an Apple II emulator card in my 1000tl; it's actually the best "multitasker" I've had the pleasure of using. I will run Bard's Tale on the Apple II and just alt-esc back over to my dos screen and the dos app is even still running. It's pretty nifty.
 
I found an "installable from a directory" distribution of Caldara DOS 7.0.3 and went ahead and installed that over 6.0. Took nearly two hours start to finish but it did complete...

And EtherDFS does work under it. So, yeah, DR-DOS 6 problem.
 
Last edited:
You must log in or register to reply here.
Back
Top