Euro profile locks - a few tips

Test door, lock sticks out a bit!
Euro profile locks are a doddle to change - it is literally one screw, and you can slide out the old lock and slide in the new locks. They are easy to buy, or order on-line. But a few quick tips:

  • You need to order the right size (inside and outside). This is the distance from the centre of the lock to the key slot each side. Usually available in 5mm steps. You want it just right, not sticking out, though good locks have a snap off part if someone does take pliers to it.
  • You can order keyed alike locks so they all have the same key, which can be very handy. Somehow people don't realise this!
  • There are loads of different quality and prices of locks.
  • You can have key both sides, or one side with a thumb turn, or just keyed one side and blank the other side even (half lock).

So, when we moved in, the first thing I did on day 1 was order new locks. Five of them. The house had all been recently re-done and the locks in the house already were all brand new, so a bit of a shame. But I wanted higher quality locks and did not want five different sets of keys (don't people know you can get locks that have the same key?).

Cheaper lock

I ordered like for like, the same size, and keyed both sides as that was what was in the house.

Unfortunately, after a little while we realised the choice of locks was wrong. You do not want keyed both sides. The reason is that the doors were all multipoint locks, and only locked by turning the key. Without that someone can literally walk in from the street (which has happened!). But this means you can only use the door from the inside if you have a key to unlock it. This means if there was a fire in the night when the doors are (obviously) locked, you need a key to get out. Remember the house originally had 5 sets of keys so you need to find the right key for the door by which you are trying to escape from a fire.

The short term fix, a key on a hook by the door, but that is far from ideal. Obviously.

Thumb turn on inside
So I ordered another complete set of locks (getting expensive now) with thumb turn on the inside. This means you can always lock or unlock the door easily from the inside without a key. Importantly it is not hard to unlock if trying to escape a fire. I actually disposed of the first set of locks as no use to me any more.

As some of you know, I have a complete door access control system and alarm system, but changing locks means a locksmith and time and money, so even though we have been here over a year I had not yet changed the locks. I was also researching the right lock for the job. Being a house, I really don't want an "exit button" and an "emergency break glass" by every door. I also wanted a "fail secure" so a power cut when we are away (long enough for battery to drain) does not leave all the doors unlocked. But I also want it "safe" so always possible to get out in a fire even when nothing is working electrically.

So the locks are Abloy EL560. I have been testing on my office/study door, meaning we now have six locks. This is great, it is fail secure (i.e. power fail is locked). But it can always be opened from the inside with the handle, and with a key. It also has signals so you know if opened by handle or key. This is great.

RFID reader
They are being installed in the rest of the house shortly, with my AES DESFire based readers to open from outside - nice and secure, and all links in to the alarm system.

However, if it was to be opened from outside using a key, I would want the alarm to know this, and disarm. The idea is we can trust a key. That is fine, I simply configure the system to disarm when the key is used. The system is very flexible and easy to configure for various types of lock.

Except... I have thumb turns on the locks on the inside. I don't need these now as you can open the door with the inside handle. But if I set the system to trust a key it trusts the thumb turn as well. Someone breaking in only has to turn the thumb turn on any door to disarm the alarm. So yes, obviously, it is not being configured to do that (yet). Indeed, one approach would be you have to enter a PIN on the keypad if not using a DESFire fob, even if you did use a key. Given how easily keys, even high security keys, can be copied or 3D printed, this may be sensible anyway.

The real answer is order locks keyed both sides, or even no key at all on the inside now.

I had a full set of locks just like that from when we first moved in. I have disposed of them. Arg! So another set of locks, six this time.

The moral is never throw anything away, ever!... I should know this already.



I should write up my concept for IP. This is literally stuff I dream of!

This is totally "if I had a time machine and could fix IP at the start" and very much not a "this is what we should move to". The time taken to get IPv6 deployed (over 50% in US now) shows this would never fly.

So my ideas is this...

IP addresses would have multiple levels, tagged at the binary level in some way to allow each level to be different number of bytes, and allow for multiple levels - perhaps top two bits say length of each level. The exact detail on this is not that important other than the fact it is "variable" in some way and a fixed pattern for any IP address to allow hardware to cope. The displayed format is not that important either, but probably a series of decimal numbers with a separator.

The top level of any target IP would be AS number. This is still routing packet by packet, not session routing. So an ISP level core router needs a simple top level binary decisions, is target outside our AS (so send to target AS) or within (so send to next level at byte X in packet). Yes, a router could have more than one role as more than one AS maybe, but in general it is simple. This is the sort of thing that can work at a hardware level in ASICs without too much issue. A CAM at top level for sending to AS and a CAM for "within my network (AS)" level.

Routers below this level are similar - "is it my network" do routing to "next level", or I send "upstream".

The concept is that the IP would actually go in levels from AS, to areas within an AS (if needed), to customers, to devices on customer networks, and even include "port" within the device. No need for NAT ever. Ultimately extensible at ISP or customer or network level and even within device to allow more ports (which can be an issue). Some limit on levels, and bits at each level, but more than enough.

Yes, TCP and UDP would change to not have a port where it is now, but part of the IP addressing.

As for allocation and RIRs, the allocation would be AS, and anyone with an AS controls as many IPs within that as they need.

More ports

Also, the session connection to a device would be a protocol in itself, for things like TCP (maybe even UDP and others), where the connection is to the device IP address (not a port level) but the payload includes a text port name. So https would be to port "https" not port 443. The reply would confirm the actual target IP (which includes port ID) to use for that connection. This allows target port to be unique without mapping the source IP/port and target IP/port normally needed to identify TCP socket within a device, even as a server. So simpler code (yes, check the IP/ports are right when you match it).

I also think that, unlike IPv6 which has a separate standard header for encryption (which therefore does not actually work for TLS we have now) I think TLS would be an option in the that SYN, along with port name. So port "http" can request TLS or not as a standard start of that session, with things like "use previous authentication session" as an option at the SYN level for faster connections. Ideally the application calls for TCP would make it very simple for any stream to be TLS or not with minimal coding overhead.

Multihoming at TCP level

Also, you need protocols like TCP to be multi-homed at the TCP level. Mobile phones can already do this to some extent. Connect to a name, not an IP, and it has multiple IPs, but allow the IPs to change during the session if needed, either end, as part of the connection protocol. This avoids the need for multihoming at the BGP level, and IPs can start with AS at a top level regardless.

No, not "IP is the route" - still routing path redundancy

Just to be clear, this is not saying the IP is the route to the end point, either. The route taken would be determined by routing protocols like BGP, and still have the alternative paths and redundancy that exists now to get to an AS, and within an AS. The only really difference is that core routing policy would almost certainly not allow announcements below the AS level, and hence keeping routing tables smaller. At present IPv4 does not work (by policy) smaller than a /24, for the same reasons. This just makes a really simple and obvious policy as the inter-AS level. It also means each AS only needs to originate one prefix (their AS) where as now they originate loads of separate blocks. That one prefix is extensible as much as they like. Indeed, the role of RIRs for IP management would pretty much vanish as having an AS would entitle you to allocate IPs under that AS, and originate routing for those IPs from that AS.

Comments and discussion welcome - but remember this is essentially just a thought exercise.

Alternatives rejected

This idea is still per packet - a totally different approach involves a connection based system. Establish a route over the internet as you connect and each point reports the connection id, and at the start you send to the local connection ID which is mapped to next hop connection ID. It could work but is a massive amount of "state" in the core, and I don't think a viable approach. Sorry.


Un-mapping CGNAT for IPv6, etc, with no overhead?

Some links are IPv4 CGNAT (notably Starlink at the moment).

What if I want IPv6.

Well, a simple approach is something like L2TP. The issue is that this is IPv6 over L2TP over UDP over IPv4 over CGNAT, and that means a much reduced MTU. This is not the end of the world if you know you have the reduced MTU, but a shame.

So would there be a way, even if only for outgoing sessions, to "tunnel" the IPv6 over IPv4 with zero overhead?

I think so. You need something in the Internet with IPv6 and something on the network that is stuck behind the IPv4 CGNAT end point.

The trick is that an IPv4 header is 20 bytes shorter. So if you reduced an IPv6 packet to IPv4 you get 20 bytes spare. You could tack something on to the end of the packet, and it should arrive at the tunnel endpoint via the CGNAT over IPv4.

So why not tack on the original external IPv6 address?

Yes, the source address would have to be tracked using NAT of the IPv6. And indeed, one could say you only need to tack on the original IPv6 at the start of the session as once you have created the NAT session you know both IPs involved.

Only catch is that TCP, for example, does not normally have extra data on SYN packets, so you have to check they arrive intact. One would hope so.

OK scrap that - I have a better idea :-)

You establish a link, maybe simply a TCP session, between your devices, outgoing via the CGNAT IPv4 to the far end. You use this to carry some control data. It could even be TLS with client cert, etc, for security.

Every outgoing session you create you send details over your TCP control link to the far end with details of that session, and it allocates an IPv4 UDP or TCP port for you and advises over the TCP control link. You can then send a new packet of the same type, e.g. TCP/UDP, to the far end. This then maps through to the IPv6 addresses you want to use, and the original ports. The CGNAT is then used to carry each new packet in or out over the session map each end.

What makes this even more clever is that you can do incoming new sessions as well. Obviously the IPv6 block being used has to be routed to the outside device. But simply carry the details of the new incoming connection over the TCP control link, and then have the NAT end start an outgoing session. Once established, that is used to carry the incoming packet and the outgoing reply packets. Yes, it could make for a slight odd TCP handshake, and that may need slight messing, e.g. send the SYN and SYN/ACK over TCP control link, but create an outgoing SYN and SYN/ACK exchange over the CGNAT outgoing, setting up the payload sequence numbers to match what the ongoing packets will be using.

This could allow full IPv6 both ways over an IPv4 only CGNAT, and not only would it have no overhead, allowing full MTU, it would actually use fewer 20 bytes per packet after the first control packets, and so be 1.3% more efficient on the wire. Technically you would lose per packet flow labels, but not a lot else. Of course things other than TCP and UDP would be a challenge, but could simply be mapped to look like UDP on the IPv4 if needed.

Of course the same could be done for IPv4, not saving 20 bytes per packet, but basically un-mapping the CGNAT at each end.

A zero overhead tunnel could save one of the classic IT/networking issues "MTU".


Starlink (2)

As I say, impressed, and to be honest even at £89/month inc VAT this is good value...

A doddle to install properly, some tree cover is unavoidable, but it works, and is happily doing 185Mb/s right now. Thanks to Jim to coming round with his drill for me.

The IPv4 is all CGNAT, and the IPv6 is not working yet or reliably. But this "just works" with A&A L2TP providing fixed IPv4 and IPv6 over it. And the latency makes this a very viable service at around 30ms. The package of a Starlink + FireBrick + A&A L2TP is pretty appealing, to be honest.

I really am pretty gobsmacked with how simple this all was to buy and get working - only caveat is "remember to get the Ethernet adaptor".


Security by annoyance

TOTP (Timed One Time Password) uses a secret which is a block of binary data. It suffers from being symmetric in that the server doing the checks, and the user (usually in an app on their phone) both have to know the same secret.

This presents the problem of getting this secret from one to the other. This story is about that journey.

A friend has a customer that wants to use some specific device they already have to provide OTP codes, and so has to send the secret to him to load on to the server.

Firstly, this is not quite how it is usually done - the usual way is the server makes a (new, random) secret, provides it to the customer (often as a QR code), who confirms receipt by entering the current OTP code. All done over https to be secure. Sorted.

But in this case the customer had the secret and wanted to send it.

As I say, the secret is just a small block of binary data, usually expressed as base32.

They sent, by email, an RFC6030 XML file, signed, with base64 coded encrypted secret in it. They also sent a simple 16 byte binary file which is the key, by email.

  • The base64 had to be converted to binary
  • The first 16 bytes extracted as IV
  • The remaining bytes stored, in binary, as the encrypted data
  • The IV had to be converted to hex for openssl command line
  • The 16 byte binary key file had to be converted to hex for openssl command line
  • openssl command line for AES-CBC was run and produced a binary decoded file
  • This had to be converted to base32 and loaded on the system as the secret

Was this secure?

Short answer: no. Both parts sent by email. Sent as separate email as obviously no hacker could possibly intercept both emails!!!


Almost any secure messaging app, e.g. signal, interactively whilst talking to the contact, sent as base32, and ideally as a disappearing message.

Or email the base32 over PGP encrypted email.

Or, well, almost anything else! Reading the Base32 over the phone FFS (though phone calls are rarely encrypted in transit over the network).

Storing the key?

One thing done on the back end system, apart from encrypted disk, etc, is to store the secret encrypted with the users password and salt. The password is not stored, only an argon2 hash. This means you can validate a password+totp code, but you cannot extract either the password or the TOTP key from a leaked copy of the database. I mean, yes, if someone can get a copy of the system and database, and trojan a user in to entering password, they can decode the TOTP as well, but that requires that extra user interaction step for each compromised user record.

P.S. what is my involvement?

Mostly helping my friend out to understand what he had to do. We are all cautious to ensure security, as you would expect.

Shelly Plus 1 GPIO

I am quite impressed with Shelly stuff anyway, but the new "Plus" range has allowed some interesting developments - as they use ESP32, which is the processor I use for my access and alarm system.

This has meant I am able to add bits to the alarm system much more simply than using my custom boards - anywhere I need just an input and/or just an output, for £15.99 I have a device that does the job. As an output it is a dry contact relay, and can be powered from 12V DC, or 24V-240V DC, or 110V-240V AC, so very flexible. Working with alarm system 12V DC or 24V DC is easy.

The input is run at "live" so for mains working needs a proper switch rated for mains such as a light switch (or one of the nice retractive switches). But working on alarm system 12V, a simple contact like a reed switch, or connection to a PIR is simple.

Obviously there are plenty of uses for the alarm system that needs more than one input or one output, but this is pretty useful. I even have one electrically locked door that is just using one for the lock and door open inputs as it is a door that does not need a fob, just needs to be locked when alarm armed, and detect door open as an alarm input ("access", causing alarm if armed).

My new EL560 locks on the house are great as no need for break glass or exit button as they open with the inside handle. But if you have any doors you keep unlocked during the day, you need a way to lock the doors at night. And that needs a button. Well, a Shelly Plus 1 is ideal. The light shows the doors have been locked.

I have also worked out the GPIO:-

  • GPIO0: Output for small LED (hard to see through case).
  • GPIO4: Input for SW signal (external switch) but needs configuring as pull down.
  • GPIO25: Input for small blue button on the case, but needs configuring as pull up.
  • GPIO26: Output to work relay.

There are also 6 external connection pins for programming (WARNING: THESE CAN BE LIVE):

  • GND
  • GPIO0
  • EN
  • 3V3
  • GPIO3 RX to shelly
  • GPIO1 TX from shelly
  • GPIO16


A bit more on air-con

I have been tweaking the air-con even more.

The control I have, basically, is to set the target temperature. I can set higher than now, and lower than now, and so make it turn on or off. But sensibly the air-con has controls. It does not run the compressor exactly to match what I say, it turns on for a minimum time, and there are also sorts of laggy effects for the temperature to react. Once compressor was on it stays cool a while and then fan blows cool for a while.

But it is getting silly.

For the last hour or so, even more so. This is not like ±0.1℃, it is more like ±0.05℃.

It is really good. But I was thinking, is this just that it is a cold day in Wales and the temperature happens to be settling where I want? At 22℃?

Well no, it is not that, looking at the power usage I see that it is turning on and off the compressor to work the temperature.

What I did was make it predict on a trend the next 2 minutes and turn on/off (set high/low target) based on that. And it was surprisingly good. This is the power usage showing it is fine tuning it to manage that. It is controlling the temperature to well within ±0.1℃ with no problem.


P.S. Just to clarify (as someone asked), this is not switching between heating and cooling (which would use more power), this is turning cooling on and off. It will switch to heating, but only after quite a while of temperature not coming back within range when off - and that can happen on some days in spring/autumn, but usually only once (each way) in the day. It also does automatic fan control.


Finally got one for testing, so first experiences.

1. Ordering was simple, but the site is one of these "slick modern sites" that are a pain to find any proper information - very easy to order - not so easy to realise an Ethernet adapter is separate. I have finally ordered one now.

2. Arrived very quickly (ordered 1st June, arrived 6th June, Jubilee in the middle).

3. Very very confusing re "account". The pages all have "sign in". I cannot find any "create account". What I did not know is that when I ordered by simply clicking "apple pay" and double clicking my phone (yes, very slick), is that this "created" an account using the apple pay email address. Once I worked that out I could use the "locked out" link to get a password. They could make that a lot clearer.

4. The instructions are simple, you plug it in and point at the sky and connect to wifi - it makes you then create an SSID/password, but then it works - Internet, several MB/s of it. NAT / IPv4, but yes, works. I now need to find somewhere vaguely sensible to put it - away from trees - may need a pole on the wall.

Of course the next steps are to get the Ethernet adaptor, and start working with FireBrick, see if I can get an IPv6 address; see if L2TP/IPsec/etc tunnels work over it; etc, etc... So R&D to do.

P.S. LOL, you can get to RT.com via Starlink :-)


New air-con, part 6

Well, well, well... I am impressed with 4 Seasons. They have only gone and sorted it.

This is the huge difference between this install and the previous Mitsubishi install from a different company. The customer service to get to the bottom of the problem and fix things.

Firstly, they did discuss this "anti-freeze" mode with Daikin, and whilst we all agreed that turning the fan down was silly, their point, which is very valid, is that it should not be happening at all. The refrigerant should not be getting so cold in the first place - this is a fault condition. That is what needs fixing.

Naturally I leapt to the conclusion that the issue was air-flow. But I was wrong. It seems the advice from Daikin at this point was right - they said to check the refrigerant. Well, pressures had been checked several times. But they suggested there was too little refrigerant. Indeed they suggested (counter intuitively) that we would see these lower temperatures if there was not enough refrigerant. That seems crazy, obviously.

Well, the installer, and I, were rather baffled, but the only thing that basically makes sense is that the system is (over) compensating for the lack of refrigerant, and that is how it ends up colder. And, of course, at the same time, it is unable to carry the heat away properly, so does not work as well.

The symptoms were pretty simple, when cooling, the refrigerant quickly goes down to as low as -10C, which it manages for a few minutes, and then the anti-freeze mode kicks in, and everything stops for 10 minutes, and overall things are not working well.

Now, the refrigerant is settling around 5C with no problem, and cool air is coming out, and the room is quickly cooling. It is not going negative at all, not even getting below 4C. It varies, and I have seen 5C to 8C, but that is "sane".

So what did we fix?

The fix was to completely drain down the system and refill it - simple as that. The big clue was that only 0.9kg of R32 came out. It should have had around 2.5kg. So he emptied, vac'd, and refilled. What I had not appreciated is that these systems come pre-filled for installation, so it seems that somehow it must have come without the right amount - some must have leaked in transit (not good). But the only real test he can do is pressures, and they were fine, so no clue that there was not the required amount of R32.

I'll add some graphs once we have a couple of days running to confirm. But I am sat here on a warm sunny day in a nice cool office. To say that I am over the moon is putting it mildly.

Side effects

A small side effect is that my Daikin wifi modules have way more monitoring and reporting and graphing now. I did loads of work to try and find what was actually happening, turning in to a seriously useful tool.

Next job is the new controller to work with it for when people want manual control but doing a better job than the normal Daikin controller.

Another small side effect is that my previous very tight temp control is now a little less tight as the effect of cooling (or heating) is much more and continues longer, so some level of predictive processing may be needed to manage tighter temp control. Should be pretty easy.


New air-con, part 5

After the fiasco of the previous air-con install, I was pleased with the new one, as you can see, and especially that I can make my WiFi controllers.

However, this month, as we have got warmer, I have run in to an issue. It was gradual, kicking in some afternoons. Initially it was something that fooled my temperature control, causing it to flip to heating and back to cooling...

I made the controller a bit more reactive, and fixed the flipping to heating, which was good, but still, in the afternoons, things were not right.

Will all this, over night was OK, mostly, but not always. After a while I realised the clue was in the power traces. Basically, after a while the unit switches in to a mode where it cycles, around 11 minutes on, and 11 minutes off, and a low fan when off too.

This is not enough to keep my office cool, and as we go on, it is getting worse and worse. It always starts the day OK for some minutes, but can go in to this mode right away after that.

This is crazy. I tried all sorts. I thought maybe it is the "econo" mode, which apparent limits cooling when below a certain temperature. I even fudged the temperature (replacing thermistor with a resistor) to test this, but no joy.

After a lot of testing for a couple of weeks, I have found it. It is an "anti freeze" mode. This is what they say (when you know what to google). Needless to say that Daikin support did not work this out for us.

What is especially annoying is that when it is pending 10 minutes with "thermostat off", it also puts the fan in what is shows as "LL" mode, i.e. slower than "L". Well, if it want to avoid the coil freezing you would think it should keep the fan at "H", but that is not what happens.

So now we know what it is, well what can I do?

For a start, I can try and pre-empt the anti-freeze logic, but that does not really solve the problem of why it is freezing the first place. It would have helped a lot if Daikin could have simply said "that looks like anti-freeze kicking in" when asked. Indeed, a fault/indicator on the controller or controller app would have helped so we knew the problem.

Even so, a way better outcome than previous air-con install, and some hope it will be "just working" soon.

Update: Clearly air-flow is the issue, but by preempting the anti-freeze I can keep it on full fan more and so have a slightly improved performance for now.

Part 6