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!)

I recently received an email asking how to use fTelnet from behind a corporate firewall.  Since ports 1123 and 11235 are non-standard ports that I just picked because of their slight resemblance to telnet's port 23 (and also because they're the start of the Fibonacci sequence), they're going to be considered unknown ports and get blocked by some corporate firewalls.

To get around this, I've moved many of my public proxies from ports 1123 and 11235 to ports 80 and 443.  These are standard HTTP and HTTPS ports, so have a much greater chance of passing through a corporate firewall.  (If they're really nosy they could use DPI to see that the connections over port 80 are not really HTML and block on those grounds, but since 443 is encrypted I don't think there's anything they can do to block that without also blocking legitimate HTTPS traffic...not a firewall/network expert though, so I could be wrong).

I'll leave ports 1123 and 11235 active indefinitely, but if you're using one of my proxies, and you want the greatest level of connectivity to your BBS, you should really consider updating the port numbers to 80 and 443 instead.

The reason I moved "many" instead of "all" is because some of my proxies don't have a dedicated IPv4 address, so I don't have control over what ports I can use.  Currently this is proxy-au and proxy-us-tx, so they have to stay at whatever ports they are currently using.  I'd like to replace them at some point to standardize everything, but I haven't found any great deals in those regions yet so we're stuck with them for awhile.

If you're using the embedded version of fTelnet, you should notice that I just pushed some new changes.  If you're not using the embedded version, these are changes worth upgrading for!

Here's a list of what's new:

  • Updated virtual keyboard layout (slightly more compact, allowing for slightly larger keys)
  • Virtual keyboard will show on mobile and hide on non-mobile by default
  • Virtual keyboard is WAY more responsive on iOS (and possibly other mobile) devices
  • Replace ugly looking Connect/Upload/Download/etc links at top of client area with a pop-up menu on the status bar
  • Non-mobile has a new, much more user friendly scrollback buffer.  Mobile devices I tested didn't have the horsepower needed to support this feature, so they still have the clunky scrollback buffer
  • Non-mobile also has copy/paste support!  Every browser supports this a little differently, so it works a bit different in each.  In time I think they'll all support seamless copy/paste (ie no pop-ups like you currently see in Firefox)

If you run into any problems with this new release, please use the Contact link to let me know!

It's been about a year since I setup the first proxies, so it's time for renewal for some of them, and I'm going to be shaking things up as a result:

  • proxy-jp will be going away. It had great uptime, but was hardly ever used, so might as well invest in other locations that will see more traffic.
  • proxy-nl will be replaced. It has the second-worst uptime, so there's no point wasting money on it. I'll be ordering a RamNode server in the near future -- their USA locations are amazing, hopefully the NL location will be as well.
  • proxy-uk will be going away. By far it has the worst uptime, and it's probably close enough to proxy-nl or proxy-fr to not bother finding a replacement.

All three of the old hostname/port combinations will continue to work, but the connections will be routed via the new proxy-nl server.  This is ideal for the old proxy-nl and should be pretty good for the old proxy-uk, but proxy-jp users (if there were any) might want to update their settings to use proxy-au instead.

1 2 3 4 5 6 7 8 9 >
Get it on Google Play Download on the App Store
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!