Wednesday, March 25, 2020

Introducing new Radiator Repository

Recently, Radiator Software team has been putting their efforts into making life easier for system administrators. Following the introduction of the new Radiator Linux packages, we are now very proud to announce the new Radiator Repository. This is good news for the Linux users, since the new repository allows you to streamline maintenance and to easily distribute the updates to all Radiator servers in your organisation. What is even better, this new service is included with all active Radiator Support contracts. 

Supported platforms are Red Hat 7/8, CentOS 7/8, Ubuntu 16.04 (Xenial), Ubuntu 18.04 (Bionic), Debian 9 (Stretch) and Debian 10 (Buster). Here are the steps how to get it:

  1. Visit our repository page and log in using your existing Radiator user credentials: 
  2. Scroll down to your Linux distribution version 
  3. Follow the instructions and use the commands in instructions to set up Radiator Repository
  4. Enjoy easy updates

For security, the repository URLs are customer specific and generated for your organization, and the packages provided from Radiator repositories are never marked as security upgrades. This means that using unattended-upgrades for system's security upgrades is safe as Radiator will not be automatically upgraded. You also get to pick whether you want the official releases only, or include the testing versions. 

For our customers using other platforms or with download access only contracts, Radiator Downloads site has been redesigned and is sporting a clean new look. You will continue to get the software updates the classic way by downloading the packages from our website, whether you are using Mac or Windows, older Linux distributions, or simply prefer to do so.  

Please contact our team at if you want to check your subscription status, renew or upgrade your support contract, or reset your password. Let us know if you try the new repositories. We would like to hear your feedback!

Thursday, March 5, 2020

Protecting user identity with Radiator SIM Pack

Nowadays, mobile operators use complementary network technologies to improve user connectivity. Mobile data traffic originally targeted for cellular networks can be offloaded to designated Wi-Fi hotspots, therefore relieving congestion in high traffic areas. By implementing SIM authentication with Radiator SIM Pack, customer experience is enhanced by seamlessly authenticating users and logging them into the Wi-Fi network.

Cellular networks use IMSI (International Mobile Subscriber Identity) as a unique identifier for every user of the network, which comprises 15 digits including the user's telephone number. When this identifier is sent by the device to the network, privacy can be compromised if the connection request is not encrypted. This encryption relies both on the operator's AAA server and the user device.

Starting from revision 2.5, Radiator SIM Pack supports IMSI encryption, also known as "Permanent Identity Encryption"; functionality specified in 3GPP document S3-170116: "Privacy Protection for EAP-AKA". This feature is already implemented by some of our operator customers to cover their AAA server encryption. Alongside device manufacturers such as Apple, who already implement identity encryption, permanent identity of the user is not exposed, increasing their privacy protection.

The latest release of Radiator SIM Pack is available for new licensees and for licenced customers with valid download access. To find out if Radiator SIM Pack suits your needs, you can contact us at and a member of our sales team will be happy to assist you. You can also contact us to renew your support contract and get access to the newest release. A full history of Radiator SIM Pack releases is available on our website.

Wednesday, February 26, 2020

New Radiator Carrier Pack 1.6 released

Radiator Software is pleased to announce the release of Radiator Carrier Pack version 1.6. This revision includes improvements such as enhanced Diameter routing and rearranged StreamServerUnix modules. This new version of Radiator Carrier Pack requires the newest version of Radiator AAA Server Software (4.24).

Detailed changes and updates include:

  • Rearranged StreamServerUnix related modules by separating connection package from the server package file.
  • Minor fixes to StreamServerUnix unix domain socket initialisation.
  • Major Diameter routing enhancement: Diameter peers for request routing and forwarding can now be looked up from Diameter specific RealmTable added in Radiator 4.24.
  • Minor update to DiaPeerDef related peering to update Diameter routing RealmTable added in Radiator 4.24.

A complete revision history can be found in our website.

Since revision 1.5, Radiator Carrier Pack is available in packages suitable for Red Hat, CentOS, and Ubuntu. If you are interested in purchasing a Radiator Carrier Pack licence or due for a support renewal, you can contact and a member of our team will be happy to assist you.

Tuesday, December 10, 2019

Radiator 4.24 is now available!

We are pleased to announce the release of Radiator version 4.24.

This version contains new features, enhancements, and bug fixes, including new Radiator packages now available for Red Hat Enterprise Linux 8, CentOS 8, and Debian 10 (Buster). 

Selected compatibility notes, enhancements and fixes
  • Added configuration parameters TLS_SecurityLevel and EAPTLS_SecurityLevel and calls to set accepted TLS version ranges. This allows for Radiator module level control of desired TLS settings without modifications of system defaults.
  • ClientListSQL configuration can now be simplified with ClientColumnDef parameters.
  • AuthBy SQLHOTP and SQLTOTP SQL query parameter support was added.
  • Dynamically updated Diameter RealmTable for request routing and forwarding is now available for advanced Diameter applications.
  • Added a new configuration flag parameter IgnoreIfMissing.
  • Added a new check item ExistsInRequest for matching requests by attribute presence. Useful for Handlers.
  • Added new AuthBy REST, which is built on a new class called HTTPClient.
  • Packages are now available for Red Hat Enterprise Linux 8 and CentOS 8 and Debian 10 (Buster).
  • Added configuration guide and samples for SecureW2 integration.
Known caveats and other notes
  • TLSv1.3 remains disabled by default for TLS based EAP methods and Stream based classes, such as RadSec.
  • EAP-FAST functionality is reported to vary between TLS versions, TLS library security level settings and client implementations.
As always, more detailed changes can be found in the revision history.

Monday, November 18, 2019

Fix to lost zsh prompt settings in MacOS Catalina

A major portion of our Radiator team are MacOS/Linux users and even on Windows usually run Linux/GNU/UNIX command line tools. In the recent MacOS Catalina Apple switched from bash shell to the zsh shell and there was much rejoicing.

However, to the annoyance of at least the writer, Apple changed their zsh configuration so that setting up terminal prompt in user's own .zshenv did not work anymore.

This is caused by Apple's default configuration in /etc/zshrc, which is read/run for interactive shells after user's .zshenv. In the Apple's default configuration the prompt is set up as follows:

# Default prompt
PS1="%n@%m %1~ %# "

To override this, just put PS1/PROMPT settings (and other settings you may want to override for interactive shells) into user's .zshrc and the problem is solved.

Tuesday, June 25, 2019

Grouping and controlling multiple Radiator instances with systemd


Radiator Linux packages provide by default two systemd service files -- /lib/systemd/system/radiator.profile for single instance and /lib/systemd/system/radiator@.profile for multiple instances configuration. The single instance configuration expects to find its configuration from /etc/radiator/radiator.conf while the multiple instances configuration expects each instance configuration to be named as /etc/radiator-<instance>.conf e.g. /etc/radiator/radiator-proxy.conf.

When configuration files are in place, the instances can be enabled/disabled with following commands.

Single instance enable/disable:

systemctl enable radiator
systemctl disable radiator

Multiple instance enable/disable (instance name proxy, configuration file name radiator-proxy.conf):

systemctl enable radiator@proxy
systemctl disable radiator@proxy

All the commands above and in these instructions require root privileges, so open a root shell or use sudo to make sure that commands work.

Please note that enabling or disabling an instance does not start or stop the instance. It only controls if an enabled instance is started when starting the server. For starting and stopping instances manually there are systemctl start <instance> and systemctl stop <instance> commands e.g systemctl start radiator@proxy.

Sometimes there exists a need to run multiple Radiator hosts on a single host -- for example when one has separated RADIUS proxy and authentication functionality into multiple separate instances. The reasons to do so vary from clarifying configuration to optimising performance by running multiple Radiator processes instead of a single one.

When multiple instances are used, managing and restarting them separately may become burdensome. Together with Radiator's systemd service files, systemd provides the means to group and control multiple Radiator instances with one virtual systemd service. These instructions follow the systemd configuration guidelines as described by Linux distribution manuals.

Preparations before starting

Please check and do at least the following before starting to migrate to virtual systemd service model:
  1. Ensure that your Radiator instance configurations work as manually controlled services. This means that you have working configurations for them and are able to enable, disable, start and stop them without any problems. If you run into trouble getting instance configurations running, check the configuration file owner, group and file permissions so that they are readable by radiator user or group.
  2. Stop and disable all Radiator instances
These will ensure that you can more easily detect problems with the virtual systemd service configuration, when you know for sure that the instances and their configurations are already tested to be working. Stopping and disabling them ensures that you will start from clean slate when adding new virtual systemd service files.

When editing systemd service files, please do not edit and change files in /lib/systemd/system as the next Linux Radiator package upgrade will overwrite those files. The proper place to do these adjustments is under /etc/systemd/system as the following instructions will also describe.

Setting up virtual systemd service to control multiple instances

The actual implementation varies with the version of systemd, but for clarity, we have divided the instructions according to tested and compatible Linux distribution versions.

Red Hat 8.0, Ubuntu 18.04 LTS

Configuration files

Create the virtual systemd service file /etc/systemd/system/radiator-instances.service with the following content:

Description=Virtual service for managing all Radiator instances

# The dummy program will exit
# Execute a dummy program
# This service shall be considered active after start

# Components of this application should be started at boot time

Adjust existing radiator@.service file by creating a directory /etc/systemd/system/radiator@.service.d and creating adjustment file /etc/systemd/system/radiator@.service.d/custom.conf with the following content:



Controlling the instances

When you have finished creating the files and directory, you can enable the virtual service and instance(s) for example with the following command (assuming you have instances proxy and auth):

systemctl enable radiator-instances radiator@proxy radiator@auth

You can then control all instances either separately or by directing the virtual service radiator-instances with commands like:

systemctl start radiator-instances
systemctl stop radiator-instances
systemctl restart radiator-instances

The virtual radiator-instances now controls all radiator@.instance based instances on host. If you need more granular control, of which services are controlled radiator-instances, you need check Grouping instances to control section in the end.

Centos 7, Debian 9, Red Hat 7, Ubuntu 16.04 LTS

Configuration files

Centos 7, Red Hat 7 and Ubuntu 16.04 LTS have an older version of systemd, which is not able to understand instance configuration adjustment directories like /etc/systemd/system/radiator@.service.d. Because of this, on these platforms, the radiator@.service itself needs to be copied to /etc/systemd/system directory to be adjusted. The disadvantage of this is that if new Radiator packages update the radiator@.service, the updates need to be edited manually to the /etc/systemd/system/radiator@.service file.

Create the virtual systemd service file /etc/systemd/system/radiator-instances.service with the following content:

Description=Virtual service for managing all Radiator instances

# The dummy program will exit
# Execute a dummy program
# This service shall be considered active after start

# Components of this application should be started at boot time

Copy the /lib/systemd/system/radiator@.service file to /etc/systemd/system/radiator@.service and add the following lines to it.

To [Unit] section add line:


To [Install] section add line:


Controlling the instances

When you have finished creating the files, you can control the instances like already presented in the Red Hat 8.0, Ubuntu 18.04 LTS -- Controlling the instances section.

Grouping instances to control

The above instructions assume that you want to control all Radiator instances on a host with the radiator-instances service, but if you want to select the instances the control, the recommended way is to create renamed radiator-instances and radiator@.service under /etc/systemd/system. This approach is common for all mentioned Linux distributions and Radiator packages

For example if you wanted to group certain organisation's instances on host under a virtual service, you could create radiator-organisation-instances.service and copy /lib/systemd/system/radiator@.service as radiator-organisation@.service under /etc/systemd/system. In this case it does not matter if you use newer or older systemd as it is better to separate radiator-organisation@.service from radiator@.service. What you need to do is to adjust radiator-organisation@.service file so that it has PartOf and WantedBy lines pointing to the new renamed radiator-organisation-instances.service file.

After setting up those renamed files, you will be able to command the group of instances the same way as above with system wide instances group. The only difference is that for example in this case you would use the same commands with differently named services and instances, for example:

systemctl enable radiator-organisation-instances radiator-organisation@auth radiator-organisation@proxy

systemctl start radiator-organisation-instances

systemctl stop radiator-organisation-instances

For more information

In case you have any questions, comments or feedback, please contact

Thursday, June 20, 2019

TNC19 Radiator technical workshop presentations available!

Terena Networking Conference 2019 (TNC19) is over as is our Radiator technical workshop, which was part of the conference. Here are all of Radiator Software presentations presented in the Radiator technical workshop. You are able to find these also on our SlideShare account, where we will upload also future public presentations about Radiator.

1) TNC19 Radiator Technical Workshop -- Introduction, what's new with Radiator (Software)

2) TNC19 Radiator Technical Workshop -- Using Radiator to ensure better SP/IdP connections to eduroam/govroam

3) TNC19 Radiator Technical Workshop -- Meet Radiator developers

Thank you to all Radiator technical workshop participants, we hope to see you again. We also will look into possibilities of repeating our technical workshop as a webinar together with TNC19 organisers for those who were not able to attend live.