datasets: deviceinfo: clear MTP extension string to avoid libmtp quirks and USB resets#134
Conversation
…ks and USB resets
Remove legacy MTP extension string ("microsoft.com: 1.0; android.com: 1.0;") from DevInfos_MTP_Extensions[] and set it to an empty string. These identifiers were originally intended to point to vendor-specific documentation per the MTP spec [1], but no such documentation exists — even the Internet Archive has no record of it.
This string inadvertently triggers libmtp's [2] vendor-specific quirk handling, which includes problematic flags such as:
- DEVICE_FLAG_UNLOAD_DRIVER
- DEVICE_FLAG_FORCE_RESET_ON_CLOSE
These flags are applied when libmtp detects an "Android device" and assigns default bug flags [3], causing the USB connection to be reset after each transfer. This behavior is especially disruptive on multi-function USB devices, where the USB-gadget interface also serves as e.g. the primary SSH entry point. Frequent resets during rapid MTP file transfers lead to intermittent network disconnects and test failures.
By clearing the extension string, we prevent libmtp from applying these quirks, improving stability and preserving USB functionality during stress tests.
There is no other impact on MTP functionality, as both umpt-responder and libmtp do nothing else with these extension strings; and the supported MTP operations are both listed and handled separately.
Links:
https://www.usb.org/document-library/media-transfer-protocol-v11-spec-and-mtp-v11-adopters-agreement
https://libmtp.sourceforge.net/
https://github.com/libmtp/libmtp/blob/master/src/device-flags.h#L320
Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
js731ca
force-pushed
the
drop-extensions-string
branch
from
45cc28c to
71796ad
Compare
|
Maybe this string is worth a new optional parameter in the configuration file? |
i've pondered that too... but how would we document on what values to set it to?, apart from this inherited/legacy one - for which finding any actual documentation is already nigh impossible :-S |
|
For reference: the original string seems to have been inherited from cmtp-responder, which in turn just got it from tizen -- with no usefull context or documentation :-| The later commit hints at things like: or things that are potentially part of the microsoft:1.0 extension like: but these look like they are vestiges from back when PTP "evolved" into MTP Raising the question: does it make sense to advertise extensions that are not actually there? |
|
Update: "tested" the connection to a Windows 11 Enterprise host, looked OK |
Add a configuration option to allow a user to set the mtp extensions the responder will advertise to the host. This is only provided for backwards compatibility. Note that this string is defaulting to empty, and the string inherited from the tizen code-base mentioned in the example configuration can be used but can&will cause a hosts MTP implementation to see extensions that are not backed by any logic - and in the case of libmtp will trigger vendor specific quirk handling that unloads the hosts usb driver and resets the usb device. Signed-off-by: Johannes Schneider <johannes.schneider@leica-geosystems.com>
how about this: 684ff37 I'm still confident though that we could just drop this inherited legacy :-) |
|
It's perfect ! Thanks again ! |
2 participants
Remove legacy MTP extension string ("microsoft.com: 1.0; android.com: 1.0;") from DevInfos_MTP_Extensions[] and set it to an empty string. These identifiers were originally intended to point to vendor-specific documentation per the MTP spec [1], but no such documentation exists — even the Internet Archive has no record of it.
This string inadvertently triggers libmtp's [2] vendor-specific quirk handling, which includes problematic flags such as:
These flags are applied when libmtp detects an "Android device" and assigns default bug flags [3], causing the USB connection to be reset after each transfer. This behavior is especially disruptive on multi-function USB devices, where the USB-gadget interface also serves as e.g. the primary SSH entry point. Frequent resets during rapid MTP file transfers lead to intermittent network disconnects and test failures.
By clearing the extension string, we prevent libmtp from applying these quirks, improving stability and preserving USB functionality during stress tests. There is no other impact on MTP functionality, as both umpt-responder and libmtp do nothing else with these extension strings; and the supported MTP operations are both listed and handled separately.
Links:
https://www.usb.org/document-library/media-transfer-protocol-v11-spec-and-mtp-v11-adopters-agreement https://libmtp.sourceforge.net/
https://github.com/libmtp/libmtp/blob/master/src/device-flags.h#L320
Tested (so far):
Request for support/testers, since i don't have all combinations at hand :-)
CC @gujie-leica @bith3ad