Month: August 2015

New monitoring

Since we went static IP for our broadband, I can no longer infer the state of the Norchard broadband from the number of times we change IP address per hour (previously every time the broadband connection went down it would come up on a different IP address)

So I’ve put some better monitoring in place, and http://dfrvoip.org.uk/blog/status/ now tracks our connection to the outside world by pinging the google DNS servers.

Due to the way they’re hosted – the graphs on that page might not be visible on every interenet connection. I’ve got a few ideas about how to change that, but they’ll have to wait for another day as life is somewhat hectic at the moment!

The technology I’m using is pretty basic network monitoring software called smokeping. It’s not my monitoring tool of choice, but it’s easy to install and get going – and for something as simple as monitoring a single internet link it’s pretty good.

The gratifying results of this are that our current broadband looks a lot more stable than the previous broadband!

Changes to dial in access

Some time ago, I put in place a test number on our Asterisk system to allow the Telecoms Team to access the internal telephone network from the public telephone network, so that we can test and verify facilities, and access our exchange test numbers from home.

It’s been brought to my attention that this number has “leaked” and is now being used by at least one person to access the internal network from their mobile phone during the running day.

Apparently me working on the Asterisk DP during the day on the 8th August caused an issue for this person, and while they didn’t complain to me directly, I did get to hear of the complaint.

I don’t know who this person is, but I can see that they have used the facility 27 times in the last 3 weeks and rumour has it they are operational staff – and that worries me.

The Asterisk system which hosts the test number is maintained by a single volunteer who has a full time day job in Bristol (me!), and I can only really work on it at weekends – during the running day. It has no resilience or redundancy designed into it, and the phone number is provided by a free provider (so may go away or change at short notice)

In the past, when the Asterisk has failed it’s taken me 3 weeks to get to site to resolve the issue (in one case, much longer) If that was to happen again, and someone was relying on it for operational use then that may put the safety of the railway, or the continuity of the business at risk!

Given these limitations I cannot in good conscience allow the facility to become relied upon for business, operational, safety or emergency use – so I need to nip this in the bud and clarify the position.

I have changed the recorded message on it this evening to something which makes the status of the facility clear, and if the message doesn’t appear to get through – I may be forced to change the PIN.

Sorry if that’s inconvenient for anyone, but I just can’t let an informal test facility sneak into operational service like this!

Two minor fixes

I’ve done two minor fixes this week:

  • Status Graphs: These were being updated, but not drawn for most visitors. I’ve fixed that now, if you still have no graph try a force refresh of the page (ctrl-f5)
  • Speaking Clock: Ian noticed that it was saying “thirty four” twice, skipping “thirty five” and jumping straight to “thirty-six” – This was a fault I fixed on my asterisk server years ago, but seemingly never applied the fix to the railway version. The route cause was that the “35.wav” file contained the words “thirty four”. I’ve updated to a newer version of the samples and everything is working again.

I’m going to re-think the status graphs, as we now have static-ip so don’t need dynamic DNS any more (so don’t really need to monitor it any more).

Perhaps I’ll finally write the peer monitoring stuff as well, so we can spot when sipgate goes away.