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 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

[root@scw-4eee22 ~]# find /tmp

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

I certainly have never logged in from

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 port 50587 ssh2

Nov 1 09:54:35 scw-4eee22 sshd[4347]: Accepted password for root from 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 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@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
python-gobject-base armv7hl 3.22.0-1.el7 base 279 k
replacing pygobject3-base.armv7hl 3.14.0-3.el7
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 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 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: base 1.1 M
shared-mime-info armv7hl 1.8-3.el7 base 309 k
socat armv7hl 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 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 base 325 k

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



Posted in Uncategorized | Leave a comment

Doing consulting work

Been meaning to write this for a while.

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

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.


1: (MSc. telecom, 4-5 years of sysadmin/ops + 5 years of Varnish Cache. See

Posted in Uncategorized | Leave a comment

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:

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.

Posted in sailing | Tagged , , , , | Leave a comment

Regatta race course by SMS

Cowes Week does something interesting; they’re sending out the chosen race course over SMS to the contestants[1].

The cool part about this, for the racers, is that it allows for automatic adding of waypoints on the yachts. Through the years, sailing on different yachts, more than once have we been late or unprepared to the start because the skipper was busy plotting the waypoints manually on the chart plotter. We have computers, they’re good at such. This shouldn’t be an issue.

When the race committee decides on the course, they text this to all contestants automatically. The best specification I’ve found on the format is in the Expedition manual[2], repeated here for reference:

The format is
IRC 3; Saturday; 8Y(RS); 8S(RS); 44(RP); 31(RP); 3H(RP); FINISH at 80
Class;Day of week; markref(rounding);markref(rounding);…markref(rounding);Finish at markref
First field: name of class
Second field: Day of week
Third to n-1th field: mark of the course
Nth field: finish mark in the format shown

The rounding definitions are: RP or RS meaning round to port/starboard, PP or PS for pass to port/starboard, LP or LS for leave to port/starboard, and GT for gate mark.

If you beforehand have plotted all the marks/buys under the correct names (or imported a waypoint file), this gives you everything you need to know except for where the start line is. With this information available, the obvious step of computing reaching angles and which sail to use becomes a whole lot easier.


Posted in sailing | Tagged , | Leave a comment

Looking for FDX data dumps (Nexus .nxb files)

I’m looking for data dumps containing FDX protocol data.

Last year I wrote a FDX data decoder in Python (see Garmin GND10 unveiled (it is Nexus FDX!)), and with the sailing season starting there is some interest in improving it.

First of all it would be nice to validate the assumptions made by looking at FDX data from a non-GND10 source. There are duplicates of the data seen from the GND10 in different messages, I think this is the GND10 rewriting data to support some legacy systems. It would be nice to figure out what are duplicated and what is needed. Also my paddlewheel was attacked by barnacles, so I think all my FDX dumps have speed-through-water (STW) at zero.

When that is sorted, a possible next step is to start writing/encoding messages to FDX, to program an NX2 server. I don’t have the gear for it, so I probably won’t spend too much time on it, but as a matter of curiosity it would be nice to have. If anyone have some old (working!) Nexus gear they can spare or upgraded from, ship it to Norway for me to play with. :-)

Data dumps can either be extracted with GND10read’s, or simply by saving a trace file with Nexus Race from Nexus/Garmin into an .nxb file. Upload to and send me the link.

Be aware that I may bug you to go sailing with the log/wind sensor/gps turned off later on, to figure out data fields and what unit originates the messages. It takes some time and scientific rigor to get right, but it is as good a reason to go sailing as any. :-)




Posted in sailing | Tagged , , , , | 1 Comment

Boat electronics hacking on 33c3


Interfacing the tiller auto pilot Seatalk bus

I’ve set up a small workshop / meetup on boat electronics hacking at 33c3 this year.

33c3 is the 33rd yearly congress for the Chaos Computer Club and collects around 5000 awesome people in a big conference centre in Hamburg.

I’ll do a small presentation on NMEA0183, NMEA2000, some signalk, perhaps a bit why this matters when racing sail boats, and why I’m frustrated with the state of boat electronics. I’ll demo some of the progress I’ve made, what I’m doing next and then try to get some discussion going.

My plan is to bring a small NMEA2000 lab setup, with a marine display and some canbus units. Most likely this will be at the Hackeriet assembly, and you’re invited to come and play with it.

If you’re on CCC, come by and say hello!

Posted in Uncategorized | Leave a comment

Seatalk and the ST2000+ autopilot

I’ve been looking at interfacing my Raymarine ST2000+ tiller auto pilot with the other sensors onboard.

The perceived upside of this is that it will steer based on wind angle instead of compass angle. This is nice on longer distance sailing since you don’t have to adjust the sails all the time.

Of course I don’t do much distance sailing, so it may just be an excuse to go digging into another arcane marine electronics protocol. Would be nice to have it working, though!

The Raymarine autopilots are about as old as the Internet is. Seriously. They came in different forms under the names Autohelm, Raytheon and Raymarine, and seem to have looked the same since the seventies.

Interface wise, it can read selected NMEA0183 messages and it also has a Seatalk bus. Course updates and track can be received over NMEA0183, for remote controlling it you need Seatalk.

Seatalk, or Seatalk1 since there is a later incompatible one called Seatalk NG, is a one-wire
bus with binary messaging. The messages (some) and the electrical characteristics have for a long time been reverse engineered and can be found on

Over the years there have been many small electronics projects to create protocol bridges.
Some of them can only read, some can only write, they only support a subset of the messages and they all have their own bugs. Firmware updates are done through a PIC or Atmel design tool that nobody has. After a few years the author loses interest and they disappear or go out of stock. I’m generalising here, but I think there is a grain of truth to it.

How about we take the following practical approach; 1) get the electrical interfacing documented in updated reference designs, and 2) do all of the message translation in software on a real computer.

Laptops are cheap, and they can easily run on battery for the 2-4 hours a normal can race lasts. Since you have the code, any bug that really annoys you is possible to fix, and over time the shared code base should mature nicely.

When it comes to running it without a laptop for cruising or distance races, a generic small x86 or arm computer can be bought cheaply and can run on 90mA (Intel Edison) to 200mA (older Raspberry Pi). This is in the region of the power usage of a navigational light, so most sailing boats should have the power budget for it.

Getting back to the auto pilot, one of the other sweet possibilities of having direct Seatalk bus access is that the autopilot can (I hope) be configured remotely. See the “88 03” message type on Knauf’s site. This means that gain and wind response can be set from a reasonable user interface on the laptop! I’m pretty good with technical gadgets, but I always have to look up in the manual how to adjust gain if its been more than a month since last time.

You can also send key presses directly over the bus, so when it rains you can change course without getting wet in the rain. From here the path to remote control from your apple/android/pebble watch is pretty short, if you’re into that.

All in all there are significant cool stuff to be had. Now we just need the Seatalk USB transciever design that does collision management, line coding (9 bits to the byte!) and data coding.


Posted in sailing | Tagged , , | 2 Comments

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 . 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.

Posted in sailing, varnish | Tagged , , , , , , | 10 Comments

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.



Posted in stuff | Tagged , , , , , | Leave a comment

Shutting down

Keeping this short: I’m shutting down my side project running a hosted Munin monitoring service from mid August 2016.

Priorities have changed, and since I don’t run many servers these days I don’t spend the time maintaining it that such a service deserves.

I hope it has been useful service. I know I’ve learned a lot from this experience.


Posted in Uncategorized | Leave a comment