Making EE run IPv4 only so that VPNs work

Apparently, EE (the UK mobile phone network) did “something” to their network at some time in between when I last used my VPNs with them and now-ish, apparently involving adding IPv6 which sometimes does not do IPv4 properly.

I don’t know the background of that, what the underlying situation is, or why it seems to cause my primary VPN (OpenVPN on a Raspberry Pi at home, to allow me to access home-LAN-only resources from external) to not work. Don’t work on my [Android] phone, also don’t work when using phone-as-hotspot for a laptop. Just can’t reach the IPv4-address referenced by an A-record somehow, so OpenVPN can’t connect.

It’s not that EE is “blocking VPNs”, but they’ve done something which breaks certain things, and VPNs (both homebrew and commercial service offerings, it seems) is one of the things that it breaks.

What I do know is that after various experimenting with suggestions from various sources on APN (Access Point Name) configurations, I found that following the APN Android instructions listed hereexactly and precisely – made stuff work for me again.

The specific details (Android-centric) listed on that page – just in case it ever goes away – are as follows (these relate to creating a new APN – find that dialog on your own):

Name: EE internet
APN: everywhere
Proxy: Not Required
Port: Not Required
Username: eesecure
Password: secure
Server: Not Required
MMSC: http://mms/
MMS proxy: 149.254.201.135
MMS port: 8080
MCC: 234
MNC: 30
Authentication type: Not Required or just use the default value shown.

When following various different guides and such which didn’t work for me, I had been ignoring the MMS-related stuff – on the basis that I don’t care about MMS. But when I followed exactly those details and put all of them in, it worked for me. I have no idea if including the MMS-related stuff is necessary for the APN to work properly or not – as soon as my settings started working, I stopped investigating.

The only variation to the settings above would be to find the “IPv6 and IPv4” thing and set that to “IPv4 only” – otherwise there’s not much point.

Template blank of “stay alert, control the virus, save lives”

(Download link for Zip of PNG, SVG and .afdesign files)

The transition of the UK / English government’s coronavirus messaging from the pretty clear “Stay Home” line (red and yellow branding) to the uselessly vague and aspirational “Stay Alert” with its green-and-yellow colour scheme is a terrible idea. It’s already being widely mocked with hot fresh memes, as is the fashion of these times.

I’ve looked, but failed to find, a meme-template blank of the original image. I even struggled to find high-res source material. It was all JPEGd to hell, everywhere I looked.

So, I did a bit of very basic image-bashing – flood-filling the (squishy JPEG-artefact-laden) regions of should-be-solid colour with actual solid colour, then got Inkscape to do a vector trace. Finally a very quick tidy-up of the worst of the wobbly lines in Affinity Designer.

This is not a pixel-perfect replica, but it’s as much as I could be bothered to make for my own use. I’m just throwing it out there in case it’s of help to anyone else.

That image may not be as “pure” of a PNG as might be desired, due to the use of image re-compression stuff on this website. A Zip archive is also available, containing the un-fiddled PNG blank, plus the vector in both SVG and Affinity Designer (.afdesign) formats.

Download the zip bundle of this template blank (containing PNG, SVG and Affinity Designer formats).

License: As I can’t find an official gov.uk direct source for the original graphic, I can’t figure out what license (if any) applies to that. So I’m not claiming any particular copyright-originality on my “turn it in to a clean blank meme template”. Call it Public Domain (as far as my input and work is concerned), but I would appreciate a credit or link back if you felt like it.

I cannot assert that this is a “perfect dedication to the Public Domain” because of the above-stated uncertainty about the original graphic upon which my work was based. I can state only that if my work in making the nice clean meme-blank is capable of copyright protection, I waive it. However, I cannot speak to any rights in the original composition.

When NextCloudPi is very badly out of date

I run an instance of the excellent NextCloud software locally on a Raspberry Pi, thanks to the equally excellent NextCloudPi distribution – which bundles all the fiddly bits together and provides an additional set of admin tools (collectively “NCP”, and with each of its sub-tools prefixed “nc-“) to assist with stuff like moving the data-storage location to an external USB drive.

However, I had been very foolish and not set up the automatic updates for the NCP software stack when I initially got everything up and running.

I had been running on NCP 0.6.something and NextCloud 13.something for quite a while, but the current-newest is NCP 1.2.something (and it is strongly recommended to have NCP perform the updates of NextCloud itself).

NCP’s self-updating process is not (currently) set up to cope with trying to bridge version-differences as big as the one I had built up, so it failed and left the NCP web panel in a slightly confused and misbehaving state. Didn’t break the NextCloud instance itself, which was nice, but I was still going to have to do some more-manual work to get things updating nicely.

If you want to follow how I got my outdated NextCloudPi system back to current, when the auto update couldn’t, read on!

1. Make Manual Backups

Using the NCP- tools via SSH, I did both a config-export (with nc-export-ncp) and a “backup not including data” (nc-backup style) to paths on my USB stick.

Then I shut down the Pi and used Win32DiskImager to make backup image files of both the microsd card AND the USB stick (to protect the file data from any chaos-risk) on my PC. I ended up not needing these backups but having them as a safety-net made me more confident.

2. Reflash with the current-newest img file

I downloaded the newest-current NextCloudPi Raspberry Pi img file, wrote it to the microsd card in the normal way and put it back in my Pi as well as connecting the USB data stick. Plugged it back in to power+ethernet, let it boot, find the IP address that DHCP has given it, and did the normal NCP first-run activation process (taking note of the generated passwords).

A little bit of manual re-setting of initial configuration in the NCP web panel (the thing that runs on port 4443) was in order – setting a static IP, activating SSH and setting an initial password, turning on automount for the USB stick.

I did try restoring the config-export but it did not seem to work – maybe the version-gap was too great, maybe the previous failed update-attempt had broken something, or most likely I don’t really understand what that is supposed to do.

After a reboot, the new blank-slate NextCloudPi was running on the expected IP address and I could move on to…

3. Restoring the backup of my NextCloud install

[To be clear, this section is talking about the backup made by the NCP nc-backup tool, which produced a “nextcloud-bkp_xxxxxxxx.tar” file.]

I chose to do the rest of the config-wrangling over SSH (I much prefer the free Bitvise SSH client for my from-Windows SSHing needs, rather than PuTTY that most people seem to use) from here, but it should be possible to do these steps in the NCP-web interface just as well – although it might be slightly tricky to know the exact filename of your prior backup if you haven’t SSH’d in.

Using the nice menu-based nc-config console tool, I invoked nc-restore and told it the path to my backup file from earlier (which was carefully stored on the usb stick, mounted at /media/USBdrive/, to ensure it was not lost when I reflashed the microsd card).

That worked fine! But, one thing I had not realised – the combination of nc-backup and nc-restore also backs up and restores the entire NextCloud software and not just the data/config. So now, I had a system with up-to-date NCP but the version 13 of NextCloud-itself that I had started with. But, still, that’s at least progress in the right direction.

4. Getting NextCloud up to current version

Once my NCP was up-to-date and the underlying OS-side stuff (expected packages and such) was also suitably modernised, all I needed to do was update from NextCloud 13.blah to 15.blah (being, at the time of writing, the newest version of NextCloud properly supported by NCP).

Initially, I tried using nc-update-nextcloud and accepting the default version-value of “0” which means “update to newest version”. Alas, that failed – NextCloud cannot skip over entire major versions when updating itself (going directly from 13-to-15 was not tolerated). Thankfully, the nc-update-nextcloud tool was clever enough to take an extra backup beforehand and flawlessly roll-back the failed upgrade.

OK, so I figured out I would need to instruct nc-update-nextcloud to take me to an intermediate version (14, in my case) first, and then update from that to the most-recent (15).

So, I found the NextCloud Changelog page, looked up the last release for NextCloud 14 (14.0.12) and asked nc-update-nextcloud for that version instead. Which worked perfectly.

Then once the upgrade to NC 14 had completed, I re-ran nc-update-nextcloud one last time, asked it for “0” as the version, and it was able to upgrade to NextCloud 15.0.6.1 with no further headaches.

(If I had put this task off much further, NC 16 would have become available for NextCloudPi and I would most likely have had to do an intermediate upgrade to NC 15 first. So if you’re in the same situation and have been neglecting your NextCloudPi, the sooner you get on with sorting it out, the easier it will be.)

5. Finishing up

At some point in this process I also re-configured letsencrypt, turned on ramlogs and some other NCP config options.

My NextCloud instance was happily back up and running, with all the existing users I had configured there and working (the desktop and mobile apps did not even need to be re-authenticated). All files present and correct, happy days!

As a final finishing touch, I made damn sure to enable both nc-autoupdate-nc and nc-autoupdate-ncp to hopefully stop me getting in to the same stupid mess again in the future. I think unattended-upgrades was enabled by default in the newer NCP install? Either that, or I turned that on too.

Adding in other icons to the Social menu

This WordPress theme came with the Jetpack plugin and uses Jetpack’s cute social-media menu feature – when you add links to your Twitter, Youtube, Github, etc. pages to the Social menu, they magically get turned in to pretty little icons which automatically match the site.

But if you add a service that isn’t supported by default, like Mixcloud, you get an ugly crummy generic link icon there instead. That’s no fun.

Those little icons are 24px-square SVG vectors and the image data is actually directly-present in the HTML source of the web page – they’re not PNG/GIF graphics being loaded as an addition request from the server.

Thankfully, a lovely Belgian called Jan has already written up how to solve this – his writeup presumes you’ve created a Child Theme, but luckily I already did that in my last post where I tweaked the colours in the theme I’m using.

To follow Jan’s guide, you will need the free Inkscape vector-graphics software and an understanding that SVG files are a type of XML document – which means you can edit them using a simple text editor. Even Notepad will do, although I used Visual Studio Code.

Both of the snippets of PHP code he provides need to go in the functions.php file of your current theme (creating a Child Theme if you’re using an “off the shelf” theme is probably a good idea, see my last post), changing the 'mastodon.social' => 'mastodon' etc. to suit the domain you want to match and the name you want to use for the icon.

You can copy+paste his sample SVG text in to a blank text file, copy-paste the <path> elements out of your logo SVGs (once you’ve sized them down nicely to 24px square and run them through his suggested optimiser tool) to replace the <path>s, change the symbol id to match the icon name you put in the PHP. Then just save that as something.svg and upload to the path described (you might need to create the assets/svg folders within your child theme).

Thanks Jan, that’s another little annoyance solved!

Tweaking colours in this WP theme

This blog is using a slightly customised version of the stock “Penscratch 2” theme provided by the Jetpack plugin – it’s pretty much exactly what I wanted, but made just slightly annoying by the choice of color for hyperlinks being hard-set (rather than accessible in the conveniently modern theme Customizer).

Rather than going back to the theme-browsing drawing board to find another theme I liked which had that particular feature built in, I did a tiny bit of digging + learning to find out what the “more proper” approach to dealing with a nearly-but-not-quite Theme would be.

WordPress has a concept of “Child Themes” – where you want to make a new theme based heavily on an existing one, with only certain adjustments. Perfect, all I wanted was to change some instances of one colour to another.

Even more helpfully, there’s a nice plugin called Child Theme Configurator which exists to smooth-over the process of creating a new Child Theme from one you’ve already got loaded and then make the desired changes. I only needed the Free version, although there is a premium-tier offering which can do more-involved stuff that I don’t need.

I’m not going to do a full hand-holding guide, as the website linked above has pretty decent documentation. Instead, here’s the bullet-points:

  • Install the Child Theme Configurator plugin
  • Go find it in the WP dashboard menu (Tools\Child Themes)
  • Create a new Child Theme based on the original one, accepting defaults for everything and ticking the box for “Copy Menus, Widgets and other Customizer Settings from the Parent Theme to the Child Theme
  • Go to the Property/Value tab, type “color” into the box (and select just “color” when it gives you a list of options)
  • Scroll down and find the colour I wanted to change (in my case, #1c7c7c) and click the Selectors link in that row
  • In the pop-up dialog that comes up, paste my desired new colour (#d00) in to the text field on each row and click Save as I go
  • Preview the changes (Appearance\Themes and use the Live Preview button on my new Child Theme)
  • Realise my changes had not looked after the Social-Media icons in the footer
  • Go back to the Child Theme Customiser, Property\Value tab and this time look for “background-color” and make the relevant color change that shows up there too
  • Preview again, be happy, activate my new Child Theme.

That hasn’t quite concluded all of the tweaks I want to make – right now, the social-menu icons in the footer don’t know what pretty icon to display for Mixcloud – but it’s a step in the right direction.