Speed and cadence sensors for you bicycle

▼ It happened again: I look at my bicycle handlebars to see how fast I'm going, but my bicycle computer was gone. This happens to me every three to four years. A goot moment to reconsider what information I really need during and after cycling. That would be:

• current distance
• current speed
• total distance per day / week / month

Current distance and speed are mostly relevant during longer rides. I could use my Apple Watch for this. But I don't want to be forced to always use my Apple Watch (and suffer the resulting power use for running the GPS the whole time) to record the total distance for all rides big and small. So for that, I need an extra sensor.

Bike speed sensors measure the revolutions of your wheel. That way they also record the total distance traveled. These days there are speed sensors that use bluetooth low energy (BLE) to transmit your speed/distance to another device. Like your phone. Many of these sensors also support Garmin's ANT+ protocol.

However, it turned out that the apps from makers of two of such sensors require you to create a login on their system. What kind of nonsense is that? The bizarre thing is that apparently these days this is so normal that reviews don't even mention it. Apart from hassle and privacy the problem I have with this is that if the maker discontinues their server, your device no longer works.

It's interesting that several of these sensors don't work with a little magnet on a spoke that the sensor sees flying by, but they're mounted around the hub of the wheel. So apparently they can count the revolutions of the wheel that way. This is of course a bit of a hassle when you need to replace a battery, especially if the sensor is mounted on the back wheel.

So I came back to Sigma Sport. I've had several of their BCs ("bicycle computer"?) over the years. For a long time, I didn't understand their naming convention. But it seems like they use two numbers: the first is the number of functions and the second the year a new platform was released. Currently that's 16 (2016). So the BC 14.16 has 14 functions, including recording elevation changes. The BC 16.16 (which I ordered) has a few more functions, including an ETA timer. That seems useful. (But it doesn't seem to have the elevation sensor.) The BC 23.16 has even more functions, but the screen gets pretty crowded/complex. See Sigma Sport's Youtube channel for more info.

Sigma Sport has bike computers where the sensor is connected to the mount on the handle bars with a wire and also wireless BCs. Those come in two varieties: ATS and STS. ATS is an analog protocol and is less reliable, but probably cheaper. STS is digital and has the advantage that one bike computer can be coupled with both a speed / distance sensor and a cadence sensor, and that for two different bikes. Your total distance is then recorded separately for both bikes. So I would definitely go for an STS model.

With the different models, like for instance the BC 16.16, you can buy the wired variant (just "BC 16.16"), the wireless variant with just a speed sensor ("BC 16.16 STS") or the wireless variant with a cadence sensor included ("BC 16.16 CAD").

Permalink - posted 2022-12-20 - 🇳🇱 Nederlandse versie

Has BGP routing security failed (yet)?

▼ In the thorough style we've come to expect from him, Geoff Huston tries to answer the question Is Secured Routing a Market Failure? Please read about the market aspect (and the limitations imposed on the IETF by big router vendors) in that article. His final conclusion is broader, through:

But mostly it's a failure because it does not deliver. Security solutions that offer only a thin veneer of the appearance of improvement while offering little in the way of improved defence against determined attack are perhaps worse than a placebo.

20 years ago I went to my first IETF meeting and there I learned about S-BGP and soBGP. It would take another almost ten years for RPKI to be standardized and fifteen years for the BGPSEC specification (which is largely S-BGP with the RPKI functionality removed) to be published. RPKI is gaining some traction but hasn't been able to stop at least some determined attackers. There are no production level implementations of BGPSEC after five years.

So why is that? True, if people would be prepared to pay extra for secure routing, we'd have it by now.

But I think the bigger issue is failure to understand the problem.

Looking at the valley-free model, we can observe that the right hand part of the network hierarchy is trusted by the sender of the routing updates / receiver of the packets, while the left hand side is trusted by the receiver of the routing updates / sender of the packets.

This hierarchy is pretty flat, so there's usually only a handful of networks on each side. So telling the world that those are networks you trust should be something we can do reasonably efficiently. Then, the only thing is to make sure that there are no network hops in the path that aren't trusted by either side.

Earlier this year, RFC 9234 "Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages" was published. This adds some information to BGP that lets it detect paths that aren't valley-free. The nice thing about this mechanism is that it protects two networks that implement the mechanism against mistakes made by networks that don't implement the mechanism.

We still need better mechanisms to thwart determined, purposeful attackers, but the good news is that we've made life a lot harder for those already. So even though we're not there yet when it comes to secured routing, it's not so much that we've failed, but that we are taking too much time to succeed.

Permalink - posted 2022-12-13

Smart home Matter and Thread misconceptions (or not?)

▼ I just saw a Youtube video kind of reviewing the new Thread smart home communication protocol. I'm not linking to it because it attributed a bunch of things to Thread that are Matter, unless I'm very much mistaken. (And the latter is certainly possible. Do your own research before buying new stuff.)

Matter is the new IP-based system that lets a smart home "ecosystems" such as Amazon Alexa, Google Home, Apple HomeKit and Samsung SmartThings talk to smart home accessories. Matter has two big advantages. The first one is that you're no longer locked into a single ecosystem or a limited number of ecosystems. Every ecosystem that supports Matter can control accessories that use Matter. Even better, multiple ecosystems can control the same accessories.

Thread, on the other hand, is simply a wireless protocol for talking to smart home accessories. Other protocols that accomplish the same thing are Zigbee, Z-Wave and bluetooth LE (low energy). Zigbee and Thread share the same underlying IEEE 802.15.4 mesh technology. The difference is that with Zigbee, the applications talk more directly to the IEEE 802.15.4 layer, while Thread uses 6LoWPAN to make IP(v6) communicate over the limited bandwidth and packet size 802.15.4 protocol efficiently.

So a smart home controller that uses Matter can simply use IP packets to talk to Thread-connected accessories the same way it would talk to Wi-Fi-connected accessories. The only extra thing needed for that is a "Thread border router" that connects to the Wi-Fi or Ethernet home network and also to the Thread mesh network.

No more bridges?

The big advantage of Thread over existing solutions is that once you get a Thread border router, you don't need any additional bridges or hubs like the Philips Hue bridge. The range will be better than bluetooth low energy (used by Eve Homekit accessories) and the reliability better than bluetooth or Wi-Fi due to the mesh networking, where accessories that are connected to mains power will forward packets for other accessories.

But it's unlikely that you'll be able to get rid of your existing bridges. For instance, the Hue bridge will get an update that implements Matter in the first half of 2023, but the individual Hue lights won't be updated to support Matter or Thread. Those lights and other Hue accessories will continue to talk to the Hue bridge using Zigbee. That is probably the right choice as moving all those individual lights, some 10 years old, to the new Thread protocol without losing current functionality would be a gargantuan task.

However, it's likely that a Thread border router will be your last new bridge. If that is going to be a separate device in the first place. The thread border router functionality is (or already has been) added to a lot of new devices, such as Apple's latest Homepod Mini and AppleTV 4K and the LG 2022 OLED TVs.

Hue, Thread and Matter

Signify (the maker of Hue) has said that they don't want to make light bulbs that support Matter, as the Hue bridge has an important role to fulfill in a Hue installation. However, their current lights do support bluetooth so you can control a few lights directly from the phone app without the need to buy the relatively expensive Hue bridge. I wonder if they'll move that functionality from bluetooth to Thread. Then again, this requires a Thread border router, so perhaps that doesn't help their "no bridge" use case.

Even though Hue won't support using Thread itself, it would be really great if Signify could add Thread border router functionality to the Hue bridge. As the bridge already supports IEEE 802.15.4 and apparently has some processing/memory capacity to spare, this should be possible...

What now?

Although the smart home future looks bright with Matter and Thread, for those of us who already have a bunch of accessories in a single ecosystem, these new standards won't really change anything. This is really all about the future when getting new smart home accessories might be as simple as to check for the Thread logo.

For now though, this probably means waiting a bit to see where different systems end up. Hue is pretty clear: the Hue bridge isn't going anywhere and (existing) lightbulbs won't get Thread. But the bridge will get a software update to get Matter support. So if you already have a Hue bridge, no need to stop buying Hue right now for products where the high price is justified.

But the cheap smart light bulb product space is probably going to be a war zone next year as those cheap bulbs gain Matter/Thread support and no longer require separate bridges.

Eve has already been building Thread support into its new Homekit accessories, so Eve is now more attractive as this allows you to remove the bluetooth performance/reliability bottleneck, and with Matter support it will leave the Homekit-only limitation behind. But again, there will probably cheap alternatives next year.

Unless you can get a killer deal, I wouldn't buy any cheaper brand non-Thread, non-Matter accessories. Better alternatives will become available in the relatively near future.

Permalink - posted 2022-12-03

Heeft echt maar 9% van de Nederlandse Google-gebruikers IPv6?

▼ Al heel wat jaren kijk ik af en toe naar deze grafiek waar we kunnen zien hoeveel Google-gebruikers de beschikking hebben over IPv6:

Langzaam maar zeker gaat het wereldgemiddelde richting de 50%. In Europa bereikte België die mijlpaal al een aantal jaren geleden, en ook bijvoorbeeld Duitsland en Frankrijk zijn over de helft. Maar een klein dorpje landje blijft dapper weerstand bieden tegen de oprukkende nieuwe versie van het Internet Protocol:

Twee weken geleden scoorde Nederland 14% en inmiddels is dit afgenomen tot 9%. Maar kan dat wel kloppen? Uit de statistieken voor IPv6-gebruik in Nederland van Facebook, Akamai en APNIC komt toch een heel ander beeld naar voren. Ik heb ze hier gecombineerd:

Met zo'n 37% doet Nederland het nog steeds aanmerkelijk slechter dan de buurlanden. De grafieken laten wel duidelijk verschillen zien, maar het verschil met Google is wel van een andere orde. Het lijkt erop dat er toch iets bijzonders aan de hand is met Google's IPv6-metingen in Nederland.

En wat zou kunnen verklaren dat Nederland het qua IPv6 slechter doet dan de buurlanden? Ik begrijp dat zowel Ziggo/Vodafone als KPN, de twee grote consumenten-ISPs in het land, IPv6 nu wel standaard aan zetten op hun laatste generatie modems, maar niet op de oudere modems die veel klanten nog gebruiken. Het is goed mogelijk dat in onze buurlanden de breedband-revolutie wat later op gang kwam zodat gebruikers daar gemiddeld nieuwere modems hebben. En waarschijnlijk voelen ISPs in Nederland de druk minder omdat Nederland relatief veel IPv4-adressen heeft. Een kleine vergelijking:

US: 1617.10 M = 4.85 IPv4-adressen per inwoner
DE:  123.73 M = 1.47 IPv4-adressen per inwoner
FR:   82.34 M = 1.21 IPv4-adressen per inwoner
NL:   49.96 M = 2.81 IPv4-adressen per inwoner
BE:   12.36 M = 1.06 IPv4-adressen per inwoner

Ik ben benieuwd hoe dit zich de komende tijd gaat ontwikkelen.

Permalink - posted 2022-12-01