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.

I've removed proxy-ca-on from the list of proxies, as I've found another use for the box it's running on.

From the logs I can see it wasn't used too much, but to avoid breaking things for the few people that were using it I've updated the hostname to point to the IP of the next closest box, which is proxy-us-nj (when I tested my ping times at proxy.ftelnet.ca it was only about 20ms slower, which isn't bad considering it's about 7x further away from me than proxy-ca-on was).

LowEndSpirit got stock back in their Dallas, TX location, so I've added a proxy there since it's so cheap. 

I think that's the last one I'll be adding, until someone requests an additional area to be covered.  LowEndSpirit is the best deal for these proxies, and while I don't have a proxy in every city they offer, I do have a proxy in every general area (ie have one in UK, France and NL, so unless somone says they're not good enough I won't bother with their Germany and Italy locations).

And I just mentioned the fTelnet Proxies page in my last post, but this map is cool and worth a separate mention:

Check out the fTelnet Proxies map here.

I had a VPS idling in Toronto, Ontario, so I figured I'd re-provision it and get it up and running with FleckProxy!  So the first Canadian proxy is now online at proxy-ca-on.ftelnet.ca!

I've also created a website for listing the (now 10) proxies, which contains uptime statistics provided by Uptime Robot, and a "ping" test to let you know which one is likely to give you the best performance.  I put ping in quotes because it isn't a true ping, it's actually a measure of how long it took to establish a WebSocket connection, which will be 10s to 100s of milliseconds longer than it would take for a standard ping reply.  So use the value more as a comparator than a performance indicator.

Check out the fTelnet Proxies list here.

I just finished updating My fTelnet with a few changes.

First, and most importantly, I finally implemented the ability to add your own entries to the address book.  Previously you were limited to my default entries, which was kind of pointless!

Second, I've moved the client connection out of the main window and into a popup window (or new tab, depending on your browser settings).  This makes it so you can load multiple connections at once, and also simplifies my life because I can re-use the work I put into the embedded version of fTelnet.

Click here to check it out now!

Someone on DOVE-Net recently mentioned they liked the RIP support in the old fTelnet, but one day it stopped working (I fixed the problem after that, so it should be working again).

This made me think about all the effort that went into adding support for RIP (it was probably close to as much effort as all the other features combined...and that's only for partial support, full support likely would require more effort than all the other features combined), and what a waste it would be since I'm not supporting the old fTelnet anymore. 

But ActionScript and TypeScript/JavaScript are pretty similar languages, so I figured it probably wouldn't be too difficult to take the RIP support out of the old fTelnet and transplant it into the new fTelnet.  And it turns out it wasn't!  The screenshot below shows the experimental RIP support in the new fTelnet:


It's only partially ported, there are a few things I skipped to get it up and running, and then of course the original code wasn't a full implementation to begin with, so it's not ready for prime time.  But a small number of the RIP screens from the sixteen colors archive render quite nicely, feel free to log into my demo system and check them out for yourself.

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