Twisted Networking with an EE MiFi

Jan 1, 2018 / 0 comments

Life’s been busy for the past few months, so excuse the lack of posts. One reason for this is that I’ve moved house. Virgin were supposed to install a cable modem on November 11th, but at the time of writing currently have my install on hold (more on that in the future). As a result when we actually moved in mid-December there was no broadband available. I’d noticed Currys were doing a deal on an EE 4GEE WiFi Mini - £4.99 for the device and then £12.50/month for 20GB on a 30 day rolling contract. Seemed like a good stopgap measure even if it wasn’t going to be enough for streaming video. I was pleasantly surprised to find it supported IPv6 out of the box - all clients get a globally routed IPv6 address (though it’s firewalled so you can’t connect back in; I guess this makes sense but it would be nice to be able to allow things through). EE are also making use of DNS64 + NAT64, falling back to standard CGNAT when the devices don’t support that.

All well and good, but part of the problem in the new place is a general lack of mobile reception in some rooms (foil backed internal insulation doesn’t help). So the MiFi is at the top of the house, where it gets a couple of bars of 4G reception and sits directly above the living room and bedroom. Coverage in those rooms is fine, but the kitchen is at the back of the house through a couple of solid brick walls and the WiFi ends up extremely weak there. Additionally my Honor 7 struggles to get a 3 signal in that room (my aging Nexus 7, also on 3, does fine, so it seems more likely to be the Honor 7 at fault here). I’ve been busy with various other bits over the Christmas period, but with broadband hopefully arriving in the new year I decided it was time to sort out my UniFi to handle coverage in the kitchen.

The long term plan is cabling around the house, but that turned out to be harder than expected (chipboard flooring and existing cabling not being in conduit ruled out the easy options, so there needs to be an external run from the top to the bottom). There is a meter/boiler room which is reasonably central and thus a logical place for cable termination and an access point to live. So I mounted the UniFi there, on the wall closest to the kitchen. Now I needed to get it connected to the MiFi, which was still upstairs. Luckily I have a couple of PowerLine adaptors I was using at the old place, so those provided a network link between the locations. The only remaining problem was that the 4GEE doesn’t have ethernet. What it does have is USB, and it presents as a USB RNDIS network interface. I had a spare DGN3500 lying around, so I upgraded it to the latest LEDE, installed kmod-usb-net-rndis and usb-modeswitch and then had a usb0 network device. I bridged this with eth0.1 - I want clients to talk to the 4GEE DHCP server so they can roam between the 2 APs, and I want the IPv6 configuration to work on both APs as well. I did have to change the IP on the DGN3500 as well - it defaulted to 192.168.1.1 which is what the 4GEE uses. Switching it to a static 192.168.1.2 ensures I can still get to it when the 4GEE isn’t active and prevents conflicts.

The whole thing ends up looking like the following (I fought Inkscape + Dia for a bit, but ASCII art turned out to be the easiest option):

/----------\       +-------+       +--------------+            +------------+
| Internet |--LTE--| EE 4G |--USB--|   DGN3500    |--Ethernet--| TL-PA9020P |
|          |       | MiFi  |       | LEDE 17.01.4 |            | PowerLine  |
\----------/       +-------+       +--------------+            +------------+
                       |                                              |
                      WiFi                                            |
                       |                                              |
                  +---------+                                         |
                  | Clients |                                     Ring Main
                  +---------+                                         |
                       |                                              |
                      WiFi                                            |
                       |                                              |
                  +--------+            +----------+            +------------+
                  | UniFi  |--Ethernet--|   PoE    |--Ethernet--| TL-PA9020P |
                  | AC Pro |            | Injector |            | PowerLine  |
                  +--------+            +----------+            +------------+

It feels a bit overly twisted for use with just a 4G connection, but various bits will be reusable when broadband finally arrives.

C, floating point, and help!

Aug 31, 2017 / 0 comments

Floating point is a pain. I know this. But I recently took over the sigrok packages in Debian and as part of updating to the latest libsigkrok4 library enabled the post compilation tests. Which promptly failed on i386. Some narrowing down of the problem leads to the following test case (which fails on both gcc-6 under Debian/Stretch and gcc-7 on Debian/Testing):

#include <inttypes.h>
#include <stdio.h>
#include <stdint.h>

int main(int argc, char *argv[])
{
        printf("%" PRIu64 "\n", (uint64_t)((1.034567) * (uint64_t)(1000000ULL)));
}

We expect to see 1.034567 printed out. On x86_64 we do:

$ arch
x86_64
$ gcc -Wall t.c -o t ; ./t
1034567

If we compile for 32-bit the result is also as expected:

$ gcc -Wall -m32 t.c -o t ; ./t
1034567

Where things get interesting is when we enable --std=c99:

$ gcc -Wall --std=c99 t.c -o t ; ./t
1034567
$ gcc -Wall -m32 --std=c99 t.c -o t ; ./t
1034566

What? It turns out all the cXX standards result in the last digit incorrectly being 6, while the gnuXX standards (gnu11 is apparently the default) result in the correct trailing 7. Is there some postfix I can add to the value to prevent the floating point truncation taking place? Or do I just have to accept this? It works fine on armel, so it’s not a simple 32/64 bit issue.

On my way home from OMGWTFBBQ

Aug 27, 2017 / 0 comments

I started writing this while sitting in Stansted on my way home from the annual UK Debian BBQ. I’m finally home now, after a great weekend catching up with folk. It’s a good social event for a bunch of Debian folk, and I’m very grateful that Steve and Jo continue to make it happen. These days there are also a number of generous companies chipping in towards the cost of food and drink, so thanks also to Codethink and QvarnLabs AB for the food, Collabora and Mythic Beasts for the beer and Chris for the coffee. And Rob for chasing us all for contributions to cover the rest.

I was trying to remember when the first one of these I attended was; trawling through mail logs there was a Cambridge meetup that ended up at Steve’s old place in April 2001, and we’ve consistently had the summer BBQ since 2004, but I’m not clear on what happened in between. Nonetheless it’s become a fixture in the calendar for those of us in the UK (and a number of people from further afield who regularly turn up). We’ve become a bit more sedate, but it’s good to always see a few new faces, drink some good beer (yay Milton), eat a lot and have some good conversations. This year also managed to get me a SheevaPlug so I could investigate #837989 - a bug with OpenOCD not being able to talk to the device. Turned out to be a channel configuration error in the move to new style FTDI support, so I’ve got that fixed locally and pushed the one line fix upstream as well.

Notes on upgrading from Jessie to Stretch

Aug 22, 2017 / 0 comments

I upgraded my last major machine from Jessie to Stretch last week. That machine was the one running the most services, but I’d made notes while updating various others to ensure it went smoothly. Below are the things I noted along the way, both for my own reference and in case they are of use to anyone else.

  • Roundcube with the sqlite3 backend stopped working after the upgrade; fix was to edit /etc/roundcube/debian-db-roundcube.php and change sqlite3:// to sqlite:// in the $config['db_dsnw'] line.
  • Dovecot no longer supports SSLv2 so had to remove !SSLv2 from the ssl_protocols list in /etc/dovecot/conf.d/10-ssl.conf
  • Duplicity now tries to do a mkdir so I had to change from the scp:// backend to the sftp:// backend in my backup scripts.
  • Needed to add needs_root_rights=yes to /etc/X11/Xwrapper.config so Kodi systemd unit could still start it on a new VT. Need to figure out how to get this working without the need for root.
  • Upgrading fail2ban would have been easier if I’d dropped my additions in /etc/fail2ban/jail.d/ rather than the master config. Fixed for next time.
  • ejabberd continues to be a pain; I do wonder if it’s worth running an XMPP server these days. I certainly don’t end up using it to talk to people myself.
  • Upgrading 1200+ packages takes a long time, even when the majority of them don’t have any questions to ask during the process.
  • PostgreSQL upgrades have got so much easier. pg_upgradecluster 9.4 main chugged away but did exactly what I needed.

Other than those points things were pretty smooth. Nice work by all those involved!

How to make a keyring

Jul 31, 2017 / 0 comments

Every month or two keyring-maint gets a comment about how a key update we say we’ve performed hasn’t actually made it to the active keyring, or a query about why the keyring is so out of date, or told that although a key has been sent to the HKP interface and that is showing the update as received it isn’t working when trying to upload to the Debian archive. It’s frustrating to have to deal with these queries, but the confusion is understandable. There are multiple public interfaces to the Debian keyrings and they’re not all equal. This post attempts to explain the interactions between them, and how I go about working with them as part of the keyring-maint team.

First, a diagram to show the different interfaces to the keyring and how they connect to each other:

keyring-maint workflow

Public interfaces

rsync: keyring.debian.org::keyrings

This is the most important public interface; it’s the one that the Debian infrastructure uses. It’s the canonical location of the active set of Debian keyrings and is what you should be using if you want the most up to date copy. The validity of the keyrings can be checked using the included sha512sums.txt file, which will be signed by whoever in keyring-maint did the last keyring update.

HKP interface: hkp://keyring.debian.org/

What you talk to with gpg --keyserver keyring.debian.org. Serves out the current keyrings, and accepts updates to any key it already knows about (allowing, for example, expiry updates, new subkeys + uids or new signatures without the need to file a ticket in RT or otherwise explicitly request it). Updates sent to this interface will be available via it within a few hours, but must be manually folded into the active keyring. This in general happens about once a month when preparing for a general update of the keyring; for example b490c1d5f075951e80b22641b2a133c725adaab8.

Why not do this automatically? Even though the site uses GnuPG to verify incoming updates there are still occasions we’ve seen bugs (such as #787046, where GnuPG would always import subkeys it didn’t understand, even when that subkey was already present). Also we don’t want to allow just any UID to be part of the keyring. It is thus useful to retain a final set of human based sanity checking for any update before it becomes part of the keyring proper.

Alioth/anonscm: https://anonscm.debian.org/git/keyring/keyring.git/

A public mirror of the git repository the keyring-maint team use to maintain the keyring. Every action is recorded here, and in general each commit should be a single action (such as adding a new key, doing a key replacement or moving a key between keyrings). Note that pulling in the updates sent via HKP count as a single action, rather than having a commit per key updated. This mirror is updated whenever a new keyring is made active (i.e. made available via the rsync interface). Until that point pending changes are kept private; we sometimes deal with information such as the fact someone has potentially had a key compromised that we don’t want to be public until we’ve actually disabled it. Every “keyring push” (as we refer to the process of making a new keyring active) is tagged with the date it was performed. Releases are also tagged with their codenames, to make it easy to do comparisons over time.

Debian archive

This is actually the least important public interface to the keyring, at least from the perspective of the keyring-maint team. No infrastructure makes use of it and while it’s mostly updated when a new keyring is made active we only make a concerted effort to do so when it is coming up to release. It’s provided as a convenience package rather than something which should be utilised for active verification of which keys are and aren’t currently part of the keyring.

Team interface

Master repository: kaufmann.debian.org:/srv/keyring.debian.org/master-keyring.git

The master git repository for keyring maintenance is stored on kaufmann.debian.org AKA keyring.debian.org. This system is centrally managed by DSA, with only DSA and keyring-maint having login rights to it. None of the actual maintenance work takes place here; it is a bare repo providing a central point for the members of keyring-maint to collaborate around.

Private interface

Private working clone

This is where all of the actual keyring work happens. I have a local clone of the repository from kaufmann on a personal machine. The key additions / changes I perform all happen here, and are then pushed to the master repository so that they’re visible to the rest of the team. When preparing to make a new keyring active the changes that have been sent to the HKP interface are copied from kaufmann via scp and folded in using the pull-updates script. The tree is assembled into keyrings with a simple make and some sanity tests performed using make test. If these are successful the sha512sums.txt file is signed using gpg --clearsign and the output copied over to kaufmann. update-keyrings is then called to update the active keyrings (both rsync + HKP). A git push public pushes the changes to the public repository on anonscm. Finally gbp buildpackage --git-builder='sbuild -d sid' tells git-buildpackage to use sbuild to build a package ready to be uploaded to the archive.

Hopefully that helps explain the different stages and outputs of keyring maintenance; I’m aware that it would be a good idea for this to exist somewhere on keyring.debian.org as well and will look at doing so.

subscribe via RSS