From: Richard Röjfors
GCC 10 warns about a couple of implicit conversions;
huawei: Member from the incorrect enum was returned,
both had the value 0, so the code would still work.
drivers/huaweimodem/radio-settings.c: In function ‘band_gsm_from_huawei’:
drivers/huaweimodem/radio-settings.c:107:
From: Richard Röjfors
In the case a unsolicited indication for UREG was received
while the status was polled. The poll response failed to parse.
This since the unsolicited indication only carries one
parameter, while the poll response is expected to carry two.
Update the code to loop until the r
From: Richard Röjfors
In the case a unsolicited indication for UREG was received
while the status was polled. The poll response failed to parse.
This since the unsolicited indication only carries one
parameter, while the poll response is expected to carry two.
Update the code to loop until the r
From: Richard Röjfors
Instead of implementing an own copy of requesting and parsing
CREG, reuse the existing one from at-modem.
---
drivers/ubloxmodem/network-registration.c | 40 +--
1 file changed, 16 insertions(+), 24 deletions(-)
diff --git a/drivers/ubloxmodem/network-r
From: Richard Röjfors
To be considered attached on LTE a context should be activated.
But in case the context got deactivated we did not update
the attached state, it remained attached.
That caused the connection manager to try to re-activate the
context manually, but for LTE thats done automatic
From: Richard Röjfors
There was an issue while running LTE and the connection
manager tried to activate the context with CID 1 while
it got automatically activated at the same time with
CID 4.
When the automatic activation happened ofono_gprs_cid_activated
got called which tried to assign the co
From: Richard Röjfors
There was a race condition where a context might be
registered before the netreg status updates to LTE.
The code took for granted the context is activated after
the technology update. With this change, any order is
is accepted.
---
src/gprs.c | 10 --
1 file change
From: Richard Röjfors
It turns out that both L2xx and L4xx modems are a bit
buggy when it comes to send CREG URC's when the tech changes.
Try to overcome this by subscribing to both UREG and CREG,
and poll the other when any of the URC's are received.
Protect from doing simultaneous polls though.
From: Richard Röjfors
It turns out that both L2xx and L4xx modems are a bit
buggy when it comes to send CREG URC's when the tech changes.
Try to overcome this by subscribing to both UREG and CREG,
and poll the other when any of the URC's are received.
Protect from doing simultanious polls though.
From: Richard Röjfors
It seems like the CREG reporting from the L2 modems are quite
buggy. An example for a L210 where CREG reports UTRAN while
COPS and UREG reports LTE. A manual poll also indicates LTE.
I also found that the technology mapping was incorrect,
probably confused with enum packet_
From: Richard Röjfors
Its incorrect to fiddle with the driver attach state when
attaching. When attaching the state is transitioning,
and the correct state will now always be assigned in
the end of the attach process, regardless of result.
---
src/gprs.c | 9 +
1 file changed, 9 insertio
From: Richard Röjfors
Its incorrect to fiddle with the driver attach state when
attaching. When attaching the state is transitioning,
and the correct state will not always be assigned in
the end of the attach process, regardless of result.
---
src/gprs.c | 9 +
1 file changed, 9 insertio
From: Richard Röjfors
plugins/quectel.c: In function ‘quectel_pre_sim’:
plugins/quectel.c:1150:20: error: unused variable ‘sim’
[-Werror=unused-variable]
struct ofono_sim *sim;
---
plugins/quectel.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/plugins/quectel.c b/plugins/quectel.c
index
From: Richard Röjfors
In the same way as we consider the driver attached when the
gprs status indicates we are registered, we should consider
it deattached when the status indicates unregistration.
If we don't, then we would not always recover from the case
when deattaching the driver fails. We
From: Richard Röjfors
Currently there is an issue if the attach state changes and
there are active contexts of which the driver does not
implement the detach_shutdown.
In that case we just release the context (clears CID and
active state), but nothing is signalled on D-Bus or towards
the modem.
O
From: Richard Röjfors
Currently there is an issue if the attach state changes and
there are active contexts of which the driver does not
implement the detach_shutdown.
In that case we just release the context (clears CID and
active state), but nothing is signalled on D-Bus or towards
the modem.
O
From: Richard Röjfors
In case a context get deactivated when a AT+CGACT=0 is
not issued, indicate that to gprs core.
This can happen if the device has an auto activated
LTE context and modem switches over to for instance UTRAN.
---
drivers/ubloxmodem/gprs-context.c | 15 ++-
1 file c
From: Richard Röjfors
This reverts commit 1fd419e5b4b3a87673f8e0219edb0f3ed9fca774.
Since gprs_attached_update now guarantees that we
will not get attached without having a context activated
in LTE, this is not needed anymore. It also potentially
interferes in case the driver was actually attach
From: Richard Röjfors
This reverts commit 0167c3339ca8f17a653592af995f439d24405de8.
Since gprs_attached_update now takes LTE in account this
should be reverted. This was actually a bad solution since
in case LTE was lost, and we should fall back on GPRS we
have flagged the driver to already bein
From: Richard Röjfors
Since we have a different condition for the attach state
when running on LTE, we should consider it in gprs_attached_update.
Previously it's done in some instances. But for instance if
the driver got detached from GPRS but now running on LTE with a
context up, we would be de
From: Richard Röjfors
Since its registered context is a condition for being attached
when running LTE, we might need to update the attached state
when a context is deactivated. Otherwise we might remain
attached, and connection managers (at least connman) start
to hammer us to connect a context,
From: Richard Röjfors
This reverts commit 0167c3339ca8f17a653592af995f439d24405de8.
Since gprs_attached_update now takes LTE in account this
should be reverted. This was actually a bad solution since
in case LTE was lost, and we should fall back on GPRS we
have flagged the driver to already bein
From: Richard Röjfors
This reverts commit 1fd419e5b4b3a87673f8e0219edb0f3ed9fca774.
Since gprs_attached_update now guarantees that we
will not get attached without having a context activated
in LTE, this is not needed anymore. It also potentially
interferes in case the driver was actually attach
From: Richard Röjfors
Since we have a different condition for the attach state
when running on LTE, we should consider it in gprs_attached_update.
Previously it's done in some instances. But for instance if
the driver got detached from GPRS but now running on LTE with a
context up, we would be de
From: Richard Röjfors
The callback calls cgact and cgdcont to get information
regarding any activate context.
---
drivers/atmodem/gprs.c | 167 +
1 file changed, 134 insertions(+), 33 deletions(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs
From: Richard Röjfors
There is an issue if an context gets auto activated early,
then provisioning might not have run yet for instance,
so a "new" context is created, which might be duplicated
by a provisioning context later.
So ignore the activated contexts until gprs is ready,
then it calls the
From: Richard Röjfors
This is useful for instance during startup where early
activated contexts can be listed at a suitable point in time.
---
include/gprs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/gprs.h b/include/gprs.h
index 988d6102..20bdb7a4 100644
--- a/include/gprs.h
From: Richard Röjfors
There are cases where the gprs status might updated to for instance
"unknown" while LTE is the bearer.
In that case we should not set the attach state to FALSE,
since then running LTE the conext activation reflects the attached
state.
---
src/gprs.c | 23 +++
From: Richard Röjfors
This is useful for instance during startup where early
activated contexts can be listed at a suitable point in time.
---
include/gprs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/gprs.h b/include/gprs.h
index 988d6102..c276517f 100644
--- a/include/gprs.h
From: Richard Röjfors
There is an issue if an context gets auto activated early,
then provisioning might not have run yet for instance,
so a "new" context is created, which might be duplicated
by a provisioning context later.
So ignore the activated contexts until gprs is ready,
then it calls the
From: Richard Röjfors
The callback calls cgact and cgdcont to get information
regarding any activate context.
---
drivers/atmodem/gprs.c | 149 -
1 file changed, 116 insertions(+), 33 deletions(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem/gprs
From: Richard Röjfors
There is an issue if an context gets auto activated early,
then provisioning might not have run yet for instance,
so a "new" context is created, which might be duplicated
by a provisioning context later.
So ignore the activated contexts until gprs is ready,
then it calls the
From: Richard Röjfors
The callback calls cgact and cgdcont to get information
regarding any auto activated context.
---
drivers/atmodem/gprs.c | 115 +++--
1 file changed, 88 insertions(+), 27 deletions(-)
diff --git a/drivers/atmodem/gprs.c b/drivers/atmodem
From: Richard Röjfors
There are cases where the gprs status might updated to for instance
"unknown" while LTE is the bearer.
In that case we should not set the attach state to FALSE,
since then running LTE the conext activation reflects the attached
state.
---
src/gprs.c | 19 ---
From: Richard Röjfors
---
src/gprs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/gprs.c b/src/gprs.c
index bdb8c8a2..723013b7 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -271,6 +271,9 @@ static gboolean assign_context(struct pri_context *ctx,
unsigned int use_cid)
From: Richard Röjfors
Previously the valid "unknown" netreg status was set
during startup, but its a bit problematic for gprs.
There might be cases where a LTE context is activated
before netreg is finished updating its status.
Resulting in gprs taking faulty actions.
Instead we set the status to
From: Richard Röjfors
Previously the valid "unknown" netreg status was set
during startup, but its a bit problematic for gprs.
There might be cases where a LTE context is activated
before netreg is finished updating its status.
Resulting in gprs taking faulty actions.
Instead we set the status to
From: Richard Röjfors
Previously the valid "unknown" registration status was set
during startup, but its a bit problematic for gprs.
There might be cases where a LTE context is activated
before netreg is finished updating its status.
And then gprs could make faulty actions.
Instead we set the sta
From: Richard Röjfors
To detect if a context gets activated before we register
for unsolicited events we need to check if any is
already activated, and flag it auto activated.
---
drivers/atmodem/gprs.c | 47 ++
1 file changed, 47 insertions(+)
diff --git
From: Richard Röjfors
In case the gprs_netreg_update is called from somewhere else
than the actual netreg update before any netreg updates have
happened. It can not make proper decisions. For instance
we might run on EUTRAN but it does not know yet. So check
if the technology is known to netreg,
From: Richard Röjfors
When a context gets activated we read its settings, but
if the context gets deactivated during this time we should
not indicate that the context is activated when the settings
are received.
---
drivers/atmodem/gprs.c | 11 +++
1 file changed, 11 insertions(+)
diff
From: Richard Röjfors
In one instance it was stored as boolean and another as int.
Since its always parsed as a boolean and it is a boolean,
always store it as boolean.
---
src/gprs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/gprs.c b/src/gprs.c
index d432c9fd..148c
From: Richard Röjfors
The ublox modems always run DHCP when in router mode.
Unfortunately the code overwrote the IP settings with
static IP settings while activating.
Now we respect the networking_mode regardless if
we read settings during activation or read settings
phase.
---
drivers/ubloxmod
From: Richard Röjfors
This fix is similar to the one in the following commit,
but fixes allocation for context ids after ap's are
read from settings.
commit c3fdf6a7c567a7507c3558a27006b6f9559493d6
Author: Denis Kenzior
Date: Thu Jan 3 17:17:21 2019 -0600
gprs: Fix allocation of context
From: Richard Röjfors
In a recent patch vendor family was only set if the device
did not support USBCONF, but that resulted in drivers
being registered the "generic" vendor. That caused
for instance netreg to use incorrect cmer mode and fail
on TOBY-L210.
---
plugins/ublox.c | 4 ++--
1 file cha
From: Richard Röjfors
According to the u-blox AT Commands Manual and my tests
the response prefix of AT+UUSBCONF is "+UUSBCONF:", including
a colon. The colon was missing in the code, causing next step
to parse a number to fail, since a colon is not a number.
---
plugins/ublox.c | 2 +-
1 file c
46 matches
Mail list logo