The VirtualBox Guest Additions are software services which allow client operating systems to interact with the Virtualisation environment, breaking the limitation of strictly running the client OS on emulated hardware. Facilities provided include cut and paste between the Client OS and the host system, much better display support with resizing, and even drag and drop of files (which I have not got working).

Up until about Ubuntu 14.04, the method for installing the VirtualBox Guest Additions was to install Ubuntu and then to (virtually) install the Guest Additions CD image provided by VirtualBox and run the installation from that. This no longer works under Ubuntu 17.10 (and I read that it didn’t work for Ubuntu 16, but I can’t verify that). Instead, packages are provided in Ubuntu itself to support the VirtualBox virtualisation facilities.

Based on a video by ‘Linux Video Tutorials’, here are the steps to install the VirtualBox Guest Additions in Ubuntu 17.10:

Settings for VirtualBox VM

    • set plenty of Video Memory (128Mb) in Display->Screen
    • set 3D Acceleration active in Display->Screen
    • enable PAE/NX under System->Processor
    • enable the bidirectional clipboard and drag and drop if you want them, in General->Advanced.

Installing the software

% sudo apt-get update
% sudo apt-get upgrade
% sudo apt-get install build-essential virtualbox-guest-dkms virtualbox-guest-x11
% sudo shutdown -r now

Checking that the software is working

The client OS should now boot with flexible display resizing and cut and paste support. The VirtualBox Guest Additions services should be enabled and running. I found I had to start them:

% hostnamectl
% sudo systemctl status virtualbox-guest-utils.service
% sudo systemctl start virtualbox-guest-utils.service
% sudo systemctl status virtualbox-guest-utils.service

% ps -ef | grep -i vbox
 root 280 2 0 11:36 ? 00:00:00 [iprt-VBoxWQueue]
 lemon 1501 1 0 11:37 ? 00:00:00 /usr/bin/VBoxClient --clipboard
 lemon 1504 1501 0 11:37 ? 00:00:00 /usr/bin/VBoxClient --clipboard
 lemon 1505 1 0 11:37 ? 00:00:00 /usr/bin/VBoxClient --display
 lemon 1506 1505 0 11:37 ? 00:00:00 /usr/bin/VBoxClient --display
 lemon 1512 1 0 11:37 ? 00:00:00 /usr/bin/VBoxClient --seamless
 lemon 1513 1512 0 11:37 ? 00:00:00 /usr/bin/VBoxClient --seamless
 lemon 1519 1 0 11:37 ? 00:00:00 /usr/bin/VBoxClient --draganddrop
 lemon 1520 1519 0 11:37 ? 00:00:00 /usr/bin/VBoxClient --draganddrop
 root 20751 1 0 11:40 ? 00:00:00 /usr/sbin/VBoxService

Three years ago, I wrote about making Trixbox work in the UK with TDM400P analogue line cards in a PC to connect to the PSTN and normal telephone extensions.  That setup served me well for ages, but I began to have difficulties with the Digium TDM400P cards when driving the lines to the exchange.  One of the channels started to play up, and as the DAHDI drivers are not really user-friendly either, I migrated to a pair of Linksys SPA3102 boxes.  These are sweet devices which have a lot more functionality in them than I use in my setup.  The SPA3102 provides an exchange line (PSTN) interface socket and also a traditional analogue phone interface socket, as well as two Ethernet interfaces, one intended to connect to the Internet (or in this case, to my Asterisk server) and one which I do not use, intended to serve a PC or home/office network.

Things in the Asterisk world have moved on in three years, and one change is that Trixbox is no longer supported.  Feeling that the time was right for an upgrade, I looked around the web and concluded that the front runner these days is PBX in a Flash.  This is very similar in scope to Trixbox, being a complete distribution presented as a bootable DVD which takes over and overwrites the entire machine it is booted on.  Beware!  For my upgrade, I disconnected the existing disk drive and used a different one for the new installation.  In typical calavier fashion, I didn’t write much down about my existing configuration and just went ahead and installed the new one.  I used PBX-in-a-Flash (PIAF) v2. which includes CentOS 6.2, and I used the 64-bit version.  PIAF requires the user to make quite a lot of choices during installation, and I chose FreePBX 2.9 and Asterisk 1.8, these being the most recent stable versions.

Installation takes forever,  belying its name.  The massive distribution doesn’t even include half the stuff you need, instead relying on the Internet to download and automatically install additional components.  There are several guides to installation on the Web, so I shan’t attempt one here.  What I do want to cover though is the mysteries of getting the TDM400P cards to be recognised.

The best guide to this which I found is Configuring and Testing Dahdi Hardware.  This covered the basics for me, though I had to recompile and reinstall the DAHDI drivers first:

# cd /usr/src/dahdi/
# make all
# make install
# make config

# cd tools
# make distclean
# ./configure
# make install

Then reboot the machine.

The undocumented magic for me was:

# dahdi_genconfig
# cd /etc/asterisk

Edit chan_dahdi.conf and add this line near the end, before chan_dahdi_additional.conf:

#include dahdi-channels.conf

After that, it’s time to reboot again and confirm that the channels exist:

# dahdi_cfg -vv

This should list lots of channels on the cards you are configuring.  They should also be visible in the Asterisk command-line interface (this output is specific to my setup):

piaf*CLI> dahdi show channels
Chan Extension  Context         Language   MOH Interpret        Blocked    State
pseudo            default                    default                         In Service
1            from-internal              default                         In Service
2            from-internal              default                         In Service
3            from-pstn                  default                         In Service
4            from-pstn                  default                         In Service
5            from-internal              default                         In Service
6            from-internal              default                         In Service
7            from-internal              default                         In Service
8            from-internal              default                         In Service

One more magic step: use a browser to access the FreePBX administration interface on your server, and go to the Setup->DAHDi screen.  Under Analogue Hardware, find a line entitled “FXS Ports” and hit the “Edit” link.  If the Group entries are blank for your channels, enter “1” in each group field, then save and apply the settings.  At that point you should be able to create DAHDI extensions.  Hoorah!

The UK-specific changes I documented in my first article on this subject probably still apply, but I haven’t tried them as I no longer use the FXO ports.

Turn it on

{Administrator}=>service system modify
[state] = enabled
[log] = false
:service system modify name=SNMP_AGENT state=enabled log=disabled

Add a RO community

{Administrator}=>snmp community add
securityname = ROCommunity
communityname = ******
Please retype communityname for verification.
communityname = ******
:snmp community add securityname=ROCommunity communityname=_DEV_E43BC822A4BAE52F
{Administrator}[snmp community]=>

Where the asterisks are type your chosen community name.

Once this is done I could access the router using SNMP version 1 and my RO community string.

This information was taken from with thanks.

I was reading this interesting catalogue of telco-powered products which rely on the ultra-reliable batteries in telephone exchanges in many countries including the UK.  In my imagination, after the apocolypse, as we’re all sitting in our cellars drinking the best bottles of wine, but we can’t find the corkscrew because the lights have all gone off, we will rig up lights powered from the telephone line and everything will, somewhat briefly, be all right.

But then I had this fantastic idea.  Where I come from, there’s a trend to solar power and micro-generation with the government subsidising technologies and products which allow locally generated electricity to be sold into the national power grid, at really good prices too.  But why wait for the solar panels and micro-generation? We have a great source of local power already: the phone company!  I now plan to develop a gadget that takes power from the phone line and sells it to the power company.  OK, so the amount of power available will be very small, but it will always be there!

Another idea would be to take cheap energy in the night time, store it in hot water tanks, and generate electricity from it again in the day, selling it back to the power company at a better rate later.  Could this be my future income stream??

I’ve been trying to use Ruby libraries to access Sharepoint and am having trouble getting to the starting line.  NTLM authentication from Ruby doesn’t seem to be in a good state.  I’m using httpi-0.9.6 as my HTTP library, which by default uses httpclient-2.2.4, and for NTLM support I’m using httpi-ntlm-0.9.6.  All this is running under Ruby 1.8.7 which incorporates Net::NTLM 0.1.1 which http-ntlm relies on.

In my enterprise environment, I need to use NTLM authentication to access the Sharepoint server.  So, I format the username string supplied to httpi as “USERDOMAIN\username”.  It happens that the Sharepoint machine I want to access is in a different NTLM domain than the user account that I want to access it with.  When httpclient does the NTLM authentication phase, it uses facilities from Net::NTLM to format a Type 1 Message.  This is where the problems start.  Firstly, httpclient doesn’t do the right (undocumented) things necessary to get Net::NTLM to properly include the user’s domain into the request.

case state
  when :init
    t1 =
    t1.domain = domain if domain
    return t1.encode64

The trouble here is that this code doesn’t properly tell Net::NTLM that this domain information should be incorporated into the request.  As written, HTTPI generates a corrupt request, as can be seen from a Wireshark trace.  It’s additionally necessary to enable the resulting SecurityBuffer and to set a flag in the request indicating that the domain is being signalled:

case state
  when :init
    t1 =
    if domain
      t1.domain = domain
    return t1.encode64

But when you do this, you find that the packet is still corrupt, because the offset to the domain name data in the resulting request is incorrect.  This is because of what appears to be a bug in Net::NTLM.  That’s not so easy to fix and play about with, because it’s incorporated into Ruby itself.  The problem is that the offsets are calculated by adding the sizes of the SecurityBuffers defined for the message type, regardless of whether a particular SecurityBuffer is active or not. For my testing purposes, I forced the additional “workstation” SecurityBuffer to be active (with an arbitrary non-null value) in the same way as the Domain, and by doing so, was able to generate a valid request.

But imagine my horror when my requests were still denied by the server.  Further investigation revealed that Net::NTLM ignores the user-specified domain when generating the subsequent Type 3 Message, substituting instead the Target value returned in the Challenge of the Type 2 Message.

Further hackery will be required to fix that, but another approach might be to use Curb instead of httpclient.

I really enjoy learning new things in the field of computer science.  Recently I have been learning some new computer languages and having a great time into the bargain.  Ruby is my favourite, but I’ve also started playing with node.js which is an asynchronous IO library bundled with an implementation of JavaScript (or ECMAscript) because substack has been Plurking about how wonderful it is.  I’m not all that keen on JavaScript so far, partly because I’m so keen on Ruby and partly because of the criticism of it by Douglas Crockford in his book JavaScript: The Good Parts.  However he is not totally anti-JavaScript and has spent a lot of time working on its standardisation as described in a YUI Theatre video called The State and Future of JavaScript.  (This was very interesting for me, for reasons some people may know, though of course I didn’t agree with everything he said.)  There’s a bunch of intriguing talks available at The YUI Theater which I’d love to watch.  I did watch the one by Ryan Dahl on node.js and I expect I will go back for more.

The computer on my desk at home runs Windows (XP SP3 at the moment) rather than my beloved NetBSD or a Linux variant.  Of course my servers run real OSes, but I wanted to work on my desktop machine and so spent a while installing node.js, its package manager and associated packages under Cygwin, which is what makes programming on a Windows machine bearable for me.  The node.js installation instructions cover Cygwin separately and the instructions there worked for me.  However I had a problem using the Node.js Package Manager to install third-party modules.  As described in this email thread, Cygwin pipelines into gzip can hang in certain environments.  I spent hours rebooting, reinstalling and futzing around until I found that thread, which goes on to lay the blame on a “BLODA“.  It turns out that certain antivirus applications can cause this, by hooking themselves into the system call invocation chain in a way which doesn’t actually work perfectly.  I turned my AVG Antivirus Free (v11) off for 30 seconds during the installation of this particular package (called “request“) and the installation went like a dream.

Node.js is young software and under frenetic development.  One promising use-case is the implementation of very scalable web applications, where the asynchronous IO model can yield great efficiencies.  My interest in it is as a web client, where I hope to use it to retrieve and execute JavaScript from websites whose applications depend on it, but with which I want to interact with programatically rather than manually in a browser.  Some such websites (for example Plurk) provide proper APIs for this, whereas others, such as Facebook, do not.  Facebook requires you to write a Facebook application instead.

A consequence of node.js’s youth is the immaturity of adjunct libraries for interaction with other services.  Although HTTP is treated as a first-class application with built-in support, that support is primitive at this stage when compared with Ruby’s net/http.  I’ve been exploring the available libraries for node, which for HTTP client applications include node-httpclient, node-get, node-http-digest, request and abstract-http-request of which the last two look particularly promising.  None of them appear to offer cookie storage between requests, which is something I will need.  At the moment I’m thinking of using one of the available key-value storage libraries which are available to store cookies.

Once one receives the appropriate page from the server, the HTML may need parsing (and there are plenty of HTML parsers for node, such as this), and scripts therein will need executing (aha! That’s why I’m using JavaScript to write the program!).  That’s all in the future.  For now, I’m able to run simple JavaScript programs which fetch pages from websites, and ready to start the real work.

Sitting here in China, wondering what to do, I decided to write some code to help with analysis of moves in a wargame.  Rather than write it though, I started to wonder why people like to write code.

I find writing computer programs fun. When they work, it’s fantastic. When they won’t, it’s frustrating.  I love learning new skills in computing, new languages, environments, toolkits. That’s not to say I like all the ones I come across; there are some which put me off, or which I fail to understand quickly enough to keep my interest. (Ruby on Rails is one such.)  I claim that learning to use these new tools keeps my brain sharp.  Recently I’ve been writing web-hosted database applications, for fun!  I used to think databases were the pits; the boring, commercial end of computing, but now I’ve found a need to use them and find lots of interest, particularly in constructing complicated queries. I never cease to be amazed at how much one can persuade the server to do, rather than have to code into the client application.

This morning though, it wasn’t the challenge which excited me, or even the benefit the new code would bring once it was completed – it was the aesthetics of the code itself.  There are two aspects to that, one serious and one more trivial.   Since I learnt my original computing skills (in assembly language and BASIC), the power of languages has changed greatly.  There’s a good deal of satisfcation in being able to write small chunks of code which do a lot.  I find Ruby particularly rewarding in this respect.  Secondly, editors with syntax highlighting make code so attractive!  Pretty code draws the eye; colours help understanding.  I want to code because the result is pretty!

Asterisk is an open-source PABX.  It can connect existing telephones, “soft phones” running on a PC, and physical IP phones to the VOIP networks and to existing “POTS” telephone lines.  Connectivity to existing telephones and exchange lines is provided by either external hardware boxes such as Astribank (for large systems) or PCI plug-in cards such as Digium’s TDM400P.  Cards are also available to connect to digital lines such as T1/E1 to provide multiple lines.

Using Asterisk, I can connect telephones in my children’s bedrooms to the one in the kitchen, and allow them to make phone calls (with restrictions).  I can also connect to my home telephone system from the Internet and call my wife on a real phone from my iPod Touch, or make a call apparently from home when I am in a conference room in the USA.  Also, I can provide new telephone numbers in minutes (via VOIPuser for example) which connect directly to a particular phone in my house, or my PC wherever it is in the world that day, or to an automated message.  I can receive voicemails and have them sent to me by email.  I can also write simple teleohony apps which (for example) tell my wife how many emails she has when she dials *90 on the phone in the kitchen.  The telecoms world becomes my oyster.

Asterisk is available in many forms, both in source and binary distributions designed to run on a PC.  The easiest approach is to dedicate a PC to running Asterisk (though mine also runs a firewall for my home network and a disk server).  Pre-packaged distribtions for this are available and the one I prefer is Trixbox.

Getting Asterisk to work in the UK with caller-id can be tricky.  Having struggled with it several times and found a solution which works, I thought I’d write it down both for my own reference and to help other people struggling with this problem.

  1. Install Trixbox from CD.  Trixbox is based on the CentOS Linux distribution.  Mind, it will find and destroy *all* your hard disks at installation time.
  2. Upgrade to Asterisk (I think)
  3. # yum clean all
    # rpm -del –nodeps kmod-dahdi-linux dahdi-linux
    # yum -y update           (this takes a while)
    # yum install kmod-dahdi-linux dahdi-linux

  4. Then edit /etc/modprobe.d/dahdi to add a line as follows:
  5. options wctdm opermode=UK fwringdetect=1 battthresh=4

  6. Then edit /etc/asterisk/chan_dahdi.conf to add the following lines after “usecallerid=yes”
  7. cidsignalling=v23

NOTE that Asterisk seems to refuse to use the outgoing line after a reboot until the line is unplugged and plugged back in again!