fTelnet

There's been a couple noteworthy changes in the last year, which I've neglected to mention!

The most recent is really recent (as in a few days ago), and is a fix for YModem-G transfers.  The public proxies had a couple bugs that needed fixing, and now that they're sorted, transfers are working again.

While testing the changes, I noticed the transfers were pretty slow at around 20KB/s or so, so I also made some additional tweaks to fTelnet, fTelnetProxy, and Synchronet's websocketservice.js to speed things up.  If I remember correctly the fastest transfer I saw after all the changes was around 3MB/s, which is still pretty slow in the grand scheme of things, but a 150x speedup isn't too bad at all.

Another older change is related to how the user's IP address is reported, if the BBS requests it.  Previously both SEND-LOCATION and TTYLOC were supported, but since TTYLOC doesn't allow sending an IPv6 address, support for that was disabled.  This means your BBS will now need to use SEND-LOCATION to request the user's IP address, if it isn't already.

And the oldest changes from November of last year are actually pretty cool, so I should have mentioned them sooner!  fTelnet now has mouse support, if the BBS requests it, so for example in Synchronet you can click on menu options instead of hitting hotkeys!  A new screen size dropdown was added to the menu as well, allowing users to select a larger screen.  Both of these changes were made to improve the Synchronet Minesweeper experience, but hopefully will be useful elsewhere as well.

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:

https://play.google.com/apps/testing/com.randm.ftelnet

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