Bjørn Mork <[email protected]> writes: > Aleksander Morgado <[email protected]> writes: > >> I've opened a new issue in gitlab for your problem: >> https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/issues/9 >> Will take a look at the problem sometime this week. > > Something is incrementing the transaction id between each fragment: > > [21 ä¹ 2020, 09:55:23] [Debug] [/dev/cdc-wdm_pcie] Sent message > (translated)... > <<<<<< Header: > <<<<<< length = 4096 > <<<<<< type = command (0x00000003) > <<<<<< transaction = 4 > <<<<<< Fragment header: > <<<<<< total = 65 > <<<<<< current = 0 > <<<<<< Contents: > <<<<<< service = 'qdu' (6427015f-579d-48f5-8c54-f43ed1e76f83) > <<<<<< cid = 'file-write' (0x00000003) > <<<<<< type = 'set' (0x00000001) > <<<<<< Fields: > <<<<<< DataBuffer = > .. > > <<<<<< Header: > <<<<<< length = 4096 > <<<<<< type = command (0x00000003) > <<<<<< transaction = 5 > <<<<<< Fragment header: > <<<<<< total = 65 > <<<<<< current = 1 > <<<<<< Contents: > <<<<<< service = 'invalid' (00000000-0000-0000-0000-000000000000) > <<<<<< cid = '(null)' (0x00000000) > <<<<<< type = 'query' (0x00000000) > > > > That's not good. The function is supposed to err out both transactions > when it sees this second fragment with a new transaction id: > > If the function receives a fragment that is not the first fragment of a > new command with a new TransactionId, both commands shall be > discarded. One MBIM_FUNCTION_ERROR_MSG message per TransactionId shall > be sent.
A proposed quickfix here: https://gitlab.freedesktop.org/mobile-broadband/libmbim/-/merge_requests/32 But as noted: A real fix for proxied fragments will have to prevent other clients from interfering. Access to a device should be blocked once a client starts a fragmented transaction, until either all fragments have been submitted or some reasonable timeout. I guess MAX_TIME_BETWEEN_FRAGMENTS_MS could be re-used. This means that fragmented transactions must be tracked by the proxy. Bjørn _______________________________________________ ModemManager-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
