Connecting to Wi-fi with an Ethernet-to-Wireless bridge

posted in: Hardware | 5

Being the glutton for punishment that I am, I decided to do some rearranging of things around the house recently. Apart from a computer that runs without a monitor, keyboard or mouse connected to it, I was planning on moving all my machines to another room. The only system that put a spanner in the works was my Raspberry Pi running RISC OS 5 – which of course doesn’t support wireless.

I initially tried out powerline adapters to allow my electric cabling in the home to pass connectivity around the house and into the spare room, where I could then plug it up to my Pi. For most people, this solution would probably work but I found that there was something about the cabling in my property that was causing traffic on my LAN to loop – this resulted in about 25% of all my traffic dropping out.

Running an Ethernet cable from my router through to the other room wasn’t a suitable option either as the ball and chain my significant other would hang me out to dry.

So I looked at getting my hands on a Wireless-to-Ethernet bridge. I wasn’t sure on what compatibility issues with RISC OS I was going to run into, so I thought I’d start out cheap with something that has reasonably good reviews on Amazon.

I went for the Vonets VAP11G-300, which is an all-in-one wireless extender and wireless-to-ethernet bridge. It’s coined as being compatible with games consoles and printers so I figured as the device wouldn’t require drivers to work, it was likely to work on RISC OS.

The device can be powered by an external power adaptor or you can plug its built-in USB cable into a computer. The back of the device has a sticker with its MAC address and configuration panel details for you to log in with.

After being plugged into the power and connected up to my Raspberry Pi via ethernet, it was just a case of opening up the adapter’s local IP address ( in a web browser and selecting my router’s Wi-fi network name from a dropdown list then entering the network password. (Edit: It looks like accessing the configuration page on RISC OS doesn’t work for everyone, your mileage may vary. Use a non-RISC OS computer to setup the network before switching the device back onto RISC OS if needed.)

Then I ran !Boot and went into the Network configuration section to set the Pi’s IP address to and set the gateway and DNS server to Setting the network configuration as Manual works best as selecting DHCP will most likely give a Gateway error.

Once that was done, RISC OS on my Pi was running on my Internet connection without a hitch, and I found it to be pretty reliable considering how inexpensive the device was (£15 on Amazon). I’ve had no issues with it located upstairs and my router being downstairs, although the signal strength does show at about 50% in the configuration webpage, which leads me to believe that if the distance was any larger between it and the router then I might have encountered problems.

All in all, if you’re looking to connect your RISC OS system to a Wi-fi network, this is a decent, cost-effective option.

Under the Microscope: Island of the Undead

posted in: Games | 0

An original first-person shooter for RISC OS is definitely a rarity, the last one I can think of is the woeful Destiny many moons ago.

Fortunately, Amcog Games’ The Island of the Undead seems to have a lot more going for it.

Officially unveiled at the Wakefield show back in April and released a few months later, The Island of the Undead is a retro first-person shooter written using the Amcog Games Development kit as well as a new 3D engine. The game is a commercial release and is available for purchase for £11.99.

The plot

The game is based around the protagonist finding themselves alone on an abandoned military base after being forced to land a plane on a seemingly deserted island due to lack of fuel caused by a fuel leak.

While searching for fuel, a notebook is found with a number of eery scribblings in them, written by the last person on the island. An experimental virus that was initially meant to extend life began killing test subjects before reincarnating them in zombie form. Oo-er.

So naturally, your aim is to find some fuel and bugger off of that island post-haste, but the zombies don’t intend on making it that easy…

The game itself

Island of the Undead is displayed in retro-styled 3D vector graphics and features five original music tracks, 360 degree movement and the quite handy addition of level codes – so you can jump straight back onto a level you were playing before without having to start from scratch again. As always with an Amcog game, sound effects are supplied by their very own RDSP sound module.

A nice feature of the game is a built-in map in the right corner along with a counter that keeps track of your score, ammunition, health and the amount of fuel you’re still to acquire before you can get in your plane and bugger off home.

Source code and level design are also included for everyone to see and tinker with.


As the game is written in BBC BASIC, it should play fine on a vast majority of RISC OS machines, old or new.

The game runs well on a Raspberry Pi 2 and I’d imagine it should be fine with pretty much any other modern RISC OS compatible board you throw at it – Titanium, Beagleboard etc.


Overall, another solid title from Amcog and some definite progression in terms of the type of challenges Antony is giving himself with this game appearing to be a much more difficult title to write when compared to previous releases.

The game is a digital purchase via the Pling Store. If you’ve got just over a tenner to spare and want to help support further RISC OS game development from Amcog then giving Island of the Undead a spin isn’t a bad shout.

Running RISC OS servers in 2018: is it secure?

posted in: Software | 6

Over the years, the blog has featured a few articles on running Internet-facing services on RISC OS, from web servers (WebJames and HTTPServ) to VNC and Samba shares. While those articles did go a little into the security of running those services on RISC OS in this day and age, they didn’t cover what you can expect if you open up your WebJames or Samba instance to the wider Internet.

While browsing the ROOL forums I came across a discussion about how secure it really is to run servers on RISC OS in this day and age – considering how old the majority of server applications are for RISC OS, and how creaky some parts of RISC OS’ networking stack are. That got me thinking, how secure really is it to run services that you care about on RISC OS, or maybe a service that you don’t particularly care about (e.g. a Samba share you never use) but it’s running on a system that you do want to protect.

So to understand what kind of threats there are out there today and how relevant it is to RISC OS, it’ll be first worth going over what the threat landscape is today for Internet-facing servers in general and how sophisticated (or not) threat actors are with their attempts to steal or break your cyber-stuffs.

Password attacks

So unsurprisingly the vast majority of attacks against servers on the Internet are attempts to guess their password, and a huge quantity of those are not very sophisticated at all. This is mainly down to it being so easy to get into systems on the Internet with incredibly weak passwords (if they even have one). Password cracking tools such as Hydra and John the Ripper do allow for complicated ways of getting at people’s passwords other than just going through a list of widely used passwords, but realistically, attackers just don’t need to go to that level of effort.

The Mirai malware, which enslaves Linux systems all over the world, took down a large portion of the world’s most popular websites for a while in 2016 through an enormous Denial of Service attack on DynDNS – a DNS provider that supports services such as Netflix, Twitter and GitHub – in turn taking those websites down. Mirai achieved this through scanning the entire Internet (it’s quicker and easier than you think) and attempting to login to the Telnet service at each IP address armed with a small set (about 20 or so) of default usernames and passwords that are known to be distributed with popular Internet-connected appliances such as CCTV cameras and Network Attached Storage (NAS) drives – ‘admin’ and ‘password123’ type stuff for the most part. After logging into these systems via Telnet, the malware would then get the infected machines to launch Denial of Service attacks at a target all at once.

To give you an idea of the kind of password login attempts an average server might see on the Internet. A server I administer received just under 18,000 login attempts via the SSH protocol in September, which boils down to about 235 unique IP addresses attempting on average 76 login attempts. This in itself shows that attackers generally aren’t trying every possible password connection to break into your system, instead their plowing through a list of common usernames and passwords. Below is an excerpt of the SSH access logs so you get an idea of the kind of behaviour to expect in a password attack.

Nov 20 15:09:48 Plankton sshd[46342]: Failed login for invalid user admin from 194.61.XX.XX port 55962  
Nov 20 15:43:54 Plankton sshd[47108]: Failed login for invalid user service from 194.61.XX.XX port 55962  
Nov 20 17:33:11 Plankton sshd[49591]: Failed login for invalid user monitor from 194.61.XX.XX port 55969  
Nov 20 18:10:33 Plankton sshd[50444]: Failed login for invalid user guest from 194.61.XX.XX port 50669  
Nov 20 18:49:03 Plankton sshd[51313]: Failed login for invalid user support from 194.61.XX.XX port 50669  
Nov 20 19:25:06 Plankton sshd[52182]: Failed login for invalid user test from 194.61.XX.XX port 50711  
Nov 20 20:01:25 Plankton sshd[52990]: Failed login for invalid user debian from 194.61.XX.XX port 50712  
Nov 20 20:39:15 Plankton sshd[53853]: Failed login for invalid user service from 194.61.XX.XX port 50712  
Nov 20 21:16:33 Plankton sshd[54720]: Failed login for invalid user ubuntu from 194.61.XX.XX port 57006  
Nov 20 21:54:46 Plankton sshd[55569]: Failed login for invalid user user from 194.61.XX.XX port 57006  
Nov 20 22:34:53 Plankton sshd[56508]: Failed login for invalid user ubnt from 194.61.XX.XX port 57006  
Nov 20 23:16:28 Plankton sshd[57460]: Failed login for invalid user pi from 194.61.XX.XX port 63389

So with all that in context. If you want to password-protect content on your RISC OS web server, Samba or VNC server – just set a reasonably secure password and don’t reuse that password elsewhere. This website lets you see roughly how long it might take for someone to brute-force crack your password, once you get to 8 characters or longer, a password containing a mix of uppercase and lowercase letters as well as numbers and special characters is pretty tricky to crack – most attackers would move on.

That said however, if someone with enough knowledge and determination is for some reason targeting you specifically, then you might want to stop using passwords to authenticate altogether. As far as I’m aware, this will mean you’ll need to use a non-RISC OS solution for Samba, VNC etc. as I’ve not come across a RISC OS application that supports key-based authentication yet.

Encryption attacks

If your server is going to be handling any data you don’t want others getting their grubby mitts on, for example your family photos or maybe a website visitor’s form submission, then you’ll want to be using a server solution that utilises encryption when receiving and sending data. Intercepting data being passed across the Internet using a protocol that doesn’t use encryption, for example HTTP, is trivial with the right tools.

Unfortunately for us, there are no VNC, Samba or Web server programs for RISC OS that support encryption – this includes HTTPserv and WebJames, which are HTTP only web servers.

That said, if you want to run a web server that only serves free software you’ve written to its visitors, or just some information that you don’t mind anyone seeing, then hosting it on RISC OS isn’t a terrible option.

An example of this would be my Raspbery Pi at home, it runs a WebJames instance that consists of one webpage that links to other services on my local network (my file server, media server etc.), so if someone was to sniff that connection, all they’d be able to see is links to other services, but there’s no real data being passed across.

Denial of Service

Denial of Service (DoS) attacks were making the news quite a lot a few years back but they’re still a popular method of attack today, especially for people with very limited computer skills looking to create some damage. A notable attack from the last few years was the time Sony’s Playstation Network went belly up on Christmas Day due to their servers being flooded by enormous amount of bogus traffic in order to ensure that no genuine users could log onto the online gaming network.

Coupled with RISC OS server applications being more susceptible to DoS attacks than most modern servers, the threat of huge amounts of data flooding your server to stop you or others from gaining access for a little while is a real possibility. Although it does raise the question of why, unless there’s a particular reason why someone would want to take your server down for a period of time then this isn’t something I’d be too worried about.

Vulnerability exploitation

Vulnerability exploitation is a very real threat to all web-facing servers around the world. New flaws that can be exploited into remotely exposing private data or allowing attackers to take access of the system in questions are occurring all the time. These are generally fixed by software vendors in the form of software updates once they’ve been made aware of a particular vulnerability.

There are some quite old and easy-to-exploit vulnerabilities that will be lurking in Samba and probably VNC server applications for RISC OS right now due to the age of the software or protocol versions they’re based on.

In the case of Samba, the latest version for RISC OS is 2.0.2-19990209, versions of Samba 3.6.3 and lower suffer serious security issues but given that RISC OS is an entirely different beast to the Unix/Linux and Windows systems that these exploits are designed for, I find it very unlikely that Samba on RISC OS will be exploitable unless someone goes to the extent of researching then coding a RISC OS specific exploit – incredibly unlikely unless you’ve seriously pissed off a nation state or something.

To sum up

So in the grand scheme of things, if you want to run a server from a RISC OS system and you don’t have any data that could be damaging to you or others should it fall into the wrongs hands, then there’s not really any huge red flags in your way. The possibility of someone exploiting the server software to get into your computer is incredibly small, and providing you don’t cheese off a load of teenage online gamers, then you’re probably not going to fall victim to a DoS attack either.