Sunday, 22 January 2017

UBNT/Ubiquiti and iPhone and roaming not working

I have posted a few times on this - the issue is plain...

If I go to the toilet my iPhone stops working. Obviously everyone takes their phone to the toilet, don't they. It is not just me. Tell me it is not just me?

If I sit in the bath in the morning trying to catch up on twitter and FaceBook my iPhone stops working.

This is all about roaming between Access Points on the WiFi, when I roam between APs (I have 3 in the house) I lose connectivity. It is annoying.

This has varied from occasionally to damned annoying, depending on s/w versions. The latest code on the iPhone and Ubiquiti led me to turn off WiFi and read Twitter in the bath on 3G as I kept having to reset the WiFi. That really is the last straw.

Ubiquiti are now talking to me and working on it. Thank you.

We have tried many things, but the last few days I tried turning off the IPv6 on my LAN. Yes, that was strange. Most of what I do uses IPv6. Most of it will fall back to IPv4 (but not all). I have machines (e.g. my main Mac) with fixed IPv6 addresses but router set via RA, so that caused delays on access to all sorts of things. Turning off IPv6 is strange. It is, after all, the current version of IP. I'd be happier turning off IPv4. I have turned it back on now. Phew!

Initially it did not fix anything, but the iPhone still had IPv6 addresses even though RA was off. Looks like my RA code sent "infinite" life on prefixes on removing IPv6 RAs rather than zero - oops. Fixed. But proved RA itself is not the issue, it is the iPhone having IPv6 addresses.

Once it had only IPv4 addresses it worked, and roamed between APs seamlessly with no problems for 2 days!

So, is it an iPhone issue or a Ubiquiti issue? Hard to say. I do not know if "roaming between APs" has any "is this IP OK still" logic? Or what? I don't know enough of the protocols.

Many people have said they use Ubiquiti and se no issues. Ubiquiti have said a few people have issues, and they don't understand why. This could be it.

The good news is Ubiquiti are working on it - trying to reproduce the issue. I have offered a FireBrick that will send RAs for them to test. Let us hope this is close to the end of the issue. If it is iPhone, I hope they will raise with Apple.

If we can only solve this, the Ubiquiti are excellent APs at a sensible price.

Saturday, 21 January 2017

Barcode reader apps (iPhone)

Yes, OK barcodes are a hobby, but I have been looking at the different apps you can get on an iPhone. I imagine many are available for Android as well.

Firstly, I have to say this: Why the hell is reading barcodes not STANDARD in the camera function in the phone?

After all, it has face recognition - why not put a box around barcodes it sees and you poke the box and it reads the barcode and does something with it if it knows what it is. Why on earth does a phone like an iPhone need an "app" to read barcodes in the first place. Crazy. I can see merit in apps being able to hook in to that, registering URL schemes and so on to handle the barcodes you scan and do specific things, but why an app to read the barcodes in the first place. And then there are a million (exaggeration) different apps to choose - how does a user know which app to use?


i-nigma is an app that has been around for a long time, it is free, and it will read IEC16022 and IEC18004 (data matrix and QR) 2D codes as well as 1D barcodes of various sorts. If the content looks like a URL it opens that in a browser, or will link to things that register a URL scheme like otpauth for one time passwords, etc. It is quick and seems to work well. However, it seems to use a low resolution on the camera meaning it cannot read high density codes, and has its own decode logic which means it cannot handle some high end UTF-8 QR codes (e.g. pile of poo).

QR Reader for iPhone

This is quite a find! It is free (pay to remove small adverts), uses high resolution on the camera so can scan very large codes easily, is fast, reads 2D and 1D barcodes quickly. Like most apps it tries to make sense of the barcode, and will look up UPC/EAN product codes, and interpret WiFi setting barcodes and so on. It will use front and rear facing camera, zoom, and even scan images from photos you have taken. It even has a QR code generator!

However, the biggest feature of this is that you can tell it to feed the codes it reads in to a web site of your choice as an argument and display the page it gets. This means it can work as a front end for your own web based applications directly.

Seriously - that is awesome - I don't need to make a mobile app to do stuff with barcodes, I can just do something on my own web site. I am now thinking of all the things we can do with this, and we'll never have to buy a bar code reader again. At work we scan serial number of routers, for example, but we can do way more than just type in to the keyboard now, and we can handle 2D barcodes as well (we only have 1D scanners at present).

Most other readers

I have tried several others. Some are not free (ha!). Some will not read IEC16022 codes (Datamatrix). Some only do 1D barcodes. Some are packed with adverts. Most do try to link in to selling you the thing you have scanned in some way. But so far I have not found one as good as the QR Reader app.

If anyone knows any that are better, let me know...

Friday, 20 January 2017

On the TV again

Thanks to RT... Very brief inclusion in this clip, but it all helps get the message across.

Thursday, 19 January 2017

The Queen's cold

Gotta love iPhone suggested location
Obviously there is no way to know if it is the same virus from which the Queen has been suffering, but I, like so many people I know, have suffered from a particularly bad cold over the last few months. It is telling that she was publicly so ill as to not attend Christmas events.

I really am sick of it, and it has now been a month.

More than once (like today) I started to think it may be over now. It is mostly a cough, sometimes dry, sometimes coughing something up, but seems to have lots more in store than just a cough. I was tired, feverish, aching all over, to various degrees for the whole month.

I am not one to stop working for something like a cold, though I was trying to work from home even more than usual as no need to infect the office. Most of the time I was able to do some work, but quite a few days I could not even do that. I know some will cry "man flu", and I understand that, but this has been a real bugger.

A few times I have had to go to the office - two TV interviews in the last week. Thankfully recorded so they can edit out the coughing. As often is the case with a cough, if I stay still, don't talk to anyone, and work at home, I feel like things are going well. Go outside and change temperature, or start talking, and shit hits the fan.

I'd love to know how/why a virus can be so much more resilient than others. Clearly we win the battle - everyone I know who has had this, whether 3 weeks or 6 weeks or whatever, has "survived" it. So what makes one virus take so long to be defeated I wonder?

Even so, this really long bout of being ill is depressing. I have been taking paracetamol and sudafed regularly (at a bit below max dosage, as I do worry) for weeks now.

This week was extra special, on Tuesday I went to the office to meet a TV crew for Euronews. I had a coughing fit, and coughed so hard I pulled a muscle. I do not recall agony like this ever before, I was thinking I must have cracked a rib or something, I could not move, I could hardly breath, let alone talk. My staff were great, especially Andrew and Jimi, an ambulance was called. They got me on gas and air which helped. They concluded I had pulled something! After a couple of hours I was able to struggle though a TV interview thanks to a very patient TV crew before getting codeine and valium, which I then spent two days solid on. I could not lay down properly, ended up sort of propped up on my sofa to sort of sleep. To be honest, neither codeine nor valium seem to do much for me. Thankfully over the two days the pain has gradually reduced.

So, once again, I find myself hoping that this is close to the end. The muscle pain is mostly gone, or at least manageable. I have to be "careful" coughing, which is, in itself, strange.

Good luck to anyone else that has this - I know some that have had it as "an annoying cough" for many weeks and little more - well done for fighting it so well. Personally, I have been suffering. I suspect there are those way worse off than I, and you have my sympathies. Get well soon.

P.S. I discovered the ambulance crew were self employed working for a company that subcontracts the work from NHS, and so we like Uber drivers, even fined if they have too long a break. That is going to be the next uproar, I am sure. They were very good though.

Monday, 16 January 2017

Teaching us to suck eggs? BT?

We have a customer on a fibre to the cabinet (FTTC) service which has packet loss.

The red is loss, as measured by one second LCP echoes over the PPP link, and is often over 5%. Levels of random packet like this are severely impacting his ability to make use of the service.

The loss started at the exact moment BT did work on the circuit due to a major outage, so is clearly related.

This is the line before the outage, and you do not get much clearer than that - no loss. Same as every day before :-

This is the day the line came back after their major outage (which lasted two days) :-

And this is the next day, which looks much like every day since :-

It does not take a rocket scientist to see there is a problem there - periods of around 5% loss, sometimes more, most of the day, every day, since the outage.

And yes, that is start of OCTOBER 2016! BT have failed to fix the fault for that long!

Today we got this, and I am almost at a loss for words! Talk about teaching us to suck eggs!

Is the customer using a VPN? Data is transmitted in discrete units known as packets. When a network server is overloaded, these can get discarded. 
This is known as packet loss and results in slow loading game dynamics and graphics, or the unsatisfactory performance of a VPN connection.
In such circumstances, there isn't much which can be done to improve matters, as the cause is not associated with your PC or broadband service.

I'm really not happy about this, but the "there isn't much which can be done to improve matters" is just shocking. We have asked BT to confirm if they are stating, officially, that 5% loss on an idle line is considered "acceptable" for a GEA/FTTC service - we await the response.

They even go on to say :-

In the meantime can you ask the customer to run some traceroute and provide and this hopefully will aid us in seeing where in the network  the packet loss is occurring.
SPs engineers can use a "wire shark" which can detect packet loss at points in network.

This is after explaining that we can see the loss at the LCP level on the PPP link and providing access to and copies of graphs showing the loss over and over again! It is like dealing with Dory to find a fault called Nemo. We keep having to repeat ourselves.

There is one other small snag.

We are all used to the notion of "fibre" broadband not actually being "fibre" which is why this is "Fibre to the cabinet". BT sell this to us as "Fibre to the cabinet" and call it FTTC. It turns out this line is in fact "Microwave to the cabinet". A good idea, normally, but not as described, and clearly beyond BT to actually understand and fix.

This just highlights the problem with a clear definition of the service: We need a clear specification of levels of idle/random packet loss, idle latency and jitter, reliability/resyncs, min sync speeds up and down, and even throughout before loss/latency starts. Without these you can literally spend months bashing your head against a brick wall and having engineer after engineer sent (each potentially costing around £200).

P.S. Today we get "Openreach have completed the engineering checks on the Radio back-haul and discovered some issues with the Link.". Well, yes, we have said this from day one (113 days ago). How bloody annoying. Maybe we finally get it fixed now.

Saturday, 7 January 2017

Traffic management in A&A

A&A do not do much in the way of "traffic management"!

This was somewhat brought home recently when someone tried to sell Alex some DPI / traffic management system over linked-in seeming to think A&A would need some.

What he was selling was DPI (Deep Packet Inspection) systems that can "manage" various types of traffic. As he explained, this could "throttle" peer to peer traffic.

What was amusing is Alex tried to explain that we don't need that - one would only need such things to manage a congested link. We aim not to be the bottleneck and so not have congested links. This is hard work and there are always occasional exceptions from time to time, but the plan is that we have enough back-haul to carriers, core network, and links to peers and transit that normally we are not the bottleneck. Basically, we should not slow down at peak times.

Alex's tweet (here) showed the exchange, where the salesman did not quite understand how we work. I am pleased at the number of comments and retweets appreciating our stance on this.

From the discussion it is worth mentioning a couple of exceptions to the rule.

1. Denial of service attacks are where so much data is sent to a customer they have an unusable Internet link anyway. We take action in such cases not only to help the end user in question but everyone else on our network that could be affected. Such traffic is far from "normal" usage and not something our customer has asked for. We always reserve the right to protect the network as a whole. Thankfully this is rare.

2. Where the link to the customer is congested because of the capacity of that link to their line - here we do do some extremely "light" traffic management in that larger packets are dropped before smaller ones. We have to drop packets if the link is full! This is a very simple metric and needs no DPI. Large packets are a feature of bulk data transfer like TCP, which can adapt and slow down, but smaller packets are more likely interactive or VoIP or DNS which cannot adapt. This level of management, which we allow customers to control, allows VoIP to work in the face of large downloads. We offer customer options to manage this, so you have control.

Basically, that is it.

We have no need for Deep Packet Inspection traffic management. If someone wants to P2P filling links, then they can. Our tariffs all have some level of usage cap, even if in the terabytes, so if someone is "taking the piss" they will hit limits. Even so, with 1TB and 2TB monthly usage packages now, we are pretty accomodating even with non stop streaming video.

At the end of the day we should not care what you are doing and do not need DPI based traffic management systems! Well done Alex for explaining this.

Friday, 6 January 2017


I have been messing with barcodes most of my life - and I don't say that lightly! My first ever commercial software was when I was 15 or 16 and I did some bar code reading software for an RML 380-Z. It involved reading some simple character barcodes, and also EAN/UPC barcodes. All the timing was done in the processor based on a one bit input from a light pen / reader.

I learned about barcodes back then and have been messing about ever since in various ways.

There are two main types of barcodes, though, to be fair, only one has "bars". The two types are 1D or linear barcodes, and 2D barcodes. It is really misleading to call the 2D codes "barcodes" to be honest.

Linear barcodes

There are many types of linear, or 1D, barcodes. They are designed to be read by a wand or laser or reader which looks at a line across the barcode seeing black and white in specific timing or spacing.

Normally these need a quiet zone (usually white) before and after the code, and then have bars and spaces (bars being black and spaces being white) which are certain sizes. Some standards have simply thick and thin for these and thick could be different to simply twice the width of thin. In practice, using thick as 2 "units" and thin as 1 "unit" usually works even in such cases. Some systems have several thicknesses of bar and space, each a multiple of a basic unit size. This maps well on on to simple pixel graphics images.

One of the least efficient and most annoying of these is "code 39". This uses 5 (black) bars with 4 (white) spaces making a total of 9, of which (mostly) 3 are thick and the rest are thin. Thick can simply be twice the width of thin. Code39 allows 40 combinations of 3 from 9 being thick, which codes letters, numbers and a few symbols. The space between each character could be one thin space, or more. There are a set of special codes that are thin bars and thin spaces with one of the spaces thick giving 4 extra characters.

The beauty of such a system is that each character is a self contained sequence, and you can in fact make a font out of it. There are no inherent check digits. Each normal character is the same size. The codes start and end with "*" character. So it is very easy to construct, though very inefficient.

Another simple code that only uses thick and thin bars and spaces is ITF (Interleaved 2 of 5) which only codes numbers, and then only even number of digits. It is much more compact for numeric sequences. A common checksum is the LUHN checksum as used on credit card numbers. Each pair of digits is 5 bars and 5 spaces (interleaved) where 2 of the 5 are thick. This makes 10 combinations for digits 0-9.

We then get a tad more complex where we do not simply have thick and thin, but 1, 2, 3 or even 4 unit widths. The system used for retail product code marking UPC (Universal Product Code) and EAN (European Article Number) allows coding for products using a numeric value.

By using more different widths, this allows more code density. The format has specific additional control fields such as the two thin bars with thin space at start and end and in the middle. There is a standard checksum coding as well. This is coding specific 13 or 12 or 8 digit sequences only.

Another common linear code is codabar 128 - this uses multiple width bars and spaces (up to 4 units wide). It has special coding for pairs of digits to be efficient for numeric sequences, but allows for letters and numbers and symbols. It is probably the most dense and flexible 1D coding that you can use.

Like most systems for linear coding the barcodes all have consistent width (apart from special characters in code 39). This helps allow formatting of a specific number of digits or characters in a specific space.

Two dimensional codes

There are two main standards for 2D codes. These are not "barcodes" as they do not use "bars", instead they use patterns of pixels which are black or white. Both of these include forward error correction using Reed/Solomon coding. This means that defects errors printing and reading and can for many errors. Obviously the technology to read these is different - based on cameras rather than linear pens or laser scanners.

One standard is IEC16022 "DataMatrix". It is quite nice technically. It allows a number of different methods for encoding data optimised for numeric or alpha numeric and so on. It is used on postal systems in the UK quite a lot.

The other common 2D code is QR codes (IEC18004). These are, in my opinion, not as nice technically, and not as compact, but look "cooler" so are kind of winning the popular vote on such things. They have target squares within them that sort of look better. They do have different coding formats for numeric, alphanumeric, etc.


There are many 1D and 2D coding systems and some clever new colour systems even, and picking the right on is a good idea. You want something compact and with good error corrections and detection. It is a shame so many systems opt for the worst of 1D coding using code 39 fonts though, especially when the data is purely numeric and could be much better coded as ITF or codabar128.

P.S. My card ordering system allows you to create cards with any of the above bar coding systems. The Odeon card is an example.