IPv4 price forecasts for 2022-2023

Having received more than a few requests for a followup post on IPv4 price projections, I finally found some time for it over the summer.

Here are updated plots of forecasts for the two coming years, using price information (in any allocation size) from ipv4.global (previously Hilco Streambank).

The dataset used for building the model is from Jan 31st 2017 to Aug 10th 2021. I’ve changed from SARIMAX to Facebook’s Prophet, as it seems to provide a more reliable and (for me) reasonable results.

Key points

Forecast says prices will increase by 100% in both ARIN and RIPE by March 2023.

Prices in ARIN and RIPE have nearly doubled so far in 2021.

Price for a /22 in RIPE increased by 23,1% from Jan 1st 2020 to Dec 31st 2020.

Other observations and commentary

One observation worth noting in the plot, is that something is going on in ARIN right now. After the summer prices have spiked (up to 60 USD per address!), and if this continues I think the forecast will be quite off.

I’ve also played a bit with the components that Prophet fits to make these forecasts, and one interesting thing shows up in the yearly seasonality plot for ARIN:

Forecast trend component for in-year seasonality in ARIN region

It would seem that, in ARIN, buying secondhand IPv4 space is cheapest early in the year, and most expensive after the summer. (In the RIPE dataset this is not the case)

Validation-wise I’ve run the usual cross validation and and attempted to get the fit as good as possible. When fitting separate models with 2 years of data from Feb 2017, moving forward 1 month per model, and using it to forecast 2 years into the future, validation showed that the forecasts were from 17% to 30% off on RIPE dataset and 5% to 23% off on the ARIN dataset. I’m sure there is more to be done here, but I haven’t had the chance to do a deep dive in it.

Review of previous projection

Looking back, my projections in Some IPv4 address price forecasting were made January 2019.

The average price per IPv4 address (across all scope sizes) was then slightly above 20 USD.

My projections were 24 USD for January 1st 2020, and 28 USD for January 1st 2021.

The actual (average) IPv4 price for January 1st 2020 was 21.515652 USD, and for January 1st 2021 it was 24.272414 USD.

The estimates were a bit on the high side, but then again the pandemic may have slowed down things. The lower and upper estimation bounds were wide enough that the real prices were well within.

Advertisement

BMW i3’s are tracking you

I bought a used BMW i3 2016 a couple of weeks back. It was time to replace the old car, and the benefits of having an EV in Oslo are very favorable.

New (or, 3 year old) cars come with new gadgets. This one is the “fully charged” edition, which means a nice sun roof, adaptive cruise control (cool!) and real time traffic updates on the navigation. It also has an app where you can turn on the heat in winter and probably much more I don’t know about yet.

Anyway, the first thing I do is to go into the menu system on the car and disable “GPS Tracking”. I think this is for the people that don’t know or remember where it is parked. If your partner uses it sometimes, and you park on public roads, I’m sure it has benefits.

I’m the sole driver, so I don’t need it, and I don’t fancy reporting the position to random germans ever so often. I turned it off, that is sorted then, right?

Well, no.

If you ask for a data archive (think google takeout for your car) from BMW CarData, it still shows position:

<telematicValue>
<name>Posisjon til kjøretøyet – geografisk lengde</name>
<value>10.762533</value>
<unit>WGS84</unit>
<fetchTimestamp>10.05.2019 10:01:00</fetchTimestamp>
<valueTimestamp>09.05.2019 17:49:55</valueTimestamp>
</telematicValue>

Yesterday May 9th, the “GPS Tracking” setting was definitively off.

If you look at the connecteddrive web app, they eagerly tell you tracking is off and that they think the car is in Helsinki.

 

This is the position reported in the data archive, shown on a map:

The position is accurate, this is where my car was parked last night.

This is not ok.

 

Update: There is a thread on this on elbilforum: https://elbilforum.no/index.php?topic=46334.0

Some IPv4 address price forecasting

I spent some time playing around with forecasting second-hand IPv4 range prices the other day.

ARIN is the most liquid, so the price development is best seen there:

RIPE has a worse fit, but shows the same trend:

I’m wondering if there will be an IPv6 inflection point, where everyone that is hoarding IPv4 now decides enough is enough and wants to cash out. Perhaps we’ll find out.

The source material is from ipv4auctions.com, code-wise it is ARIMA (or “seasonal ARIMA”, SARIMAX) from statsmodels, some pandas and a bit of plotting.

Scaleway Centos7.2 image is vulnerable

UPDATE 2017-11-09: Torgrim Teigstad originally reported this and did some additional testing this week. It appears that all VMs spun from this image use the same hard coded root password, and this exists in the list of passwords being probed over ssh. If you’ve changed the root password after installation, you’re safe. Well done, Torgrim!

tl;dr: If you install the recommended Centos 7.2 image on Scaleway.com and leave it be, it appears to have a severe security issue and it will get owned unless patched immediately.

I did an experiment with a fresh vm and did not patch it in any way. After two days the VM locked up and refused ssh logins and console access. A hard reboot later, the vm has been taken over.

And before the haters starts yelling that I need to patch: yes, but no. This is scaleway’s fault. Their images should be safe to run by default. Yes, from the time I install it it is my responsibility, but the original image should be updated and secured by Scaleway.

Last login: Tue Oct 31 14:29:08 2017 from 177.101.205.5

[root@scw-4eee22 ~]# find /tmp
/tmp
/tmp/aw.sh.1
/tmp/.font-unix
/tmp/.ICE-unix
/tmp/.Test-unix
/tmp/.X11-unix
/tmp/.XIM-unix

-rw-r–r– 1 root root 0 Oct 27 19:58 aw.sh.1

I certainly have never logged in from 177.101.205.5.

The vm is based on the scaleway image armv7l-centos-latest-2016-07-01_10:24.

It didn’t take long for them to get back in:

Nov 1 09:39:59 scw-4eee22 sshd[4215]: pam_unix(sshd:session): session opened for user root by (uid=0)
Nov 1 09:44:34 scw-4eee22 sshd[4246]: Accepted password for root from 194.88.107.164 port 50587 ssh2

Nov 1 09:54:35 scw-4eee22 sshd[4347]: Accepted password for root from 14.47.125.208 port 4235 ssh2
Nov 1 09:54:35 scw-4eee22 sshd[4347]: pam_unix(sshd:session): session opened for user root by (uid=0)
Nov 1 09:54:36 scw-4eee22 sshd[4347]: Received disconnect from 14.47.125.208: 11:
Nov 1 09:54:36 scw-4eee22 sshd[4347]: pam_unix(sshd:session): session closed for user root

root password hash from /etc/shadow:

root:$6$0fPUiyMT/zOk$Wh83pSqrId7z.sl5wtQPn87mphyuwsHh3Zm1gt9rj1NGr9WB4V9p8I7U3biMH/THNj8/hD3iAXkOUYUh1Ki1S/:16772:0:99999:7:::

[root@scw-4eee22 log]# ls -l /etc/shadow
———- 1 root root 687 Jul 1 2016 /etc/shadow

(can’t trust the time stamps)

 

Here is the list of packages that yum wants to upgrade (if we decide to trust what yum is doing at this stage):

====================================================================================================
Package Arch Version Repository Size
====================================================================================================
Installing:
python-gobject-base armv7hl 3.22.0-1.el7 base 279 k
replacing pygobject3-base.armv7hl 3.14.0-3.el7
Updating:
alsa-lib armv7hl 1.1.3-3.el7 base 378 k
audit armv7hl 2.7.6-3.el7 base 225 k
audit-libs armv7hl 2.7.6-3.el7 base 88 k
avahi-autoipd armv7hl 0.6.31-17.el7 base 40 k
avahi-libs armv7hl 0.6.31-17.el7 base 56 k
bash armv7hl 4.2.46-29.el7 updates 942 k
bind-libs-lite armv7hl 32:9.9.4-51.el7 updates 671 k
bind-license noarch 32:9.9.4-51.el7 updates 84 k
binutils armv7hl 2.25.1-32.base.el7.1 updates 5.0 M
ca-certificates noarch 2017.2.14-71.el7 base 472 k
centos-userland-release armv7hl 7-4.1708.el7.centos.0.1 base 25 k
chkconfig armv7hl 1.7.4-1.el7 base 177 k
coreutils armv7hl 8.22-18.el7 base 3.2 M
cpio armv7hl 2.11-25.el7 updates 202 k
cronie armv7hl 1.4.11-17.el7 base 88 k
cronie-anacron armv7hl 1.4.11-17.el7 base 35 k
cryptsetup-libs armv7hl 1.7.4-3.el7 base 217 k
curl armv7hl 7.29.0-42.el7 base 262 k
cyrus-sasl-lib armv7hl 2.1.26-21.el7 base 148 k
dbus armv7hl 1:1.6.12-17.el7 base 274 k
dbus-libs armv7hl 1:1.6.12-17.el7 base 134 k
device-mapper armv7hl 7:1.02.140-8.el7 base 280 k
device-mapper-libs armv7hl 7:1.02.140-8.el7 base 308 k
dhclient armv7hl 12:4.2.5-58.el7 base 268 k
dhcp-common armv7hl 12:4.2.5-58.el7 base 173 k
dhcp-libs armv7hl 12:4.2.5-58.el7 base 122 k
dnsmasq armv7hl 2.76-2.el7.2 updates 257 k
dracut armv7hl 033-502.el7 base 319 k
dracut-config-generic armv7hl 033-502.el7 base 53 k
dracut-config-rescue armv7hl 033-502.el7 base 55 k
dracut-network armv7hl 033-502.el7 base 97 k
e2fsprogs armv7hl 1.42.9-10.el7 base 690 k
e2fsprogs-libs armv7hl 1.42.9-10.el7 base 157 k
ebtables armv7hl 2.0.10-15.el7 base 116 k
elfutils-libelf armv7hl 0.168-8.el7 base 191 k
elfutils-libs armv7hl 0.168-8.el7 base 259 k
ethtool armv7hl 2:4.8-1.el7 base 113 k
expat armv7hl 2.1.0-10.el7 base 68 k
file-libs armv7hl 5.11-33.el7 base 339 k
filesystem armv7hl 3.2-21.el7 base 1.0 M
fipscheck armv7hl 1.4.1-6.el7 base 20 k
fipscheck-lib armv7hl 1.4.1-6.el7 base 9.9 k
firewalld noarch 0.4.4.4-6.el7 base 416 k
gawk armv7hl 4.0.2-4.el7.1 base 819 k
glib2 armv7hl 2.50.3-3.el7 base 2.2 M
glibc armv7hl 2.17-196.el7 base 3.3 M
glibc-common armv7hl 2.17-196.el7 base 11 M
gmp armv7hl 1:6.0.0-15.el7 base 237 k
gnupg2 armv7hl 2.0.22-4.el7 base 1.4 M
gnutls armv7hl 3.3.26-9.el7 base 604 k
gobject-introspection armv7hl 1.50.0-1.el7 base 226 k
grep armv7hl 2.20-3.el7 base 334 k
gzip armv7hl 1.5-9.el7 base 124 k
initscripts armv7hl 9.49.39-1.el7 base 434 k
iproute armv7hl 3.10.0-87.el7 base 614 k
iprutils armv7hl 2.4.14.1-1.el7 base 220 k
iptables armv7hl 1.4.21-18.0.1.el7 updates 405 k
iputils armv7hl 20160308-10.el7 base 150 k
jansson armv7hl 2.10-1.el7 base 34 k
kbd armv7hl 1.15.5-13.el7 base 336 k
kbd-legacy noarch 1.15.5-13.el7 base 465 k
kbd-misc noarch 1.15.5-13.el7 base 1.4 M
kexec-tools armv7hl 2.0.14-17.el7 base 174 k
kmod armv7hl 20-15.el7 base 112 k
kmod-libs armv7hl 20-15.el7 base 46 k
kpartx armv7hl 0.4.9-111.el7 base 73 k
krb5-libs armv7hl 1.15.1-8.el7 base 685 k
less armv7hl 458-9.el7 base 111 k
libblkid armv7hl 2.23.2-43.el7 base 166 k
libcap armv7hl 2.22-9.el7 base 46 k
libcom_err armv7hl 1.42.9-10.el7 base 39 k
libcurl armv7hl 7.29.0-42.el7 base 201 k
libdb armv7hl 5.3.21-20.el7 base 631 k
libdb-utils armv7hl 5.3.21-20.el7 base 128 k
libffi armv7hl 3.0.13-18.el7 base 28 k
libgcc armv7hl 4.8.5-16.el7 base 98 k
libgcrypt armv7hl 1.5.3-14.el7 base 259 k
libmount armv7hl 2.23.2-43.el7 base 166 k
libndp armv7hl 1.2-7.el7 base 29 k
libnetfilter_conntrack armv7hl 1.0.6-1.el7 base 50 k
libnl3 armv7hl 3.2.28-4.el7 base 242 k
libnl3-cli armv7hl 3.2.28-4.el7 base 161 k
libpcap armv7hl 14:1.5.3-9.el7 base 131 k
libselinux armv7hl 2.5-11.el7 base 156 k
libselinux-python armv7hl 2.5-11.el7 base 218 k
libselinux-utils armv7hl 2.5-11.el7 base 152 k
libsemanage armv7hl 2.5-8.el7 base 136 k
libsepol armv7hl 2.5-6.el7 base 265 k
libss armv7hl 1.42.9-10.el7 base 43 k
libssh2 armv7hl 1.4.3-10.el7.1 base 125 k
libstdc++ armv7hl 4.8.5-16.el7 base 267 k
libtasn1 armv7hl 4.10-1.el7 base 317 k
libteam armv7hl 1.25-5.el7 base 43 k
libuuid armv7hl 2.23.2-43.el7 base 79 k
libxml2 armv7hl 2.9.1-6.el7.3 base 578 k
lm_sensors-libs armv7hl 3.4.0-4.20160601gitf9185e5.el7 base 39 k
logrotate armv7hl 3.8.6-14.el7 base 67 k
lsscsi armv7hl 0.27-6.el7 base 47 k
lua armv7hl 5.1.4-15.el7 base 179 k
make armv7hl 1:3.82-23.el7 base 409 k
ncurses armv7hl 5.9-14.20130511.el7 updates 302 k
ncurses-base noarch 5.9-14.20130511.el7 updates 68 k
ncurses-libs armv7hl 5.9-14.20130511.el7 updates 277 k
net-tools armv7hl 2.0-0.22.20131004git.el7 base 296 k
nettle armv7hl 2.7.1-8.el7 base 329 k
nspr armv7hl 4.13.1-1.0.el7 base 107 k
nss armv7hl 3.28.4-15.el7 updates 740 k
nss-softokn armv7hl 3.28.3-8.el7 updates 270 k
nss-softokn-freebl armv7hl 3.28.3-8.el7 updates 181 k
nss-sysinit armv7hl 3.28.4-15.el7 updates 59 k
nss-tools armv7hl 3.28.4-15.el7 updates 488 k
nss-util armv7hl 3.28.4-3.el7 base 63 k
ntp armv7hl 4.2.6p5-25.el7 base 514 k
ntpdate armv7hl 4.2.6p5-25.el7 base 84 k
openldap armv7hl 2.4.44-5.el7 base 314 k
openssh armv7hl 7.4p1-13.el7 updates 507 k
openssh-clients armv7hl 7.4p1-13.el7 updates 597 k
openssh-server armv7hl 7.4p1-13.el7 updates 444 k
openssl-libs armv7hl 1:1.0.2k-8.el7 base 853 k
p11-kit armv7hl 0.23.5-3.el7 base 243 k
p11-kit-trust armv7hl 0.23.5-3.el7 base 115 k
pam armv7hl 1.1.8-18.el7 base 700 k
parted armv7hl 3.1-28.el7 base 595 k
pcre armv7hl 8.32-17.el7 base 387 k
perl armv7hl 4:5.16.3-292.el7 base 7.9 M
perl-Pod-Escapes noarch 1:1.04-292.el7 base 50 k
perl-Socket armv7hl 2.010-4.el7 base 47 k
perl-libs armv7hl 4:5.16.3-292.el7 base 596 k
perl-macros armv7hl 4:5.16.3-292.el7 base 43 k
pinentry armv7hl 0.8.1-17.el7 base 69 k
policycoreutils armv7hl 2.5-17.1.el7 base 859 k
procps-ng armv7hl 3.3.10-16.el7 base 280 k
python armv7hl 2.7.5-58.el7 base 91 k
python-libs armv7hl 2.7.5-58.el7 base 5.5 M
python-pycurl armv7hl 7.19.0-19.el7 base 78 k
python-urlgrabber noarch 3.10-8.el7 base 107 k
rdma noarch 7.3_4.7_rc2-5.el7 base 29 k
readline armv7hl 6.2-10.el7 base 178 k
rpm armv7hl 4.11.3-25.el7 base 1.2 M
rpm-build-libs armv7hl 4.11.3-25.el7 base 96 k
rpm-libs armv7hl 4.11.3-25.el7 base 238 k
rpm-python armv7hl 4.11.3-25.el7 base 76 k
rsync armv7hl 3.0.9-18.el7 base 354 k
rsyslog armv7hl 8.24.0-12.el7 base 584 k
selinux-policy noarch 3.13.1-166.el7.5 updates 436 k
selinux-policy-targeted noarch 3.13.1-166.el7.5 updates 6.5 M
setup noarch 2.8.71-7.el7 base 164 k
shadow-utils armv7hl 2:4.1.5.1-24.el7 base 1.1 M
shared-mime-info armv7hl 1.8-3.el7 base 309 k
socat armv7hl 1.7.3.2-2.el7 base 269 k
sudo armv7hl 1.8.19p2-11.el7 updates 1.1 M
sysstat armv7hl 10.1.5-12.el7 base 295 k
systemd armv7hl 219-42.el7.4 updates 4.8 M
systemd-libs armv7hl 219-42.el7.4 updates 337 k
systemd-sysv armv7hl 219-42.el7.4 updates 70 k
tar armv7hl 2:1.26-32.el7 base 824 k
tcpdump armv7hl 14:4.9.0-5.el7 base 394 k
teamd armv7hl 1.25-5.el7 base 102 k
trousers armv7hl 0.3.14-2.el7 base 258 k
tzdata noarch 2017c-1.el7 updates 468 k
util-linux armv7hl 2.23.2-43.el7 base 1.9 M
vim-common armv7hl 2:7.4.160-2.el7 base 5.9 M
vim-enhanced armv7hl 2:7.4.160-2.el7 base 890 k
vim-filesystem armv7hl 2:7.4.160-2.el7 base 9.3 k
vim-minimal armv7hl 2:7.4.160-2.el7 base 359 k
virt-what armv7hl 1.13-10.el7 base 27 k
wget armv7hl 1.14-15.el7.1 updates 529 k
xz armv7hl 5.2.2-1.el7 base 228 k
xz-libs armv7hl 5.2.2-1.el7 base 98 k
yum noarch 3.4.3-154.el7.centos base 1.2 M
yum-plugin-fastestmirror noarch 1.1.31-42.el7 base 32 k
zlib armv7hl 1.2.7-17.el7 base 87 k
Installing for dependencies:
GeoIP armv7hl 1.5.0-11.el7 base 1.1 M
elfutils-default-yama-scope noarch 0.168-8.el7 base 30 k
firewalld-filesystem noarch 0.4.4.4-6.el7 base 47 k
hwdata armv7hl 0.252-8.6.el7 base 2.2 M
ipset armv7hl 6.29-1.el7 base 40 k
ipset-libs armv7hl 6.29-1.el7 base 47 k
libfastjson armv7hl 0.99.4-2.el7 base 25 k
nss-pem armv7hl 1.0.3-4.el7 base 59 k
pciutils armv7hl 3.5.1-2.el7 base 88 k
pciutils-libs armv7hl 3.5.1-2.el7 base 41 k
python-firewall noarch 0.4.4.4-6.el7 base 325 k

Transaction Summary
====================================================================================================
Install 1 Package (+11 Dependent packages)
Upgrade 172 Packages

 

 

Doing consulting work

I’ve been working as an independant consultant since January 2017.

I left my position as tech lead with Varnish Software, having spent almost five years there, knowing it was time to do something else. I’d like to thank Poul-Henning for his kind words in the Varnish Cache 5.1 release note.

Working on your own has its ups and downs (fewer interesting lunch discussions for one!), but in general I find it quite rewarding. I get to do different things, learn something new almost every day and best of all none of the politics I dealt with in Varnish.

This of course means that I’m privy of clients, and need to spend time to finding work. If you have something that you think will fit my skill set[1], I’m happy to have a chat with you.

-Lasse

1: (MSc. telecom, 4-5 years of sysadmin/ops + 5 years of Varnish Cache. See https://www.linkedin.com/in/lkarsten/

fdxread 0.9.1 released

I’ve released version 0.9.1 of my Nexus FDX protocol decoder. It does things like read .nxb files a lot quicker than before, handle USB disconnects/reconnects of the GND10 (when running), serial port timeout, and lots of other stuff.

As of an hour ago, it is on pypi and can be installed using “pip install fdxread”.

It should work on your laptop, or on a pi if you prefer. (at least it installs fine on my older armhf jessie system.)

In other news, I’ve created a Wikipedia node for FDX to make it more widely understood: https://en.wikipedia.org/wiki/Fast_Data_eXchange

As I said earlier, if anyone have any FDX capable Nexus gear they’re not using any longer, I would love some actual hardware to play with.

Garmin GND10 unveiled (it is Nexus FDX!)

Mother of all detours; the USB port on the Garmin GND10 isn’t NMEA2000, it is something called Nexus FDX. That took a couple of weeks to figure out, hunting for NMEA2000 protocol headers. Always check your assumptions.

Anyway, I’ve written a decoder for it now which can be found on https://github.com/lkarsten/GND10read . It decodes GPS position, speed, wind angle and strength. Output can be a series of json encoded dictionaries, or NMEA0183 if you prefer.

I’m pretty sure I’ve gotten the header format of the FDX packets wrong,  but it seems to work. The git repo above has my notes and some dump files, if anyone has a proper FDX network and want to try it out.

Use case is simple. I connect my laptop to the GND10 USB port before I go out sailing, and I get all the sensor data into OpenCPN. I can also log it to file, if I want to compute my own polars or do endless post-regatta analysis.

NMEA2000 and CANbus

I’ve been looking at NMEA2000 and CANbus lately. I’m attempting to reverse engineer the binary protocol seen coming out of the USB port on a Garmin GND10 network bridge, and that opens a whole field of new and interesting stuff to know about.

Quick background: NMEA2000 is a application-level protocol that is used on ships and smaller boats, to communicate things like heading, speed and position between sensors (gps, compass, etc) and displays on the bridge. The physical, datalink and network layers (to the extent that it applies) in this are CANbus.

It is truly fascinating how complicated “industry standard” can be. Adding to that, each of the 8 ISO1939 standards defining it is 168CHF each. Not an option for me at the moment, so here I go digging in binary data. (And in retrospect, complain less about RFCs in the future. They are free, open and mostly well thought out.)

The Wikipedia nodes for both these contain lots of facts, but perhaps doesn’t give you the overview you need as an implementor.

CANbus can be sent over many different physical setups, for NMEA2000 there are five wires: ground, +12V vcc, can-hi, can-lo and shield. Typically you have a canbus transciever circuit/IC to do the differential encoding on can-lo and can-hi, and a separate canbus controller for the protocol itself. The connectors for NMEA2000 is a round quick-release kind, but you can also do canbus over cheap cat5+rj45 if you want. (250kbit/s is rather forgiving these days)

CANbus frames have a 32 bit identifier and up to 8 bytes (yes, this is quite adorable) of payload. The wire format contains additional bits here and there, a length field and a CRC and DC-correcting tailer. All this is probably interesting if you create the controllers, but for anyone writing software it doesn’t matter. Especially the part about the frame identifier is either 11 bit or 29 bits, you can ignore. At least for NMEA2000 only CAN2.0B with 29 bit identifiers are used.

On the software side, you get: 1) 32bit frame identifier, 2) the length indicator, and 3) the >=8 bytes of data. Everything else is handled by your interfacing hardware. Hurray.

The 32 bit identifier is a bitfield consisting of source, destination, priority and the Parameter Group Number (PGN).

In NMEA2000 most frames are broadcasted without any specific receivers in mind. The PGNs are defined by the non-public standard made by NMEA, and defines the number of payload bits and what they contain.

Which range a PGN is in also define which framing method is used. CAN frames with a PGN in a single-frame range has the single-frame 8 bytes of payload. Some PGNs are in a “fast-packet” range, where a collection of (up to) 32 CAN-frames can be sent with a session id, sequence counter embedded in the first 8 bits of each payload. The first frame in the sequence additionally has a sequence length in the second byte. This allows the receiver to reassemble the sequence in userspace for a combined payload of up to 233 bytes.

I have no idea how controllers handle lost frames in a fastpacket sequence, most likely they just drop the whole sequence. I also wonder if anything here is complicated enough to that out-of-order delivery can happen. Haven’t seen it yet, though.

There is an additional “ISO” transfer mode that is a (“unicast”) request/response method. Back when I was playing with ODB2 in cars, you had to request a specific ID with data. I think this what was being used there, but haven’t verified. It supports up to 1785 bytes, so obviously there is some segmentation and reassembly method there as well. I haven’t looked at it yet, as I’m mostly interested in the broadcasted updates.

On the network management side, there is an ARP/ND alike way for connecting units to claim source IDs. Lower source id means higher network priority on collisions. so there is some magic to it. I haven’t come this far yet.

Trying to keep this short and readable, let me round off with mentioning the CANbus network interface in Linux. There is kernel support now and you get a network interface with a whopping 8 byte MTU. There is even a loopback interface for it, so you can talk CAN between applications if you don’t have a physical CAN interface. Look at the documentation for can-utils.git for details.

I’ll try to post again when I figure out more of this stuff.

Sources:

• https://github.com/canboat/canboat/blob/master/analyzer/pgn.h
• https://en.wikipedia.org/wiki/CAN_bus
• https://en.wikipedia.org/wiki/NMEA_2000
• https://www.kvaser.com/about-can/higher-layer-protocols/j1939-introduction/

 

Scanning for multicast TV channels

In recent times, I’ve cut the cord and stopped watching TV from my local cable company.

This gave the need to look for IPv4 multicast groups that had active talkers, so I (on occasion) could stream some live TV over the internet instead. (don’t overthink the logic here .. ;))

The Norwegian research network has some free/open TV channels (NRK, TV2, Frikanalen), and I was thinking perhaps there are more available further out?

IPv4 multicast has a pretty small address space. 244/8 and up to the top. Shouldn’t be to hard to join all of them and see if something comes down the pipe?

Steps:

1) cook up a libpcap listener that reports destination ip and port of any multicast that is coming in, as well as bitrate. you probably want to filter mdns, sap, upnp and some other ports to keep the false positives low. I’ve made gist with the one I wrote here.

2) Join every multicast group under the sun, one by one. Just bind a socket to it, the port doesn’t matter. Rinse and repeat. I spent 10 seconds in each group, and joined about 50 at the time. I recommend that you go buy your network operations people some beer in advance, as IGMP implementations seem to fall over after a few days of heavy joins/parts. I recommend perhaps 5 or 10 concurrent groups. Code is here.

Some results, either from direct scanning or from scanning subnetworks that were sending SAP announcements:

• There are some TV channels on 233.0.59.0/24. Deutsche Welle and NHK World in 1080p.
• The Hellenic Parliament [sic] TV is on 233.21.32.200:1234.
• There are quite a few surveillance cameras hooked up, ready for your viewing pleasure!
• SVT1 is still around in Uninett.
• Some weird music channel called mtvU. Endless commercials, so probably american? :)

There are some more findings, but I don’t think the owners would appreciate publicity. I’m pretty sure there is more out there, if someone cares to take another look.

Anyway, I’ve had the code laying around for a while. Perhaps someone will find it useful. It worked well enough for me.

Introducing hitch – a scalable TLS terminating proxy.

The last couple of weeks we’ve been pretty busy making SSL/TLS support for Varnish Cache Plus 4. Now that the news is out, I can follow up with some notes here.

The setup will be a TLS terminating proxy in front, speaking PROXY protocol to Varnish. Backend/origin support for SSL/TLS has been added, so VCP can now talk encrypted to your backends.

On the client-facing side we are forking the abandoned TLS proxy called stud, and giving a new name: hitch.

hitch will live on github as a standalone open source project, and we are happy to review patches/pull requests made by the community. Here is the source code: https://github.com/varnish/hitch

We’ve picked all the important patches from the flora of forks, and merged it all into a hopefully stable tool. Some of the new stuff includes: TLS1.1, TLS1.2, SNI, wildcard certs, multiple listening sockets. See the CHANGES.rst file updates.

Varnish Software will provide support on it for commercial uses, under the current Varnish Plus product package.