Settings are given with the 'AT$NWRAT' arguments as follows:
1,1: 2G allowed
2,1: 3G allowed
0,2: 2G and 3G allowed, none preferred
1,2: 2G and 3G allowed, 2G preferred
2,2: 2G and 3G allowed, 3G preferred
This patch modifies MMBroadbandModemIcera as follows:
- Change modem_load_current_bands to report only bands that are
currently enabled
- Change modem_set_bands to handle setting ANY band in a way that no
forbidden bands are activated.
Turns out we can check supported bands by asking the modem what
the enabled state is for the bands it says it supports, and then
setting the enabled state to what it currently is. For bands the
modem actually doesn't support, it'll return an error. Use that
to build up the modem's actual supported band list.
In the connection and disconnection sequences, we make sure that the Bearer
object is valid by keeping a reference in the Dial3gppContext and
Disconnect3gppContext (actually, another one kept by the GSimpleAsyncResult as
well). But we are considering here the case where the context is completed and
freed by an unsolicited message handler before we get the reply to the AT
command, so to properly ensure that the bearer object is still valid when we try
to check if the context is in the priv struct, we need to keep an extra ref
around.
In the connection sequence, we make sure that the Bearer object is valid by
keeping a reference in the Dial3gppContext (actually, another one kept by the
GSimpleAsyncResult as well). But we are considering here the case where the
connection context is completed and freed by an unsolicited message handler
before we get the reply to the AT command, so to properly ensure that the bearer
object is still valid when we try to check if the context is in the priv struct,
we need to keep an extra ref around.
In the connection sequence, we keep the context in the private info of the
Bearer object, so that we can complete and free it when we receive OWANCALL
unsolicited messages. Now, the reply of the OWANCALL itself may get processed
as an unsolicited message, so effectively we're processing and finishing the
connection/disconnection context *before* we process the reply of the AT
command.
This patch ensures that we do not try to re-use the connection context after it
has been processed by the unsolicited messages handler.
In both the connection and disconnection sequences, we keep the context in the
private info of the Bearer object, so that we can complete and free it when we
receive %IPDPACT unsolicited messages. Now, the reply of the %IPDPACT itself may
get processed as an unsolicited message, so effectively we're processing and
finishing the connection/disconnection context *before* we process the reply of
the AT command.
This patch ensures that we do not try to re-use the connection/disconnection
context after it has been processed by the unsolicited messages handler.
