| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
| |
Simple methods are no longer in the string module.
|
| |
|
|
|
|
|
|
|
|
| |
Try to handle buggy firmware, or just make the library more robust, by
validating the read TLV before really reading it. If a TLV is not considered
valid, we just skip it for now.
E.g.: the "Detailed Service Status" TLV (0x21) in the "NAS Get Serving System"
message is supposed to be a sequence of 5 bytes, but some models (e.g. ZTE MF683)
end up sending only the first 4 bytes.
|
| |
|
|
|
|
|
|
|
| |
Messages can now be tagged with a special 'abort' keyword, so that whenever the
message times out we issue a new ABORT command to cancel the specific timed out
request.
This support is currently only available for the NAS and WDS services, which are
the ones supporting ABORT for their long-running operations.
|
| | |
|
| | |
|
| |
|
|
|
| |
Among the tons of fixes done here, we now generate some per-service .sections
file which we then concatenate to build the final libqmi-glib-sections.txt file.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
TLVs are either input or output, not always output.
|
| |
|
|
|
|
| |
If the 'version' tag is given in the messages and the `QmiDevice' is opened with
a explicit version info check, we will return an error if we're trying to send
a message which was introduced in a newer version of a service we support.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a huge refactor to avoid using internal packed structs to match TLVs
from a raw byte buffer. There are cases where packed structs do not help, for
example when two variable-length fields (like strings) are found in the same
TLV.
Instead of packed structs, we'll read basic types one by one directly from the
raw byte buffer. With this new logic, struct and array variables are no more
than containers of other basic types. Each basic type, implemented as objects
inheriting from a base Variable type, knows how to read/write from/to the
raw buffer. Therefore, reading a struct is just about reading one by one each
of the fields in the struct; and reading an array is just about providing a
loop to read all the array elements one by one.
This greatly simplifies reading basic types like integers, as the implementation
is kept in a single place, regardless of having the integer as the only field
in the TLV or as a field of a struct TLV or as an element of an array TLV.
Strings are treated a bit differently. In string TLVs, the string is to be
considered to be as long as the TLV value itself. In struct TLVs with string
fields, the string is assumed to have a 1-byte length prefix which specifies
the length of the string field within the TLV.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Simplify the field-type-specific TLV adding, as well as the mandatory field
checkings.
|
| |
|
|
|
|
| |
Some times, e.g. the Result TLV, are the same in every message defined, so
instead of re-defining them over and over, just provide a reference to a
common predefined type.
|
|
|
It will try to generate message creator/parsers from a manually maintained
JSON-encoded database.
|
