[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-users] AIS message size out of range
|
From: |
Eric S. Raymond |
|
Subject: |
Re: [gpsd-users] AIS message size out of range |
|
Date: |
Mon, 1 Jun 2015 06:12:04 -0400 |
|
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Roy Barkas <address@hidden>:
> I'm seeing thousands of the messages below in gpsd.log:
>
> Jun 1 08:56:59 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 24 size is
> out of range (186).
> Jun 1 08:57:04 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 20 size is
> out of range (174).
> Jun 1 08:57:05 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 21 size is
> out of range (396).
> Jun 1 08:57:08 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 21 size is
> out of range (424).
> Jun 1 08:57:15 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 20 size is
> out of range (174).
> Jun 1 08:57:21 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 24 size is
> out of range (198).
> Jun 1 08:57:29 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 24 size is
> out of range (198).
> Jun 1 08:57:30 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 20 size is
> out of range (174).
> Jun 1 08:57:31 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 20 size is
> out of range (174).
> Jun 1 08:58:03 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 24 size is
> out of range (198).
> Jun 1 08:58:05 sop gpsd[32518]: gpsd:ERROR: AIVDM message type 7 size is
> out of range (168).
>
> Am I correct in thinking that these are not being decoded?
Yes.
> There are enough of these on the various feeds I receive to cause me to
> think that one or more manufacturers have released AIS transponders with
> incorrect message sizes for some types.
I think that is quite likely. It has happened before. As the AIVDM
Decoding document notes:
Bit lengths and length ranges are given because decoders should check
them against the message type. Messages with correct checksums but the
wrong payload length for their type occur with about 0.3% frequency on
AISHub; if you don't reject these, your clients will see spurious
zeros or garbage.
But, now that I look, one of these - the Type 6 - is our bug. Wrong maximum
length in the decoder; I've just fixed that. As for the others:
Type 20 has an expected size of 160. You're seeing 174.
Type 21 has an expected size of 272-360 bits. You're seeing 396, 424.
Type 24 has an expected size of 168 bits. You're seeing 186 and 198.
These are pretty gross errors, not just the kind of noise we see when a vendor
gets confused about message padding. I'm reluctant to try doing anything
with these.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>