Continue reading »]]> Bugtraq can be an interesting list. Back in June 2008 I noted that one Craig Wright had posted an advisory about a vulnerability in an Oral B toothbrush. Well, just over a week ago a chap called Gabriel Menezes Nunes posted a proof of concept remote denial of service attack on a Sony Bravia television set. He had discovered that a packet flood attack to any port on his TV using the tool “hping” would cause a denial of service. In his post he says:

“After 35 seconds the TV stop working and back. This happens 3 times. At fourth time, the TV shuts down. In less than 3 minutes, the TV is off remotely. It is necessary to turn on the TV physically.”

I can’t help thinking that using the normal remote control would have been easier.

Continue reading »]]> In January of this year I wrote about t-mobile’s apparent policy of actively looking for and blocking any TLS-secured SMTP sessions over their network. At the time I believed this to be a cockup rather than a deliberate policy. I still prefer to believe that, but the episode left a rather sour taste in my mouth. So this month I took the opportunity presented by the end of my contract to shift to another provider. Of course, in doing so I gained a nice shiny new ‘phone which meant that I could spend a fun few hours setting it up the way I wanted it and nailing it down as much as possible so that it didn’t leak all my data to google. This is unnecessarily difficult, and much harder than it should be (and I know that people like Peter H will simply tell me that I shouldn’t be using an android ‘phone in the first place). But that is not the point of this post.

Like most people these days, I use my ‘phone to pick up email. The standard email client on my last ‘phone was pretty uninspiring so I used K-9 mail in its place. K-9 is a pretty good application, but it has a silly little bug in it which is still not sorted properly. This bug manifests itself in a rather odd, and unpredictable way – K-9 seems to “forget” the X509 certificate used to protect the authentication process if that certificate is self-signed, or otherwise not verifiable by an external CA. The cure, such as it is, is to simply refresh the certificate by reloading the account settings and accepting the cert when K-9 warns you that “TrustAnchor found but validation failed”. The length of time between accepting the cert and K-9 “forgetting” it again seemed random to me, so I got into the habit of refreshing my account settings whenever I noticed that I hadn’t received any mail for a while. Annoying, but not ultimately a deal breaker for using what was otherwise a pretty good application.

So, the first application I looked at on my new mobile was, of course, email. The default mail client on this new phone looks a lot slicker than the old one on my previous phone, but then it is a much newer ‘phone, from a different manufacturer and the android version is much newer too, so no real surprise there. The setup seemed to have no problem with my self signed certs so I thought I might stay with the default to see if it would solve my annoying little problem with K-9.

Unfortunately not.

Whilst I had no problem with incoming mail over my IMAPS connection, all attempts to send mail failed. On checking my server logs I found the following (real details changed or obfuscated):

Mar 20 20:45:57 pipe postfix/smtpd[7594]: NOQUEUE: reject: RCPT from home.baldric.net[12.34.56.78]: 504 5.5.2 <localhost>: Helo command rejected: need fully-qualified hostname; from=<null@baldric.net> to=<noone@baldric.net> proto=ESMTP helo=<localhost>

Aha! My postfix configuration is set up to reject hosts which do not have valid hostnames or do not announce themselves with fully qualified domain names (i.e. names of the form “host.domain”). Now since I use SASL authentication in my postfix configuration the fix is relatively easy; just ensure that the stanza “permit_sasl_authenticated” appears in both “smtpd_sender_restrictions” and “smtpd_helo_restrictions” before “reject_non_fqdn_hostname” – thusly:

smtpd_helo_required = yes
smtpd_helo_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_hostname, reject_invalid_hostname
smtpd_sender_restrictions = permit_sasl_authenticated, permit_mynetworks, reject_non_fqdn_sender, reject_unknown_sender_domain

(In fact, this episode highlighted an error in my postfx configuration because my helo restriction was inadequate. By now checking the authentication before the helo restriction kicks in I am still well protected, but mail from valid authenticated users is permitted.)

I am in that (very) small minority of people who run their own mail servers and are able to change server side configurations. But, and this is a big but. I should not have to change the server side configuration to accommodate a broken client and the vast majority of people will not be able to do so anyway. Almost all well set up mail servers will reject mail where the client connection announces itself in the helo exchange as “localhost”. That is normally an indication of a spammer, indeed spamassassin will allocate a high score to any mail which is so flagged. This means that there will be a huge, and growing, number of people who cannot send mail from their android ‘phones.

If this is the default android mail behaviour, then google need to fix it now. Meanwhile, K-9 is looking attractive again.

Continue reading »]]> A few days ago my sheevaplug died. Beyond the obvious lack of response either over the network or through the USB serial connection, the symptoms (single green LED rather than blue and green LED lit, ethernet LED light steady rather than flashing) were all consistent with a blown PSU.

This problem is well known and well documented on the Newit forum and the plugcomputer forum as well as plenty of other sites, so I was pretty confident in my diagnosis. The general consensus seems to be that the low quality components used by Globalscale in what is, after all, supposed to be a piece of development kit, coupled with its low power output, means that it can’t really cope with the demands placed upon it – particularly if you attach unpowered USB peripheral devices. Even so, I was pretty pissed off that it failed after only two years.

I use my plug as my NTP time source, network “apt-get” cache and local end point for my ssh proxy tunnel to tor. So it was quite important to me that I get it working again. Fortunately Newit now stock replacement PSUs. Mine arrived within a couple of days of order.

Newit have kindly placed a “howto fix your fscked plug” guide online. I found the process relatively easy, with the exception of replacing the new AC inlet plug back in the chassis. In the end I pushed hard and held my breath in case something snapped, but I got it in.

I have seen many pictures of the PSU on-line, but I confess I was pretty shocked at the completely amateurish look of the thing when I pulled mine out.

The picture above shows the PSU in its case as I pulled it out of the plug.

and this one shows the contents of the PSU when the case lid is removed. It looks like the sort of breadboard setup I last saw in a 1960s transistor radio built by my uncle. Certainly not of the quality I would expect from a major electronics company. Mind you, the new replacement unit (see below) is not /that/ much better.

This final picture shows the new PSU installed in what is actually the top half of the plug.

The plug is now back together, and to my relief it booted fine first time. But I’m now not at all confident that it will last. And since one of my earliest slugs is now becoming a little unstable, I’m looking for a replacement for both.

Continue reading »]]> Today, 18 January 2012, parts of the ‘net went deliberately dark in combined opposition to the SOPA (A Bill to:“promote prosperity, creativity, entrepreneurship, and innovation by combating the theft of U.S. property, and for other purposes.” I love the “other purposes” bit.) and PIPA bills currently being considered by the US legislative machinery. These two bills are classic examples of badly thought through legislation developed in response to lobby group pressure to protect an existing business model which is failing. I don’t normally make political comment, but I find myself entirely in agreement with the sentiments expressed on the torproject site this morning.

When first attempting to view the tor site, readers are faced with this:

Clicking on the blacked out section you are taken to a copy of the 18 January blog posting which says:

“The Tor Project doesn’t usually get involved with U.S. copyright debates. But SOPA and PIPA (the House’s “Stop Online Piracy Act” and the Senate’s “Protect-IP Act”) go beyond enforcement of copyright. These copyright bills would strain the infrastructure of the Internet, on which many free communications — anonymous or identified — depend. Originally, the bills proposed that so-called “rogue sites” should be blocked through the Internet’s Domain Name System (DNS). That would have broken DNSSEC security and shared U.S. censorship tactics with those of China’s “great firewall.”

Now, while we hear that DNS-blocking is off the table, the bills remain threatening to the network of intermediaries who carry online speech. Most critically to Tor, SOPA contained a provision forbidding “circumvention” of court-ordered blocking that was written broadly enough that it could apply to Tor — which helps its users to “circumvent” local-network censorship. Further, both bills broaden the reach of intermediary liability, to hold conduits and search engines liable for user-supplied infringement. The private rights of action and “safe harbors” could force or encourage providers to censor well beyond the current DMCA’s “notice and takedown” provision (of which Chilling Effects documents numerous burdens and abuses).”

Jimmy Wales, the founder of wikipedia has been a particularly vocal critic of the impending legislation. Today, english speaking users of wikipedia were greeted with the following page:

There is plenty of discussion about the effects of SOPA and PIPA on-line in the usual technical fora (see wired, for example) but as El Reg said about a week ago, the mainstream media in the US have been largely quiet about the implications of the Bills should they ever become law.

I wonder why.

Continue reading »]]> As I have mentioned in other posts here, I run my own mail server on one of my VMs. I do this for a variety of reasons, but the main one is that I like to control my own network destiny. Back in October last year I noticed an interesting change in my mail experience with my HTC mobile (actually my wife first noticed it and blamed me, assuming that I had “twiddled with something” as she put it). Heaven forfend.

My mail setup is postfix/dovecot with SASL authentication and TLS protecting the mail authentication exchange. My X509 certs are self generated (and so not signed by any CA). I pick up mail over IMAPS (when mobile) and POP3S (at home – for perverse reasons of history I like to actually download mail to my main desktop over POP3 and archive it to two separate NAS backups). I send via the standard SMTP port 25 but require authentication and protect the exchange with TLS.

My mail had been working fine ever since I set it up some years ago, but as I said, back in October my wife complained that she could no longer send email from her HTC mobile (we both use t-mobile as the network provider). She was at work at the time so away from my home network. Both our phones are setup to use use wifi for connectivity where it is available (as it is at home of course). When my wife complained I checked my phone and it could send and receive without problem. But when I switched wifi off, thus forcing the data connection though the mobile network, I got the same problem as my wife reported. On checking my mail server logs I read this:

postfix/smtpd[28089]: connect from unknown[149.254.186.120]
postfix/smtpd[28089]: warning: network_biopair_interop: error reading 11 bytes from the network: Connection reset by peer
postfix/smtpd[28089]: SSL_accept error from unknown[149.254.186.120]:-1
postfix/smtpd[28089]: lost connection after STARTTLS from unknown[149.254.186.120]
postfix/smtpd[28089]: disconnect from unknown[149.254.186.120]

(the ip address is one of t-mobile’s servers on their “TMUK-WBR-N2″ network)

Everything I could find about that sort of message suggested that the client was tearing down the connection because there was something wrong with the TLS handshake and it was not trusted. Checking earlier logs, I found that t-mobile’s address had apparently changed (to the address above) recently. So I assumed that some recent network change following the Orange/T-mobile merger had been badly managed and all would be well again as soon as the problem was spotted. Wrong. It persisted. So I had to investigate further. As part of my investigation of the error, I tried moving mail from port 25 to 587 (submission) because that sometimes gets around the problem of ISPs blocking, or otherwise interfering, with outbound connections from their networks to port 25, No deal. In fact it looked as if t-mobile were blocking all connections to port 587 (I assumed a whitelisting policy block, or again, a cockup).

So, the scenario was: mail works when connecting over wifi and using my domestic ISP’s network, but doesn’t when using t-mobile’s 3G network. Symptoms point to a lack of trust in the TLS handshake. Tentative conclusion? There is an SSL/TLS proxy somewhere in the mobile operator’s chain. That proxy sucessfully negotiates with our phones, but when it gets my self certified X509 cert from the server. it can’t authenticate it and decides that the connection is untrusted so tears it down. My server sees this as the client (my phone) tearing down the connection. [As it turns out, this conclusion was completely wrong, but hey].

I said in an email at the time to a friend whose advice I was seeking, “I suspect cockup rather than outright conspiracy, but if my telco is dumb enough to stick a MITM ssl proxy in my mail chain, they really ought to have thought about handling self signed certs a little better. Otherwise it sort of gives the game away.”

In response, he very sensibly suggested that I should run a sniffer on the server and check what was going on. At that time, I was busy doing something else so I didn’t. And because the problem was intermittent (and my wife stopped complaining) I never got around to properly investigating further. (I should explain that I rarely send mail from my mobile nowadays. I just read mail there and wait until I get home to a decent keyboard and can reply to whatever needs handling from there. My wife just gave up bothering to try).

I should have persisted because of course I wasn’t the only one to experience this problem.

Back in November, a member of the t-mobile discussion forum called “dpg” posted a message complaining that he could not connect to port 587 over t-mobile’s 3G network. In response, a member of the t-mobile forum team suggested that dpg might reconfigure his email so that it was relayed via t-mobile’s own SMTP server. Not unreasonably, dpg didn’t think this was an acceptable response – not least because he would then have to send his email in clear. He then posted again saying that “the TLS handshake fails when the mail client receives a TCP packet with the reset (RST) flag set.” (This is a bad thing (TM). Further, he posted again saying that he had set up his own mail server and repeated earlier tests so that he could see both ends of the connection. At the client side he posted mail from his laptop tethered to his phone which was connected to the t-mobile 3G network. By running sniffers at both ends of the connection he was able to prove to his own satisfaction that something in the t-mobile network was sending a RST and tearing down any connection when a STARTTLS was seen. Again, in a later post in response to one from another poster who apparently manages several mail servers and had been looking at the same issue for a client, dpg says:

“I must say I’m not too pleased to discover that T-Mobile may be snooping all traffic to check for SMTP messages. I have demonstrated that they may be doing this by running a SMTP server on a non-standard port and finding that they still sent TCP reset packets during TLS negotiation – so they must be examining all packets and not just those destined for TCP ports 25 and 587.

I’m also not that keen on T-Mobile spoofing/forging TCP resets. This is the sort of tactic resorted to by the Great Firewall of China (http://www.lightbluetouchpaper.org/2006/06/27/ignoring-the-great-firewall-of-china/) and also by Comcast back in 2007 (https://www.eff.org/wp/packet-forgery-isps-report-comcast-affair) until the US FCC told them to stop (http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-08-183A1.pdf).”

Then 9 days ago, dpg posted this message:

“I finally got to the bottom of this. I was contacted by T-Mobile technical support today and was told that they are now actively looking for and blocking any TLS-secured SMTP sessions. So, it is a deliberate policy after all, despite what the support staff have been saying on here, twitter and on 150. They told me it is something they have been rolling out over the last three months – which explains why it was intermittent and dependent on IP address and APN to begin with.

So, the only options for sending email over T-Mobile’s network are:
- unencrypted but authenticated SMTP (usually on port 25)
- SSL-encrypted SMTP (usually on port 465)
- unauthenticated and unencrypted email to smtp.t-email.co.uk

TLS-encrypted SMTP sessions are always blocked whether or not they are on the default port of 587.”

(As an aside, there is, of course, another alternative. You can ditch t-mobile as your provider and pick one which doesn’t use DPI to screw your connections. You pays your money….)

Following this, a new poster called “mickeyc” said this:

“I’ve been experiencing this exact same problem. I run my own mail server which has SSL on port 465 and also uses TLS on port 587. I used wireshark to confirm that the RST packets are being spoofed. This is the exact same technology used by “The Great Firewall of China”. I have two t-mobile sims. One is about a year old and doesn’t experience this problem (yet), one is a few weeks old and does.”

He went to say that he had also experienced problems with his OpenVPN connections and would be blogging about the problem (damned bloggers get everywhere) and sure enough, Mike Cardwell did so at grepular.com. That blog post is worth reading because it has an interesting set of comments and responses from Mike appended.

Mike’s post seems to have been picked up by a few others (El Reg has one, and as Mike himself has pointed out, boingboing.net has a particularly OTT post which seems to say that he is accusing t-mobile of something he clearly isn’t.

Finally, two days ago, dpg posted this:

“I’m pleased to report that T-Mobile is no longer blocking TLS-secured email on port 587. As a follow-up to an email exchange over the Christmas period I was contacted today to say that, contrary to what I had been told previously, it was never a deliberate policy to block TLS-secured outgoing email. There was a problem with some equipment after all, which was resolved yesterday.”

I tried again myself today. Initially, I got the same old symptoms (“lost connection after STARTTLS”) then I rebooted my ‘phone and lo and behold I could send email.

Like Mike, I tend to the cockup over conspiracy theory, it’s more likely for one thing. IANAL, but it seems to me that it would be in breach of RIPA part I, Unlawful Interception, for the telco to intercept my SMTP traffic in the way it seems to have been doing. That is not likely to be a deliberate act by a major UK mobile network provider.

But I’ll still keep an eye on things.

Continue reading »]]> When I first tested running a tails mirror on one of my VMs, the traffic level reported by vnstat ran at around 20-30 GiB per day. I figured I could live with that because it meant that my total monthly traffic would be unlikely to exceed my monthly 1TB allowance. However, when I checked the stats on that server last week (around the 9th of Jan) I found that I was shipping out around 150 GiB per day and vnstat was predicting a monthly total of close to 3 TB. As the tails admins said when I told them that I would have to shut off the mirror on that VM while I sorted something, “Ooops”. Ooops indeed. I couldn’t chance a massive bill for exceeding my bandwidth allowance by quite that much. The actual stats for 4, 5, 6, 7, 8 and 9 January before I pulled the plug were: 34.23 GiB, 69.14 GiB, 178.31 GiB, 131.68 GiB, 99.05 GiB and 133.27 Gib. It turns out that tails 0.10 was released on 4 January and I hadn’t been prepared. A lesson learned.

Having shut down and had the DNS round robin amended, I attended to finding some way of throttling my traffic so that I could live within my allowance whilst still providing a useful mirror. I scratched my head for a while before stumbling on the obvious, I should be throttling at application level. (Sometimes I find that I miss simple answers because I am looking for complicated ones).

I started out by assuming that I should be using tc and iptables mangling, or something like the userspace tool trickle, all of which looked horribly more complicated than the approach taken by tor (which allows you to simply set the acceptable bandwidth rate to some limit, plus set an accounting period maximum of some total transfer limit per day/week whatever). And of course it turns out that my webserver (lighttpd) allows something similar. Just set the server limit to some chosen max transfer rate and, if necessary, also impose a per IP max rate. The magic configuration file options are:

# limit server throughput to 3000 kbytes/sec (~30000 kbits/sec)
server.kbytes-per-second = 3000
#
# and limit individual connections to 50 kbytes (~500 kbits/sec) – NB. I don’t actually use this
# connection.kbytes-per-second = 50

I tested this by pulling a copy of the tails iso from one of my other VMs which has a high bandwidth connection and got acceptable (and expected) results. So now I can go back on-line later this month safe in the knowledge that I’m not going to blow all my bandwidth in one week.

Continue reading »]]> OK, yes, I know there are probably already a gazillion web pages on the ‘net explaining exactly how to do this, but I got caught out by a silly gotcha when I tried to do this a couple of days ago, so I thought I’d post a note.

Firstly, X is not exactly a secure protocol, nor is it easy to filter at NAT firewalls, so the ability to tunnel it over ssh is hugely welcome. In fact, ssh can be used to tunnel practically any other protocol you care to name, so it should be your first port of call should you wish to connect to a remote system using an insecure protocol. (I use it to wrap rsync for example).

I don’t run X on my VMs (there is no need, they don’t run desktop software) and I had not previously seen the need to run X based graphical programs on those servers. However, a couple of days ago I thought it would be really useful to run etherape on one particular remote server so that I could watch the traffic patterns. Normally I use iptraf (which is ncurses based) when I want to monitor network traffic in real time, but etherape is pretty cool and gives a nice graphical view of your network connections. But it runs on an X based gui.

So. I changed the remote server’s sshd_config to enable X forwarding (“X11Forwarding no” becomes “X11Forwarding yes”) and restarted sshd. On my desktop I similarly changed my local ssh_config file to allow X forwarding (“ForwardX11 no” becomes “ForwardX11 yes”) to obviate the need to use the -X switch on the command line. I then installed etherape on the remote server and fired it up only to get the message “Error: no display specified”. Sure enough “echo $DISPLAY” showed nothing. But I had thought (and everything I had read confirmed) that ssh should take care of setting the appropriate display when X11 forwarding was set.

So I then tried setting a display manually (export DISPLAY=localhost:10.0 on the remote server) and then got the response “Error: cannot open display: localhost:10.0″. So, still no deal. I spent some time scratching my head (and reading man pages) and sent off a query to my local Linux User group in parallel asking for advice. They were gentle with me.

The first, and rapid, response, said:

On the server:

sudo apt-get install xauth

Then disconnect and reconnect the client.

Jobs a good un.

Thank you Brett.

So the moral is, make sure that you have X authorisation working properly on the remote system (check for the existence of $HOME/.Xauthority) if you experience the same symptoms I did.

Continue reading »]]> A couple of weeks ago, I wrote about the problems I had with a TP-Link IP camera. Today I received a comment on that post from a guy called Luke in the TP-Link support team. In that response he apologises for the difficulties I had and promises to investigate further.

His response deserves as wide an audience as my original post, so I am drawing attention to it here.

Thank you Luke for taking the time to comment.

Continue reading »]]>  

Standalone IP cameras have come down in price quite remarkably over the past few years. It is now perfectly possible to get a camera for between £50.00 and £75.00, and this makes them attractive for anyone wanting to set up simple “home surveillance” systems. I bought one recently just to see what I could realistically do with such a beast. I chose the TP-Link TL-SC3130G,

which goes for around £60.00. I bought mine from amazon. I chose this particular camera because, on paper, it looked to have a good specification at a keen price point. According to the TP Link website, the camera’s highlights include:

• 54Mbps wireless connectivity brings flexible placement
• Bi-directional audio allows users to listen and talk remotely
• Excellent low light sensitivity ensures good video quality even in the dawn
• MPEG-4/MJPEG dual streams for simultaneous remote recording and local surveillance

plus an impressive list of protocol capabilities all in a reasonably compact and attractive hardware package.

When the camera arrived I was pleased to find that the hardware was indeed quite solid and attractive. Such a shame I can’t say anything good about the software though.

As you would expect, I had to first configure the camera over a wired link. By default the camera comes up on 192.168.1.10. The login credentials are the usual “admin/admin” – which is the first thing you should change, but sadly I’ll bet that few people bother. The web interface presents the user with a set of configuration menus on the left of the screen and an image taken from the camera towards the centre of the screen. The software assumes that the user has IE and ActiveX running so for those of us with more sensible setups, some of the configuration and control options on the camera (such as snapshot, zoom and audio volume control) are unavailable. No matter, the important thing from my point of view, and the reason I bought this camera rather than its slightly cheaper brother, the SC3130, is the supposed wireless capability. At first sight, the camera and network configuration options look surprisingly comprehensive. In fact, I’d go so far as to say that the list of options available might confuse a user who had little networking experience. For example, besides the obvious options to set new static IP addressing or change to DHCP, you can change HTTP, RTP and RTSP ports, set up multicast streaming, change the multicast address, change the ports used for video and audio streaming, set viewer authentication, set the camera to use PPPoE and dynamic DNS and even send users an alert via email containing the new network settings (such as IP address) should these change. Of course, in order to do so the user must first configure email on the camera. Altogether an impressive looking range of capabilities. Again, such a shame they don’t all work.

Annoyingly, the web interface sometimes simply refused to accept changes or the system reset the changes after reboot, I first noticed this when changing the camera’s clock setting to sync with the time on my PC. It simply refused. NTP worked eventually, but it tended to stop working for no apparent reason. But by far the worst fault was in the WiFi stack. WiFi configuration options were all accepted and it was soon possible to connect wirelessly both to configure the camera and to view either a video stream or a still image. However, as soon as the wired connection was removed, both interfaces went down. Nor was it possible to connect wirelessly if the camera was booted without a cable inserted. Now it is pretty pointless to have a WiFi camera that insists on having a wired connection present as well and I couldn’t believe that no-one had tested this so I assumed that there was some way to get the thing working. Besides I hate being beaten. So I spent what was, on reflection, a disproportionately silly amount of time playing with various configuration options (DHCP vs static addressing, various combinations of UPnP and no UPnP (which involved me changing my router configs as well), changing various network port numbers, all to no avail. I searched the manufacturer’s website in case there was a new firmware image I could try, but that was a waste of time because the image on the website (1.6.17 dated 29 October 2010) was older than the firmware on the camera (1.6.18 dated 17 March 2011).

After trying umpteen variations of settings, at one point the camera froze completely and refused to boot. I had to resort to a hardware reset to get the thing back up again. Here it got weirder still. The camera came back up on 192.168.1.97 and not the default 192.168.1.10 (I found it with a sniffer). God help the average punter trying to get this thing to work.

I sent it back, and amazon refunded my money. Do yourself a favour. Don’t even think about buying one.

Continue reading »]]> The UK Home Office launched a new crime statistics website today at www.police.uk. The site is supposed to show “Local crime and policing information for England and Wales”.

I’m not entirely convinced of the merit of the site in the first place (and can see all sorts of potential objections arising in some of the more rabid tabloid newspapers), but I thought I would try it out before making any form of judgement of my own. Unfortunately I’m not impressed.

The opening page of the new service invites the user to “Enter your postcode, town, village or street into the search box below, and get instant access to street-level crime maps and data, as well as details of your local policing team and beat meetings.”

I have tried various combinations of the suggestions, scaling outwards and upwards from my precise postcode to the whole of that part of the County in which I live. I was not reassured to get the following message:

Discussion elsewhere on the ‘net suggests that this result is not unusual. It appears to be a badly worded (or badly coded) response to an error condition resulting from system overload following the launch. At least I sincerely hope that is the case and we are not really completely devoid of policing services in the whole of South Norfolk.

Examination of the HTML source for the webpage generated suggests that the service is running on Amazon’s Web Services. Certainly some of pages are retrieved from S3 servers, and the IP address of the site appears to be on Amazon’s AWS (see dig and whois results below *). If the site is, as it appears to be, cloud based, then either the supplier (Rock Kitchen Harris, Leicester) or the Home Office has seriously undersized the requirement. Regardless of who is at fault here, there is an evident need to pull in some more resource pretty quickly. This should be a good test of the much vaunted flexibility of cloud based services such as Amazon’s EC2. I expect the service to be running quickly and cleanly by this time tomorrow.

* dig www.police.uk returns:

; <<>> DiG 9.6-ESV-R3 <<>> www.police.uk
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10557
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.police.uk. IN A

;; ANSWER SECTION:
www.police.uk. 1251 IN CNAME policeuk-167782603.eu-west-1.elb.amazonaws.com.
policeuk-167782603.eu-west-1.elb.amazonaws.com. 60 IN A 46.137.113.146

;; Query time: 268 msec
;; SERVER: 80.68.80.24#53(80.68.80.24)
;; WHEN: Tue Feb 1 14:16:23 2011
;; MSG SIZE rcvd: 107

and a whois lookup of 46.137.113.146 returns:

% Information related to ’46.137.0.0 – 46.137.127.255′

inetnum: 46.137.0.0 – 46.137.127.255
netname: AMAZON-EU-AWS
descr: Amazon Web Services, Elastic Compute Cloud, EC2, EU