Wifi fails with Ubiquiti, again

My in-laws have a large house and wanted to extend wifi coverage. Since its initial teething problems, my Ubiquiti AP AC Lite has mostly been working well (it’s hard to tell, since it works, but UniFi will no longer adopt or connect to it!), so I thought I’d give Ubiquiti a shot for sorting out this location too. They have an old Orange ADSL box made by Thomson dating from about 2008, so I figured just about anything would be an upgrade. My intention was to replace their existing wifi entirely and turn off the built-in wifi on the Orange box, much as I have done with my own setup, and hope that a better access point would provide sufficient coverage. For the access point I specced a UniFi AP AC LR “long range” model. Because I really don’t like the way that the Ubiquiti UniFi control software works when installed locally (and would be beyond my in-laws’ technical abilities to set up), I thought I’d also get a Cloud Key so that they didn’t need to worry about that, and that I could potentially use for remote access to their setup.

The kit is nicely packaged, but didn’t include any ethernet cabling nor a (1A, USB-C) power supply for the Cloud Key, so I popped out to get the necessary bits. First of all I wanted to set up the Cloud Key. The cloud key comes with a small printed setup guide, but the images on it are way too small to read – I found an online PDF version, but it turns out that even blown up the images are unreadable, but I could get a vague idea of what pages I was supposed to see. I inserted its SD card, plugged it into the Orange box via ethernet and its power supply and it started flashing. I then set about connecting to it from an old PC running Windows 7 and latest Chrome. After creating a Ubiquiti cloud account, the docs said I should be prompted to install the Ubiquiti Discovery Tool. This prompt did not happen. After some searching I found a link to it on the Chrome extension store and installed it manually – though it took me a while to realise that it is a standalone application and not a Chrome extension. At this point I was supposed to be shown the results of a network scan which would show me the Cloud Key and a “discover cloud key” switch. No such switch was shown in the scan page, but clicking a button labelled “Ubiquiti family” made the switch appear, but the search results remained resolutely empty. Searching through some forum posts suggested that this is a common problem, so I did a hard reset on the Cloud Key, and it finally appeared in the scan results with a “Pending” status beside it. Docs and forums said this should show an option to “adopt” it, but nothing happened after leaving it for a while. I realised I could connect to the CK directly via its own HTTP interface, but this was via its IP address using https and so inevitably required disabling security checks and ignoring multiple warnings in Chrome before I could get to it, but I successfully logged in using the default credentials.

Next I was shown a warning saying “SD card not installed” – when it was installed. I took it out and reinserted it a couple of times, restarted the Cloud Key again, but it didn’t come back up, so I pulled the power and tried again and it came back, and the card warning had gone away (though it didn’t show any status about its presence).

I know that Ubiquiti issues fairly regular firmware updates, so the first thing I did was check for updates, and sure enough, a Cloud Key update was available. Before doing that it complained that the Cloud Key had no backup – but the interface has no means of performing a backup, only a restore! I proceeded without. As well as the CK firmware, there was also a UniFi update available, so I updated that too. That installed smoothly, and restarted, but I was somewhat surprised to find that another upgrade was then available to both CK and UniFi, from 5.10 -> 5.12.66 -> 5.13.29 (with a reboot between each), and then no more updates were offered. I don’t know why this was not done in a single step. Again, no backup option was visible, but it still complained I didn’t have one.

Back in the Discovery tool I still could not see the CK. Forums reported more success using the UniFi iOS app, so I gave that a try, and found it, and adoption worked! After this had worked, it finally showed up in the discovery tool – so I gather the discovery tool’s discovery tools are no use for actually discovering things… However, if I tried to connect to it from the mobile app, I just received a cryptic error saying “api.env.cloudaccessenabled”, and it refused to go any further. Forums suggested a full factory reset, so I tried that, but it still didn’t work on the phone. The Discovery tool however was now showing the CK and also a demo account (which I deleted), so I could finally click the “Launch” button to start UniFi on the CK – only to be presented with a “Cannot check credentials” error. More forum searching and another hard reset later I was finally able to launch it and get into UniFi running on the CK. At this point I was offered yet another update to UniFi, this time to 5.13.32!

After about 5 hours of going round in circles, I could finally set up the access point (connected by ethernet to the same switch as the CK). It wanted its own firmware update, so I applied that. This part went relatively smoothly, adopting successfully in UniFi, though as I had found in my own setup, the AP sometimes drops off UniFi and has to be reconnected. I was able to do a network scan (which showed no contention on any channels – houses are far apart here and only 1 other network was visible), set up my SSID and password. I then reconnected to the new wifi network from my MacBook, and all seemed to work. Now to check the range…

The access point and Orange box are in a big room just next a courtyard; the aim was to get wifi coverage on the other side of the courtyard, about 15m away through one stone wall (very old, so no steel in it). The Orange box is under a desk behind another (steel) desk, and I had temporarily hung up the new AP on the wall, so the new AP had the advantage of slightly better placement and fewer obstructions. The Orange wifi dropped out at about 12m and the new AP’s network… did the same. Nowhere could I find a point at which I could remain connected to the new access point and not the old one, despite the “long range” designation, and the age of the old box. I also tried using my iPhone and a recent Android phone and saw similar results on all.

It’s clear that this performance is nowhere near what was expected (or at least hoped for) or needed, and that more access points / mesh antennas would be required to get this to reach the places its wanted, however, at this point I’d entirely lost confidence in the Ubiquiti systems, and we’d spent €200 for wifi that was no better than what we already had, it was getting too expensive, so all this hardware is going back.

The cloud account setup is also confusing – the relationship between the Cloud Key, UniFi, and the Ubiquiti account is messy, and there was no way that my non-technical in-laws would have coped with anything going wrong with it, which seemed likely to happen. So much for their slogan: “At last, simple IT that just works”.

For now we’ve decided we’re just giving up, and we’ll just put up with the limited, but reliable, stock wifi.

Ski equipment I have killed

I ski a lot, very hard, very fast. Not surprisingly, this takes its toll on equipment, and I thought I’d make a list of my kit that has met an untimely end.

  • Graves slalom skis: severely bent about 30cm from the tip.
  • Dynastar Vertical bump skis: tore out both rear bindings; discovered at the very highest point of Val Thorens…
  • Dynastar X9 skis: delaminated base, tore out edge on a rock.
  • Dynafit 3F race boots: Smashed rear shock absorber mechanism, rendering them unusable.
  • Nordica 990 boots: red rear-entry monsters! Smashed the retention flange in an awkward landing; boot cuff could fold flat backwards!
  • Salomon 957 composite bindings: heel piece exploded into little bits while skiing bumps.
  • Volant Chubb Ti skis: broke off tip on one ski, delaminated whole of the other one.
  • K2 Apache Recon skis: Broke tip, pulled out rear binding. These were terrible skis.
  • Diamir Fritschi Freeride bindings: not so much a breakage as exposing a design flaw; never land a jump on a traverse: the toe retention is not good enough and the boot will twist out. A second problem is that the heel can release if a ski is flexed very hard, e.g. crossing a ditch; This flaw was fixed in later models.
  • Diamir Fritschi Freeride bindings: Sheared screw holding rear binding onto the main tube.
  • Rossignol Scratch BC skis: The first skis I got into “extreme carving” on. They couldn’t take it: I rotated the edges out of the ski structure on both skis.
  • Fischer RC4 FIS SL skis: rotated the edges out through the base.
  • Salomon 997 bindings: Barrel of toe piece split, provoking early release at higher DIN settings: cost me a broken thumb.
  • Volkl AC50 Unlimited skis: I loved these skis, but I rotated the edges out through the base.
  • Dynastar Cham 97 skis: rotated the edges out through the base (seeing a pattern here!)
  • Salomon Quest Pro 130 boots: split shell
  • Elan Amphibio 78Ti skis: broke off tip protector, delaminated tail on one ski

Any ski manufacturers that want to know how strong their kit is, do get in touch and I’ll try my best to break it for you.

Ski stuff that is still alive despite my best efforts

  • ICE lightning carbon ski poles: These are awesome. Despite being carbon, they’re not light, but they are very stiff and very strong. Bought in Vail in 1998, still dead straight after 500+ ski days.
  • I never managed to kill my Salomon SX92E ski boots, but I did try very hard.

Tested to destruction: Salomon Quest Pro 130 Ski Boots

My previous ski boots were 2012 Dalbello Il Moro Ts. I loved these boots, but they were a bit big, the liners were getting packed out with age, and they were too narrow across the forefoot. I also wanted something that I could use for touring.

After much research on hybrid boots, I was attracted by Salamon’s Quest range. I picked up a pair of 2016 Quest Pro 130s, Salomon’s top-of-the-range hybrid freeride boot, at the end of the 2015/2016 ski season, and first skied on them at the start of the 2016/2017 season, so they are just coming up for the end of their third season.

Hybrid boots are a compromise, but I wasn’t quite ready for how much of a compromise they were.

Construction

The shells are made of Salomon’s “Custom Shell” plastic that is thermoformable – I was keen to make use of this to make sufficient space for my wide feet. The liners are Salomon’s high-end “My Custom Fit Race” model, which are mostly thermoformable, though not quite in Intuition territory. The net result is a boot that can be thermoformed with the liners in, which is a recipe for a good fit. That said, I’ve still found that they are a little tight across the forefoot, despite having that area punched out to some extent when I first got them fitted. I got moulded foot beds from a sports doctor in Chamonix that specialises in boot fitting, and they have been great.

The boot has 3 clips, which are well designed, with long levers to help do them up tight, and a very chunky booster strap, which makes up for the lack of a fourth clip to some extent. The middle clip has two different mounting positions, and I found the rear one made for much better fit and heel retention.

The traditional overlap design means that they are pretty difficult to get on and off. This is partly a result of the thicker plastic which is needed to get the 130 flex rating, but makes it harder to pull them open enough. This is one things Dalbello’s “Cabrio” design is plainly better at, and a different planet to my old Salomon SX92s, which I could put on do up perfectly in under 3 sec!

One big win for these boots is the weight – at 1.4Kg each, they are very light for high-performance piste boots, though still relatively heavy for touring.

On-piste performance

These boots have a very stiff 130 flex, which I’m fine with (I’m a very fast, aggressive skier), but they’re also very upright, and the two combined makes it difficult to get your weight forward far enough, and you have to fight the flex to bend the boot sufficiently; Maybe I just need to put on some weight! I found it difficult to get them tight enough to give full-on control without making my feet ache or go numb, but generally they were ok, though overall not a patch on my old Dalbellos. The upright stance also makes it harder to get low enough at very high speeds, resulting in your weight being too far back, which reduces control and can be quite scary! I think a softer flex, perhaps 110 or 120, would have worked better for me for this kind of boot as I like to have a lot of forward lean, but the upright stance is a fairly necessary part of the hybrid design compromise.

Touring performance

I’m not into ultra-lightweight or long-distance touring – I’m usually doing the up for the down, rather than to get somewhere, so weight isn’t a big concern, for either my skis or boots, but the light weight of these boots was a definite plus anyway. My touring skis are Wedze Samurais (178/99) with Tyrolia Adrenaline bindings. They are not bad – a bit flappy on the down, but ok on the up, great in soft snow, and the bindings are very solid and reliable (unlike my experiences with Diamir Fritschi Freerides, which I’ve broken 3 different ways). The boots have a walk mode, which is vital, and you can undo the top clip and strap to give maximum movement, and there’s an oversized pivot to keep the cuff laterally stiff while allowing easy fore & aft motion. The range of motion really isn’t quite enough though, and I found it resulted in quite an uncomfortable walking motion. When undone, the top clip sticks out and gets in the way of trouser legs. Despite the moulded liners and multiple precautions, I got terrible blisters on the sides of my heel on both feet – my first 2-hour outing was so bad that I ended up at the hospital needing antibiotics, and could barely walk, let alone ski, for a week! I have never had a pair of touring boots that didn’t give me blisters, so either I’ve always had the wrong boots, or my feet are weird. Overall I think I could live with the limited range of movement for tours of < 4 hours, but the blister thing was a showstopper. This has really prevented me from doing much touring at all, which is a shame as that’s 50% of the reason for having hybrid boots in the first place.

She canna take any more, Captain!

In the middle of the 2018-2019 season, I noticed that the right boot had developed a crack in the shell, right over the top of the foot in the overlap area.

The crack of doom

This is at exactly the point where an overlap boot has the most stress, but there is no concession to that in the design, and the plastic tapers to a thin flange that is relatively easy to tear. Because this is an integral part of the lower “clog” part of the boot, this is fatal and there’s no way to repair it. Of course this happened outside the 2 year guarantee period. I contacted Salomon, who said “our boots have a 2 year guarantee”, into which read the subtext “…because they disintegrate after that”. As a result, the right boot has a noticeably softer backwards flex which directly affects on-piste performance, and it’s entirely possible that the boot could fail catastrophically at some point. The crack has progressed rather too far for preventative measures (such as drilling a hole to stop it spreading further) to help much, so these will have to head to the bin and I’ll need to shell out for some new boots for next season; I won’t be buying Salomons.

WordPress Rewrites without .htaccess

It’s been known for many years that apache’s AllowOverride .htaccess files incur a performance hit, as every node on the path from the location hit to the document root need to be checked for .htaccess files and parsed. I’ve mostly avoided the whole issue by hosting on nginx instead, but I recently needed to host WP on Apache again and ran into this issue. Many places offer a snippet like this for rewrites from a .htaccess file:

RewriteEngine On
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ /index.php [NC,L]

This says:

  • If the request is for index.php, serve it as is.
  • If the request is for a file or folder that does not exist, serve index.php instead.
  • Implicitly, if the request is for a file or directory that does exist, serve that.

The problem is that while this will work in a .htaccess file, it won’t work in main apache config because REQUEST_FILENAME will just be a filename, not a whole path, so it’s unlikely to match. The solution to this is to prepend the document root:

RewriteEngine On
RewriteRule ^index.php$ - [L]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteRule ^.*$ /index.php [NC,L]

This took me a silly amount of time to solve. I found the critical info in this post, but I thought I’d clarify it here. HTH!