darry wrote on 2022-02-01, 02:34:

DosFreak wrote on 2022-02-01, 00:33:

TrueNAS with latest updates still working fine for 3.51/95+ (Tested) but it's just a matter of time. Yes FTP or SFTP can be use […]
Show full quote

TrueNAS with latest updates still working fine for 3.51/95+ (Tested) but it's just a matter of time. Yes FTP or SFTP can be used but it's so inconvenient.

I did run into this awhile back, haven't had a chance to look at it:
Possibility of SMB2/3 on 9x-NT3-4x?

Another option that wouldn't require anything on the client would be an SMB proxy. Intent would be to strip everything not needed from SMB except for what's needed to send and receive the traffic. Since proxies are needed for web traffic for these VMs then would make sense to add that functionality in. Heck, add a cache in there to make it even more useful. Of course you can't forget about NetBIOS so if that is removed then that would need to be setup as well.

I'm confused by https://download.samba.org/pub/samba/rc/samba … c1.WHATSNEW.txt

This only affects clients using MS-DOS based versions of SMB1, the last release of which was Windows 98

That is so poorly worded.
Did they forget that MS-DOS exists in Windows 98SE or Windows ME?
What about versions of DOS that don't come with Windows, they do know DOS existed before Windows right?
Are they talking about LANMAN and not NTLM so networking in Windows in 9x,3.51,NT4 are unaffected?
Thinking anything <= NT 3.50 would be affected. Don't have my 3.50 VM setup yet (working on it!) so can't verify but I know 3.51 works.

Either a container or a VM running an older Samba version will likely be my preferred solution when SMB1 sunsetting in Samba comes to pass .

@DosFreak

I have Samba 4.13 running on Debian 11.2 and Windows 98 SE can no longer connect to shares unless I specify

1server min protocol = NT1

which allows it to work fine .

Since 4.16 removes functionality from SMB1 CORE and LANMAN1 , AFAIU, this probably means that whatever can work with NT1 as a minimum is probably safe for now .

Yeah it makes you wonder how difficult it really would be to get SMB2/3 working on DOS,9x,NT3.x/NT4/XP/2003.

The MS Net Client 3.0 is lanman only but you could even set it up as a server with an additional update.
Of course with NIC drivers and TSR in DOS you're better off using FTP instead of SMB anyway but for Windows it would be more beneficial.

If SMB2/3 isn't a possibility then a FTP/SFTP server/client that works across all operating systems would be nice instead of having to hunt down different versions of clients.

DOS
mtcp

WinSCP
95-NT4 v4.19
98-ME v4.40
2000 v5.18
XP+ v5.15.4

I did add the repo so will take a look once I get my VMs done
https://github.com/vogonsorg/winscp

I think if running an old version of Samba isn't an option then Mars-NWE is perhaps a better alternative than WinSCP or FTP. It gives you mapped network drives just like SMB does with the added benefit of using vastly less conventional memory on DOS than the Microsoft LanMan/SMB client. Windows 9x and NT have a (rather basic) client on the CD and the proper client is pretty easy to install too.

There are other more basic SMB server implementations out there as well - perhaps one of them might be a workable solution.

Now I'm also wondering, what specs are needed ideally for the Debian x86 version, to have best performance with PS3 games, X360, or whichever platforms tend to be most demanding? I've got a couple SB/IVB i5 towers that might be well-suited, although ideally I'd like to keep them as overkill WinXP / pretty good Win7 gaming desktops. Would a Core 2 or Phenom II (with USB 3 addon card), or maybe laptop i3/i5 get the job done? How much RAM and local storage (to boot the Debian VM, not the big RetroNAS drive) would be needed for best results?

Edit: I probably should have specified, how much CPU/RAM/Storage do I need to devote to the Debian VM itself? Because even if I'm told "Core 2 Quad is enough," I still don't know whether the VM needs more than one core for best performance...

For Debian the recommended minimum RAM is 128MB without a GUI but it will work with as little as 60MB on an a 64bit PC. At least 2GB of disk is recommended but no harm in giving it more - perhaps 10GB if you've got the disk space. For x86 you need at least a Pentium II or better (the original Pentium and older chips aren't supported).

If you're installing Debian without a GUI then one core and 512MB of RAM should be plenty - this is all I ended up giving my public FTP server. My web server has 1GB of RAM and two cores (serving static content - no fancy CRMs or anything). 10GB disks on both for the boot drive. No harm in giving it more RAM of course - it will just use the excess as disk cache.

I think you'd probably find a Raspberry Pi as suggested in the initial post would do just fine too and use a lot less electricity than the PCs you've got lying around. The Raspberry Pi 4 has gigabit ethernet and USB3 and you can get it with 1-8GB of RAM. An older Raspberry Pi 2 or 3 (1GB RAM, slower CPU) would probably do just fine as well if you've got one lying around - they just won't have USB3 or gigabit ethernet.

Deku_Scrub wrote on 2022-02-02, 20:35:

Now I'm also wondering, what specs are needed ideally for the Debian x86 version, to have best performance with PS3 games, X360, or whichever platforms tend to be most demanding? I've got a couple SB/IVB i5 towers that might be well-suited, although ideally I'd like to keep them as overkill WinXP / pretty good Win7 gaming desktops. Would a Core 2 or Phenom II (with USB 3 addon card), or maybe laptop i3/i5 get the job done? How much RAM and local storage (to boot the Debian VM, not the big RetroNAS drive) would be needed for best results?

Edit: I probably should have specified, how much CPU/RAM/Storage do I need to devote to the Debian VM itself? Because even if I'm told "Core 2 Quad is enough," I still don't know whether the VM needs more than one core for best performance...

If you check the wiki attached to the project page, I try to put numbers in those (also the instructional videos I do network monitoring to show the usage).

For PS2, things never really spike much over 10Mbit/s from the limited testing I did. If you dabble with emulators you'll probably be aware that some fussier games can crash if virtual optical drives read too fast. Often the tools used to simulate optical drives are slowed down to genuine drive speed to ensure stability. By spec the console's 4x DVD drive can read at a maximum speed of around 5MB/s / 50Mbit/s, but rarely gets there in practice. Certainly when streaming video and audio, it's quite a deal less.

PS3 I saw get to 400Mbit/s when installing Skyrim to the PS3's internal HDD (mandatory for that game), likely bottlenecked by the very slow spindle disk I have in my PS3 (I'd like to re-test with an SSD, and see how fast that can go on the PS3's internal SATA1 port capped at 1.5Gbit/s). During regular game loading of other titles that didn't HDD install, speeds of around 200Mbit/s were common. The hardware's internal optical drive caps out at a very low 72Mbit/s (around 8MB/s), so network game loading becomes substantially faster there, and games are less crash-prone as they are deigned to work fine off the internal hard disk as well for digital titles.

So what do you need performance wise? A stock RPi4 is a quad-core 1.5GHz ARM CPU. I'd guestimate somewhere in the order of a hypothetical Intel Core 2 Quad at about 1GHz (depends on what features you're talking about, but that's ballpark). RAM wise it depends on the number of services you're loading up, but 2GB for a GUI-less system would probably even be OK.

Your biggest bottleneck is IO, with the RPi3 being a bit garbage because of everything attached to the USB2 bus (storage and network). RPi4 really wins out here with a dedicated 1GbE network card and USB3 for storage, when combined can happily hit 900Mbit/s or more from my testing. On an old PC you've got the benefit of PCIE attached devices and SATA2+ depending on hardware. Total overkill for a lowly PS2/PS3 device.

I haven't put any time into testing XBox360 yet, but its 12X DVD caps out at 16.5MB/s or around 170ish Mbit/s, which again is miles under what most GbE NICs and even large spindle drives can deliver, so I suspect it's a similar story.

Same on the computer side. SMB1 will probably blast down the line at speeds your Win95 box can only dream of even on low spec hardware. EtherDFS is an interesting beast because of how unique it is, but several kind volunteers have provided benchmarks on real hardware (check the github wiki for numbers).

VM wise, I always recommend 2 CPUs minimum. 1 CPU bottlenecks on IO wait in Linux systems, and given that this is a NAS, having 2 CPUs for your VM is a good idea. That doesn't mean it's going to use 100% of 2 CPUs all day long. Just that the way that CPU and IO scheduling in Linux works, it is easier for it to walk and chew gum in that configuration, and latencies drop quite a bit.

davidrg wrote on 2022-02-02, 22:20:

I think you'd probably find a Raspberry Pi as suggested in the initial post would do just fine too and use a lot less electricity than the PCs

Definitely a big incentive for RPi hardware. An RPi4 struggles to consume 5W, compared to say the 65W of a Core2Duo.

elvis wrote on 2022-01-31, 05:53:

But I figure audiences like VOGONS are more than well versed in managing old computers inside modern networks, and don't need lecturing about that.

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve? Anyone? I never bothered to put mine on, precisely because 'security'. Networking has never been my interest. Until I see awesome projects like this...

I hope this can be addressed sometime, because I see it as your biggest gatekeeper. I know you don't - super network sysadmin pro for decades that you are. But think about this, since I know you and Pierre : I have witnessed Pierre himself learning about putting his retro machines on the network just in the past couple of years. And if he himself, now your champion here, was in that position of very much needing lecturing about managing old computers in modern networks such a short time ago, then perhaps you can safely assume the same level of existing networking knowledge from the general retro population as well. We know the basic concepts but once an OS goes EoL it's simply been "airgap forever", and don't think about it again in networking terms.... (Again - until project like this come up.)

And (as exampled by the below post), those who are already networking their retro gear, probably also have their own functionality solutions in place, because the two kinda go hand-in-hand. In summary, I'm pretty sure a big chunk of people this is (potentially) aimed at will also need accompanying information about how to set the network up to use it.

Doesn't have anything to do with RetroNAS but TrueNAS released their latest update recently, looks like still on 4.13.17 for TrueNAS 12 and 4.15.5 for TrueNAS 13 so safe for awhile yet.
https://www.truenas.com/docs/releasenotes/core/12.0u8/
https://www.truenas.com/community/threads/tru … 0-begins.97292/

Think if/when support is dropped then solution for me assuming nothing better are available then will be a bhyve VM in FreeNAS with a Linux distro that still supports SMB1 to redirect to my FreeNAS share. Since security is a concern then hopefully that Linux distro will still receive updates for quite awhile which will provide time for a possibly better solution.

Shreddoc wrote on 2022-02-04, 01:35:

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve?

Future plans are to use RetroNAS as a firewall of sorts. The current idea is:

RetroNAS will run dnsmasq (small DNS/DHCP tool) on the device itself, to configure all IP level stuff into a separate network. User then defines their modern and retro network interfaces, firewall scripts run to optionally allow retro computers to get out to the Internet (that'll be a yes/no question), but not allow them to see your modern network.

Likewise the modern network can get to the RetroNAS device itself, but not to machines sitting behind it. That then at least network-isolates the two sides, but allows RetroNAS to serve as a file drop in the middle. So a scenario like "download a file from archive.org/github/whatever on your modern computer, put it on RetroNAS, walk to old computer and it's waiting on the network mount" works somewhat securely.

Still in planning phases, but that's the goal. I've got a few other things to get through first as there's been a huge feature request list come in this week.

In general good news, I picked up a contributor who's already doing amazing things. "tcpser" is a tool I'd never heard of, and turns your RetroNAS into a Hayes-compatible dialler. You can't get full Internet browsing (pppd and DreamPi will do that eventually, I'll try and work on both soon), but you can use it to connect to public Internet/IP-based BBSes via ADT commands from loads of old computers (DOS, C64, Amiga, etc). He's working on that and sent me some screenshots of it in action, looks really cool.

Some nice additions in the pipeline. I was typing up my two cents for Shreddoc in the meantime. Here they are:

Shreddoc wrote on 2022-02-04, 01:35:

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve? Anyone? I never bothered […]
Show full quote

elvis wrote on 2022-01-31, 05:53:

But I figure audiences like VOGONS are more than well versed in managing old computers inside modern networks, and don't need lecturing about that.

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve? Anyone? I never bothered to put mine on, precisely because 'security'. Networking has never been my interest. Until I see awesome projects like this...

I hope this can be addressed sometime, because I see it as your biggest gatekeeper. I know you don't - super network sysadmin pro for decades that you are. But think about this, since I know you and Pierre : I have witnessed Pierre himself learning about putting his retro machines on the network just in the past couple of years. And if he himself, now your champion here, was in that position of very much needing lecturing about managing old computers in modern networks such a short time ago, then perhaps you can safely assume the same level of existing networking knowledge from the general retro population as well. We know the basic concepts but once an OS goes EoL it's simply been "airgap forever", and don't think about it again in networking terms.... (Again - until project like this come up.)

And (as exampled by the below post), those who are already networking their retro gear, probably also have their own functionality solutions in place, because the two kinda go hand-in-hand. In summary, I'm pretty sure a big chunk of people this is (potentially) aimed at will also need accompanying information about how to set the network up to use it.

Yep I have learned a lot, and now I know just enough to be dangerous. My take is that there are two primary security concerns when connecting your retro machines to your home network, outlined below. These concerns are largely alleviated by running a NAS with dual network interfaces, effectively putting your modern & retro stuff on separate networks that can access the same storage. (The addition of dnsmasq planned by elvis will achieve much the same if using a single interface.)

A Raspberry Pi 4 offers two interfaces - you can connect your retro gear to the ethernet port, and manage the server over wifi from your modern machine. That's my current setup. An old desktop or laptop repurposed as your NAS will likely offer both interfaces too. You just need to set those up on the initial Linux install. For example, my modern network runs on 10.104.x.x so the wifi gets one of those addresses. The ethernet port gets 192.168.1.1

Exposing your modern machine to old network protocols

Later versions of Windows disable things like SMB1 for a reason. There are guides out there to re-enable it, but you shouldn't, and the good news is you don't have to. When you connect a machine to RetroNAS, it will automatically use the version appropriate for your OS:

Samba supports numerous clients, and RetroNAS configures Samba to dynamically support the oldest versions of the protocol right through to newer versions. This happens automatically when the client asks to connect to the Samba server, and the protocol versions are negotiated.

https://github.com/danmons/retronas/wiki/Samba

Exposing your retro machines to the internet

Views on this range from "The sky will fall" to "Meh, it's an obscure target these days, hold my beer." I err on the side of caution by simply not entering a gateway when configuring the IP address on an old machine. If you're running a NAS with dual network interfaces, the problem is even more solved because the retro machine can't see the modern network.

But if you want to browse the web from a retro rig on this setup, you still can with WebOne. I trialled this yesterday, and out of the box it allowed me to do a bit of retro web browsing. So you can have your cake and very carefully eat it too.

https://github.com/danmons/retronas/wiki/WebOne
WebOne - proxy for old browsers to make them Web 2.0-capable

Shreddoc wrote on 2022-02-04, 01:35:

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve? Anyone? I never bothered […]
Show full quote

elvis wrote on 2022-01-31, 05:53:

But I figure audiences like VOGONS are more than well versed in managing old computers inside modern networks, and don't need lecturing about that.

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve? Anyone? I never bothered to put mine on, precisely because 'security'. Networking has never been my interest. Until I see awesome projects like this...

I hope this can be addressed sometime, because I see it as your biggest gatekeeper. I know you don't - super network sysadmin pro for decades that you are. But think about this, since I know you and Pierre : I have witnessed Pierre himself learning about putting his retro machines on the network just in the past couple of years. And if he himself, now your champion here, was in that position of very much needing lecturing about managing old computers in modern networks such a short time ago, then perhaps you can safely assume the same level of existing networking knowledge from the general retro population as well. We know the basic concepts but once an OS goes EoL it's simply been "airgap forever", and don't think about it again in networking terms.... (Again - until project like this come up.)

And (as exampled by the below post), those who are already networking their retro gear, probably also have their own functionality solutions in place, because the two kinda go hand-in-hand. In summary, I'm pretty sure a big chunk of people this is (potentially) aimed at will also need accompanying information about how to set the network up to use it.

For me, I've at times considered shifting my retro systems onto a different VLAN but so far have not bothered. I trust my router/firewall (not a garbage home-grade thing that came free from my ISP) to be relatively secure and as long as I don't forward ports to anything insecure I should be fine.

And really as long as no ports are forwarded to my vintage systems they are basically invisible to the internet. The only way someone could break into them is if they were already past my firewall in which case I've really got bigger problems than some Windows 98 machine being hacked.

A lot of my older vintage systems also don't speak TCP/IP at all. I use NetWare for network drives and that all runs over IPX which isn't internet routable. So if an OS doesn't come with TCP/IP installed by default (eg, DOS/Windows 3.11/95) it won't have an IP address. This makes the machine pretty much invisible even to an attacker who is already past my firewall - nmap won't see a DOS machine speaking IPX. I guess an attacker would have to reconfigure a switch and run something like wireshark to even know the DOS machine is there.

So while this stuff all has abysmal security a bot or a worm isn't going to see it unless you forward a port to it and hackers probably have more worthwhile targets than a windows 98 machine that's behind a firewall. Just in case though, I don't store important stuff on insecure machines.

One scenario I ponder is a threat making its way from 9x to Win10 via the server. Say I've unpacked a dodgy game patch, or been drive-by'd while browsing over WebOne. I suppose it's possible that something nasty could be written to the network share, exposing it to Win10. I don't know if that's enough of a threat vector to spend too much time thinking about.

That's just the internet for you. Retro or modern, the good practices are the same. Use trusted sites and keep your client security up to date.

Pierre32 wrote on 2022-02-05, 00:34:

One scenario I ponder is a threat making its way from 9x to Win10 via the server. Say I've unpacked a dodgy game patch, or been drive-by'd while browsing over WebOne. I suppose it's possible that something nasty could be written to the network share, exposing it to Win10. I don't know if that's enough of a threat vector to spend too much time thinking about.

That's just the internet for you. Retro or modern, the good practices are the same. Use trusted sites and keep your client security up to date.

Yeah, thats something I've thought about too. Dig some old floppy disk out and accidentally unleash some antique virus on my network.

So far I've not had it happen (at least not in the last 15 years) and I hope that whatever virus scanner comes with windows 10 would catch it if it did. For added safety most of the Samba shares are read-only (and the rest require a password which I wouldn't use on a vintage system) and that entire server is RSYNCd nightly to a NAS which also takes snapshots - my main concern there though wasn't vintage systems but ransomware.

Probably in the near future now that I know Mars NWE works I'll remove the ability for vintage systems to talk to the Samba server (by turning its security settings up a few notches). Instead I'll export a few things to a Raspberry Pi via NFS and re-share that using Mars NWE to the vintage systems. Mars NWE is most certainly less secure than Samba but if Mars NWE only has read-only access to everything it won't be able to do much damage if its compromised or if a virus on a DOS PC tries to make a mess.

elvis wrote on 2022-02-04, 22:41:

Future plans are to use RetroNAS as a firewall of sorts. The current idea is: […]
Show full quote

Shreddoc wrote on 2022-02-04, 01:35:

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve?

Future plans are to use RetroNAS as a firewall of sorts. The current idea is:

RetroNAS will run dnsmasq (small DNS/DHCP tool) on the device itself, to configure all IP level stuff into a separate network. User then defines their modern and retro network interfaces, firewall scripts run to optionally allow retro computers to get out to the Internet (that'll be a yes/no question), but not allow them to see your modern network.

Likewise the modern network can get to the RetroNAS device itself, but not to machines sitting behind it. That then at least network-isolates the two sides, but allows RetroNAS to serve as a file drop in the middle. So a scenario like "download a file from archive.org/github/whatever on your modern computer, put it on RetroNAS, walk to old computer and it's waiting on the network mount" works somewhat securely.

Sounds rad. e.g. RetroNAS-on-Pi4 in the middle, separating a little LAN switch (or whatever) for the retro connections on one side, and wireless to the modern network on the other side. Or equivalent. Doesn't sound too complex (for the user).

Pierre32 wrote on 2022-02-04, 23:07:

Some nice additions in the pipeline. I was typing up my two cents for Shreddoc in the meantime. Here they are: […]
Show full quote

Some nice additions in the pipeline. I was typing up my two cents for Shreddoc in the meantime. Here they are:

Shreddoc wrote on 2022-02-04, 01:35:

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve? Anyone? I never bothered […]
Show full quote

elvis wrote on 2022-01-31, 05:53:

But I figure audiences like VOGONS are more than well versed in managing old computers inside modern networks, and don't need lecturing about that.

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve? Anyone? I never bothered to put mine on, precisely because 'security'. Networking has never been my interest. Until I see awesome projects like this...

I hope this can be addressed sometime, because I see it as your biggest gatekeeper. I know you don't - super network sysadmin pro for decades that you are. But think about this, since I know you and Pierre : I have witnessed Pierre himself learning about putting his retro machines on the network just in the past couple of years. And if he himself, now your champion here, was in that position of very much needing lecturing about managing old computers in modern networks such a short time ago, then perhaps you can safely assume the same level of existing networking knowledge from the general retro population as well. We know the basic concepts but once an OS goes EoL it's simply been "airgap forever", and don't think about it again in networking terms.... (Again - until project like this come up.)

And (as exampled by the below post), those who are already networking their retro gear, probably also have their own functionality solutions in place, because the two kinda go hand-in-hand. In summary, I'm pretty sure a big chunk of people this is (potentially) aimed at will also need accompanying information about how to set the network up to use it.

Yep I have learned a lot, and now I know just enough to be dangerous. My take is that there are two primary security concerns when connecting your retro machines to your home network, outlined below. These concerns are largely alleviated by running a NAS with dual network interfaces, effectively putting your modern & retro stuff on separate networks that can access the same storage. (The addition of dnsmasq planned by elvis will achieve much the same if using a single interface.)

A Raspberry Pi 4 offers two interfaces - you can connect your retro gear to the ethernet port, and manage the server over wifi from your modern machine. That's my current setup. An old desktop or laptop repurposed as your NAS will likely offer both interfaces too. You just need to set those up on the initial Linux install. For example, my modern network runs on 10.104.x.x so the wifi gets one of those addresses. The ethernet port gets 192.168.1.1

Exposing your modern machine to old network protocols

Later versions of Windows disable things like SMB1 for a reason. There are guides out there to re-enable it, but you shouldn't, and the good news is you don't have to. When you connect a machine to RetroNAS, it will automatically use the version appropriate for your OS:

Samba supports numerous clients, and RetroNAS configures Samba to dynamically support the oldest versions of the protocol right through to newer versions. This happens automatically when the client asks to connect to the Samba server, and the protocol versions are negotiated.

https://github.com/danmons/retronas/wiki/Samba

Exposing your retro machines to the internet

Views on this range from "The sky will fall" to "Meh, it's an obscure target these days, hold my beer." I err on the side of caution by simply not entering a gateway when configuring the IP address on an old machine. If you're running a NAS with dual network interfaces, the problem is even more solved because the retro machine can't see the modern network.

But if you want to browse the web from a retro rig on this setup, you still can with WebOne. I trialled this yesterday, and out of the box it allowed me to do a bit of retro web browsing. So you can have your cake and very carefully eat it too.

https://github.com/danmons/retronas/wiki/WebOne
WebOne - proxy for old browsers to make them Web 2.0-capable

Many thanks. I learned some things, and filed some away for further digestion.

I don't think I'd personally expose retro machines to internet. Unless there was a pretty good reason.

Referencing the last few posts, they do echo my own vague fears - Of somehow opening up complex multi-stage attack vectors.

But I suppose that need not be the case, provided all the appropriate doors are firmly closed. And I can see how the dual interface, and/or elvis's above-proposed software solution, can in theory cleanly achieve that.

Pierre32 wrote on 2022-02-05, 00:34:

One scenario I ponder is a threat making its way from 9x to Win10 via the server. Say I've unpacked a dodgy game patch, or been drive-by'd while browsing over WebOne. I suppose it's possible that something nasty could be written to the network share, exposing it to Win10. I don't know if that's enough of a threat vector to spend too much time thinking about.

That's just the internet for you. Retro or modern, the good practices are the same. Use trusted sites and keep your client security up to date.

Definitely a concern. I saw a chat on a forum recently where someone discovered some old Atari ST viruses sitting on files on archive.org that modern virus scanners don't even pick up!

With that said, I can add ClamAV to RetroNAS:
https://www.clamav.net/

Would be pretty simple to throw in a menu item to do a folder scan on demand. You can also scan it via SMB from your PC too.

Again, not anything specific to RetroNAS. Even running WinXP in a VM with a network NAT out through your home network puts you at similar risk levels.

Shreddoc wrote on 2022-02-05, 02:15:

I don't think I'd personally expose retro machines to internet. Unless there was a pretty good reason.

You can use Rclone to mount cloud storage on RetroNAS and then expose that back to your retro computers.

https://rclone.org/

Imagine keeping all your Win9X files on OneDrive/GDrive and accessing them via the cloud. 😀

Shreddoc wrote on 2022-02-05, 02:15:

Referencing the last few posts, they do echo my own vague fears - Of somehow opening up complex multi-stage attack vectors.

But I suppose that need not be the case, provided all the appropriate doors are firmly closed. And I can see how the dual interface, and/or elvis's above-proposed software solution, can in theory cleanly achieve that.

James Mickens wrote a funny article that touches on this subject.

If you're not a valuable target and don't have enemies with a particular set of skills then as long as internet facing things are secure (your router and anything you've forwarded ports to) and up-to-date, you use good passwords, and you can't delete important files from your vintage machines, you'll be fine.

A feature request came in for TNFS, which according to the documentation is a very small, very lightweight network file system compatible with Atari 8-bit and ZX spectrum computers.

I don't have either system, nor the "Fujinet" hardware that appears to be necessary to use it. If any kind VOGONS member has the hardware and the inclination to test, I'd be very appreciative.

Wiki page for the protocol is here:
https://github.com/danmons/retronas/wiki/TNFS

Very sparse at the moment, again because I can't test. However the code compiles and installs, and successfully listens on the TCP and UDP ports listed.

Very excited to have Sairuk on board as co-maintainer now. He brings a boatload of experience as well as far better coding skills than mine. He's run this site for ages:
https://mameau.com/

And has added TCPser support in to RetroNAS, to convert your device into a Hayes compatible virtual modem, and get old computers that can do standard "ATD" style commands connecting to IP based BBSes:
https://github.com/danmons/retronas/wiki/tcpser

elvis wrote on 2022-02-11, 04:01:

And has added TCPser support in to RetroNAS, to convert your device into a Hayes compatible virtual modem, and get old computers that can do standard "ATD" style commands connecting to IP based BBSes:
https://github.com/danmons/retronas/wiki/tcpser

Yay, I might finally have a use for all the PCI serial cards I hoarded 🤣 ... I could get maybe 8 serial machines hooked up to one server... though that might be on the pointless side, since I only have two hands and a swivel chair so 4 at once is plenty... and I own switchboxes too.

I wrote up a little thing demonstrating a scenario I've hit numerous times when transferring files via EtherDFS - and how to get around it using other available RetroNAS tools. Without moving one's lazy arse away from the DOS machine. It was originally drafted up as a forum post, but I decided to put it where I can include a lot more screenshots:

https://pierre32.medium.com/etherdfs-and-retr … ix-390eb9584c94

I've also been using TCPser to do some BBS browsing lately. I might write a post on that next.