UBXDevice::parse: improve handling of corrupted ubx packets

[Sascha]

Sometimes we get the following receive error messages while frameworkd is reading from /dev/ttySAC1 (ch and rxs may vary):

gta02 kernel: rxerr: port ch=0xb5, rxs=0x00000001
gta02 kernel: rxerr: port ch=0x00, rxs=0x00000001
gta02 kernel: rxerr: port ch=0x01, rxs=0x00000001
gta02 kernel: rxerr: port ch=0x18, rxs=0x00000001

Then the UBXDevice::parse function skips 2 bytes (sync char 1 and 2) because of a failed checksum test and it tries to find the next sync bytes.

And here is the problem. Sometimes it finds the sync bytes in the middle of an ubx packet. Since there is no further check it reads class, message id, length and the number of bytes encoded in the length field (up to 2¹⁶). ogpsd seems to hang for a while. Once all bytes has been read the checksum test fails:

ogpsd    WARNING  UBX packed class 0x24, id 0x0, length 41399 failed checksum
ogpsd    WARNING  UBX packed class 0x0, id 0x65, length 46566 failed checksum
ogpsd    WARNING  UBX packed class 0x1, id 0x0, length 9234 failed checksum
ogpsd    WARNING  UBX packed class 0x1, id 0x12, length 19712 failed checksum
ogpsd    WARNING  UBX packed class 0x10, id 0x0, length 34960 failed checksum
ogpsd    WARNING  UBX packed class 0x0, id 0x0, length 63608 failed checksum
ogpsd    WARNING  UBX packed class 0x1, id 0x30, length 51200 failed checksum

Then ogpsd skips 2 bytes and all the ubx packets in the buffer are processed at once.

With the attached patch applied ogpsd will search the whole buffer for a valid ubx packet (sync bytes + checksum). Whenever it finds a corrupted ubx packet you will see a pair of log messages:

Dec 12 13:19:20 gta02 kernel: rxerr: port ch=0x62, rxs=0x00000001
Dec 12 13:19:20 gta02 2008.12.12 13:19:20 ogpsd    WARNING   UBX packet ignored '\xb5b\x01\x12$\x00\xd9\xe7d\x1c \x00\x00\x00\xd7\x00\x00\xc5\xf3f\x00e4'

In the long term, we should also check the combination of class, id and length for consistency. There is a table with valid combinations in the UBX Binary Protocol Specification.

[stefan]

Applied in 3de583b1c328b924e2841c2dfe3becc1c797cd98

Thanks