| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
When a line comes in from the modem, we check against prefixes
in outstanding commands and unsolicited notifications. If the
outstanding command has not yet been sent (cmd_bytes_written == 0),
we still check it resulting in access violation.
|
|
|
|
|
|
|
|
|
|
Commands like CMGS might return an error before the entire command
has been submitted. This results in gatchat stalling completely.
|
|
|
|
|
|
|
|
Currently next_string and next_hexstring functions use a static
buffer in the iterator to store the value. This value is clobbered
as soon as next_string or next_hexstring is called. Instead,
we copy the entire line in iter_next and use it as a scratch buffer.
The only limitation is that lines of max 2048 are possible, however
these are limited to around this size by parts of the standard.
|
|
|
|
The previous fix did not take into account the logic in have_line
function, which takes care of certain modems that do not prefix
their responses by <cr><lf> at all. This fix should take both
into consideration
|
|
The standard is a bit fuzzy on how multiline responses are returned
GAtChat assumed that they will always start with <cr><lf>, however
this doesn't seem to be correct. Add a new state which is entered
when a response is obtained. If <cr> is encountered, then it
is processed regularly, otherwise the parser assumes that the
next line is part of the multiline response
|
|
|
|
|
|
|
