Unfortunately that new provider I moved 3 of the 4 proxies to in July is shutting down the service I'm using, perhaps as early as tomorrow.  (Their host is using IPv4 exhaustion as an excuse to majorly jack up the cost of IPs, so it's nowhere near profitable for them to keep offering the service I'm using, so I don't blame them).

I found a good deal with another provider for the US East and West coasts, so am in the process of setting those up.  As of right now us-east has been setup, and I see connections coming in, so it looks like things are working well.

The AU and EU locations are a bit less common, so I don't have a replacement for them yet.  If my service is shut down before I do find a replacement, then unfortunately I'll need to redirect those requests to the US locations, which will significantly increase lag.  The provider that is shutting down the service I'm using may be bringing a new NAT-based service online in those locations, in which case I'll sign back up for that.

The main issue with a NAT-based service is that I'm given a small block of IPs that I can use, so the proxy can't run on the usual port 80 and 443 anymore, which in the past meant you would need to update your fTelnet configuration to specify the new ports.  But yesterday I updated fTelnet, along with the v2 embed wizard, to automatically update proxy configuration when the values you're using need correcting.  If you're already using the v2 embed wizard then you're good to go, but if you're self-hosting fTelnet then you'll need to manually update to the latest version, and if you're using the old embed wizard then you'll need to switch to the v2 embed wizard.

Sorry for any trouble this causes.  I didn't want/expect to be messing around with the proxies so soon again either!

EDIT: All four locations are back online, and are using the same ports as before, so no changes are needed on your end. That said, it is STRONGLY recommended that you update to the latest version of fTelnet (either by using the Embed Wizard v2, or if you self-host, by downloading the latest javascript from GitHub). That way, if I need to switch to a NAT-based service in the future, fTelnet will automatically detect a change in ports and you won't need to manually reconfigure anything.

Sorry if you've experienced problems with any of the proxies over the last few days.  I made some changes to allow connecting to IPv6-only systems, but on US-CA and US-NJ things weren't working correctly.  After seeing they were still running on Ubuntu 14.04 I thought I'd upgrade them to something more recent, which ended up fixing the IPv6 problem but then it introduced another problem because these are very low resource servers and Ubuntu 20.04 doesn't seem too happy with 64MB RAM.

So for the east coast I've found a new provider with a reasonably-priced 512MB server based in Virginia, and requests for the US-NJ proxy are now being redirected there.  Based on the usage I'm seeing on the various proxies, I will likely redirect US-GA there as well, and then have US-VA as the sole east cost proxy going forward.

Unfortunately that provider doesn't have a west coast option, so the temporary fix for US-CA is to redirect requests to US-WA, which has slightly more RAM (96MB) and doesn't seem to be crashing.  I'll look for another provider with something in the 256MB-512MB range as a more permanent solution.

The new provider does have an Australian location though, so I've switched to them for the AU proxy.  In theory the old provider worked fine, but because it didn't have a dedicated IPv4 address it means having to use different ports compared to all the other proxies, so this slightly simplifies things for me.

And lastly, they have a UK location, so at some point I'll probably start a server there and shut down the NL location.

fTelnetProxy was updated recently, so a restart is no longer needed when an SSL cert is renewed, which should help minimize downtime on the public proxies (sometimes I had to restart even though there were active connections).  It also supports switching to a non-root user after the port is bound, so you can run as a non-priviledged user on Linux.

Since I switched to Visual Studio 2022, I also had to update from .NET 4.5 to 4.6.2, which I believe means it will no longer work on XP.  But you probably shouldn't have been running a server on XP anymore anyway!

And for anybody using the Dallas, TX location, it is being shut down by the hosting provider due to it being an unprofitable location for them to operate in.  You shouldn't need to update your configurations though, I've already redirected the hostname to the Atlanta, GA location, which seemed to have the lowest ping time from Dallas.  This is bad news for anybody in the Dallas area, but good news if you're in the Seattle, WA area, as that's where they'll be migrating my VPS to, so there'll now be a proxy available in the pacific northwest.

If you're using one of my public proxy servers, you can ignore this message.

But if you're self-hosting an fTelnetProxy installation, then you'll need to download the latest binaries from GitHub to fix a TLS issue.  Firefox 74 has disabled TLS 1.0 and 1.1 by default, so this new fTelnetProxy release enables TLS 1.2 support to ensure Firefox users can still connect.

Unfortunately this required upgrading to the .NET framework version 4.5, which means if you don't already have that version of the framework installed you'll have to install it first. 

Which also unfortunately means XP is no longer supported, because as far as I know XP does not have an install for .NET 4.5.  So if you're using XP either stick to the old version and turn off https when serving the fTelnet client, or switch from self-hosted to one of my public proxies.

I've just pushed some changes to GitHub, and also to the v2 embed wizard, which will enable 24-bit Ansi support.

More info available on the PabloDraw blog.

fTelnet is now available as a native Android app!  Check out the beta here, and please let me know how it works:


Windows store should follow shortly, and I have plans for iOS too, but need to figure out how that will work since I don't have either a mac to develop with, or an iOS device to test with!

The new embed wizard I mentioned in my previous post is online (and has been for awhile but I never got around to posting here!), and can be accessed via http://embed-v2.ftelnet.ca. It still needs more testing so I'm not sure I would trust it on your live site yet, but it would definitely be helpful if you could try it out on a test page on your site and let me know if you run into any problems.  If you do use it on your live site, I strongly suggest you email me to let me know, as I don't consider it finalized yet and may end up making breaking changes to the embed code (not likely, but you never know), and I'll give a heads up to anybody that let's me know they're using it.

I have no plans to retire the original embedded version of fTelnet, so while testing of v2 would be much appreciated, there's no rush as you can stay using v1 for as long as you want.  I also have no plans to implement new features on v1 though, so at some point it may be in your best interest to move to v2.

And the proxy server fix I also mentioned in my last post seems to have done the trick...two of the servers have handled over 100,000 connections since I started them.  Of course that's mostly just port scanners looking for vulnerable DVR and security cameras to take over and use in DDoS attacks, and not actual users wanting to connect to a BBS.  Wouldn't it be cool if BBSes still had that many people connecting?!?

The proxy servers haven't been overly reliable lately...UptimeRobot is still able to ping the servers, so I don't get notifications that they're offline, but they're not accepting WebSocket connections so they really aren't doing their job.

I've just made a change to fTelnetProxy (which powers the proxies) that I'm hoping will address this problem.  If it doesn't fix it, I'll keep digging because I hate that they keep going offline for everyone!

Also, I've been working on fTelnet a bit lately.  It's bothered me for a long time that RIP support significantly adds to the size of the fTelnet .js file, to the point that I considered removing it.  I really would like to finish RIP support, or at least improve it to the point of being usable, so removing it didn't seem like a great option.  So instead I've reorganized the fTelnet project into multiple smaller projects.  This has allowed me to create 4 different versions of fTelnet that vary in features, and thus in size.  The smallest, which doesn't support RIP or YModem is down to just 140kB (current release is 263kB, so that's nearly half the size!)

I've also switched to non-static classes, which means you'll now be able to embed two (or more) client windows on the same webpage.  This is a feature that some people have asked for, and I know at least one organization hacked in support on their own, but now it'll be built right in.  This means a completely different way of using fTelnet though, so to ensure things don't break for existing embedded users I'll be creating a new "v2" embed method.

Which leads me to my final item: If you'd like to be notified of fTelnet updates, please use the contact form to send me a "subscribe" message.  I'll try to get a proper mailing list in place at some point, but for now I'll just keep a contact list in my email client (and will be sure to use BCC for any announcements I send, for your privacy!)

1 2 3 4 5 6 7 8 9 10 >
Donations for Rick Parrish of R&M Software

Like something you see here? Consider donating to keep development alive!

(Please note that donations are not tax-deductible for income tax purposes.)

Thank you!