FlapJackApps/libdc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Scubapro G2: update BLE downloading for new 1.4 firmware version

Browse Source 
The packetization format for the BLE communication used to be that the
first byte of the BLE GATT payload was the size of the payload (1-19
bytes).

That seems to no longer be true as of fw version 1.4.  It is still the
size of the payload for the simple small reply packets, but for the long
data stream it ends up being an odd sequence of 13 different values that
are almost - but not quite - 19 apart.

Whatever.  Modify our strict "length byte must make sense" rule to be
more of a guidline than a hard rule.  This makes the download succeed
again.

Very weird.

Reported-by: Adric Norris <landstander668@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
Linus Torvalds 2018-10-08 12:09:50 -07:00
parent e61b7c64f9
commit f0fe141373
1 changed files with 40 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
src/uwatec_smart.c
View File

@ -326,11 +326,47 @@ uwatec_smart_usbhid_receive (uwatec_smart_device_t *device, dc_event_progress_t
return DC_STATUS_PROTOCOL;
}
/*
* Something changed in the G2 firmware between versions 1.2 and 1.4.
*
* The first byte of a packet always used to be the length of the
* packet data. That's still true for simple single-packet replies,
* but multi-packet replies seem to have some other data in it, at
* least for BLE.
*
* The new pattern *seems* to be:
*
* - simple one-packet reply: the byte remains the size of the reply
*
* - otherwise, it's an endlessly repeating sequence of
*
* 0xf7 247
* 0x14 20
* 0x27 39
* 0x3a 58
* 0x4d 77
* 0x60 96
* 0x73 115
* 0x86 134
* 0x99 153
* 0xac 172
* 0xbf 191
* 0xd2 210
* 0xe5 229
* 0xf7 247
* .. repeats ..
*
* which is basically "increase by 19" except for that last one (229->247
* is an increase by 18).
*
* The number 19 is the real payload size for BLE GATT (20 bytes minus the
* one-byte magic size-that-isn't-size-any-more-byte).
*
* It may be just an oddly implemented sequence number. Whatever.
*/
unsigned int len = buf[0];
if (len + 1 > transferred) {
ERROR (abstract->context, "Invalid payload length (%u).", len);
return DC_STATUS_PROTOCOL;
}
if (len + 1 > transferred)
len = transferred-1;
HEXDUMP (abstract->context, DC_LOGLEVEL_DEBUG, "rcv", buf + 1, len);