AP_GPS_GSOF: internal_error with invalid output_type

[Ryanf55]

Bug report

Issue details

The GSOF parser periodically reports garbage data on the output_type field and tries to set values in the bitmask that are out of range. The highest documented GSOF packet is 70, so this is not expected.

Version
master with patches

Platform
[x ] All
[ ] AntennaTracker
[ ] Copter
[ ] Plane
[ ] Rover
[ ] Submarine

Airframe type
What type of airframe (flying wing, glider, hex, Y6, octa etc)

Hardware type
Trimble PX-1

Logs

[Ashishbsharma]

Hi, I looked into this crash and noticed that the message type coming from the GSOF data sometimes goes beyond the expected range. When it was 129, it caused parsed_msgs.set() to hit a bitmask range error.
I wanted to ask; is the GSOF spec guaranteed to never exceed type 70?
To fix this issue, would it make sense to add a range check before calling parsed_msgs.set(output_type) to catch unexpected values?

I'd be happy to open a PR with a guard clause if that sounds reasonable!

[Ryanf55]

Yea, that would prevent the internal error, but it doesn't explain why we get invalid data. Something more serious is wrong with the parser for it to give bad data - it's corrupted.
Looking at the same packets in wireshark, they don't set the output_type to that same value.

Want me to upload a wireshark capture that triggers this behavior?

[Ashishbsharma]

Yes, that would be helpful!