For now the driver works only with bridged mode for 2G/3G.
Once it activates the context it reads the ip, netmask,
gw, dns and sets them in the context settings.
Besides exceptions below, act like normal U-Blox devices.
gprs-context: don't set auth for TOBY L2. U-Blox Toby L2
doesn't support PAP/CHAP APN auth method.
atmodem: TOBY L2 supports only CMER mode 1. Also chaged original
mode variable to ind, which is a more appropriate name.
mode is what is being set first.
Each modem expresses their interfaces with its own interface string,
which is composed of 3 different USB attributes:
"bInterfaceClass/bInterfaceSubClass/bInterfaceProtocol".
While the old models like LISA support only "2/2/1" for modem
interfaces, TOBY-L2 also supports an unique string for NetworkInterface
for each profile.
* low-medium throughput profile : 2/6/0
* fairly backward-compatible profile : 10/0/0
* high throughput profile : 224/1/3
Besides the condition for checking NULL for mdm/aux/net should be relaxed
a little bit.
The newest generation of U-Blox TOBY-L2 series can be detected with
VID 0x1546 (the same as before), and one of the following PIDs:
* "0x1146" : high throughput profile
* "0x1141" : fairly back-compatible profile
* "0x1143" : low/medium throughput profile
This patch adds detection for high throughput mode.
An issue with iPhone 5C iOS 9.2 triggers desynchronization in call
states. When an active call is put on hold and another call arrives,
it is in WAITING state. It should be possible to answer it by issuing
AT+CHLD=2 but the phone changes its state to INCOMING so ATA should be
used. This change is advertised by sending callheld:2 event, but it is
not handled. This event can be used to trigger CLCC poll to synchronize
call states.
+CIEV: 3,1 <- first call arrives
AT+CLCC
+CLCC: 1,1,4,0,0,"01234567890",129
OK
RING
+CLIP: "01234567890",129
ATA
OK
+CIEV: 2,1
+CIEV: 3,0.
AT+CHLD=2.$ <- first call is put on hold
OK
+CIEV: 7,2 <- notification confirming that call #1 is on hold
+CCWA: "09876543210",129,1 <- second call arrives
+CIEV: 7,2
+CIEV: 3,1
AT+CLCC
+CLCC: 1,1,1,0,0,"01234567890",129
+CLCC: 2,1,5,0,0,"09876543210",129 <- new call is still in WAITING state
OK
+CIEV: 7,2 <- phone iternally promotes WAITING call to INCOMING
AT+CHLD=2 <- there is no WAITING call anymore, ATA should be used
+CME ERROR:3
When issuing a Scan() in poor reception while attached to an operator it's
fully possible to get no results, which causes the attached operator to be
cleaned up. In certain scenarios this would cause a use-after-free as there
are still references to this operator.
Transfer the attached operator to the new list regardless of removal caused
by the Scan() results.
This matches the behavior described by the documentation the signal
value returned by the code. This was causing a headache when using
stricter D-Bus wrappers like dbus-c++.
In situations where location changes rapidly, a use-after-free condition
can occur. What happens is that the timeout leaks and then the cbs
struct with the callback is cleaned up, resulting in a SIGSEGV when the
callback occurs from the glib loop.
Dragos Tatulea
Denis Kenzior
Dongsu Park
Samrat Guha Niyogi
Slava Monich
Kuba Pawlak
John Ernberg
Tony Espy