[PATCH] make it build against musl
by Sergey Alirzaev
ifdef away GNU libc extensions and use a POSIXly correct pointer type
---
gatchat/ppp_net.c | 2 +-
src/log.c | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/gatchat/ppp_net.c b/gatchat/ppp_net.c
index 813ed9b..914ca53 100644
--- a/gatchat/ppp_net.c
+++ b/gatchat/ppp_net.c
@@ -67,7 +67,7 @@ gboolean ppp_net_set_mtu(struct ppp_net *net, guint16 mtu)
strncpy(ifr.ifr_name, net->if_name, sizeof(ifr.ifr_name));
ifr.ifr_mtu = mtu;
- err = ioctl(sk, SIOCSIFMTU, (caddr_t) &ifr);
+ err = ioctl(sk, SIOCSIFMTU, (void *) &ifr);
close(sk);
diff --git a/src/log.c b/src/log.c
index febc874..6331b0d 100644
--- a/src/log.c
+++ b/src/log.c
@@ -30,7 +30,9 @@
#include <stdlib.h>
#include <string.h>
#include <syslog.h>
+#ifdef __GLIBC__
#include <execinfo.h>
+#endif
#include <dlfcn.h>
#include "ofono.h"
@@ -113,6 +115,7 @@ void ofono_debug(const char *format, ...)
va_end(ap);
}
+#ifdef __GLIBC__
static void print_backtrace(unsigned int offset)
{
void *frames[99];
@@ -240,6 +243,7 @@ static void signal_setup(sighandler_t handler)
sigaction(SIGABRT, &sa, NULL);
sigaction(SIGPIPE, &sa, NULL);
}
+#endif
extern struct ofono_debug_desc __start___debug[];
extern struct ofono_debug_desc __stop___debug[];
@@ -305,7 +309,9 @@ int __ofono_log_init(const char *program, const char *debug,
if (detach == FALSE)
option |= LOG_PERROR;
+#ifdef __GLIBC__
signal_setup(signal_handler);
+#endif
openlog(basename(program), option, LOG_DAEMON);
@@ -320,7 +326,9 @@ void __ofono_log_cleanup(void)
closelog();
+#ifdef __GLIBC__
signal_setup(SIG_DFL);
+#endif
g_strfreev(enabled);
}
--
2.4.1
5 years
HE910 + ofono: "Activating context failed with error: Unknown error type"
by Marko Sulejic
Hi,
I need your help in using a Telit HE910 with ofono (and eventually connman).
(I am using ofono 1.16 with HE910 firmware version 12.00.006; connman
version is 1.29).
My problem is the following ...
on startup everything works fine and the ppp0 connection is established,
but problems occur in the following case:
connmanctl> disconnect cellular_*_context15
Disconnected cellular_*_context15
connmanctl> connect cellular_*_context15
Error /net/connman/service/cellular_*_context15: Input/output error
ofonod[5355]: gprs-context.c(244):at_gprs_activate_primary() cid 1
ofonod[5355]: gprs.c(889):pri_activate_callback() 0x1a18c50
ofonod[5355]: gprs.c(893):pri_activate_callback() Activating context
failed with error: Unknown error type
connmand[3815]: Failed to change property: /he910_0/context15
org.ofono.ConnectionContext.Active: org.ofono.Error.Failed Operation failed
The same error happens if I am manually sending connect/disconnect via
dbus-send.
Only a hard ofono restart can establish the connection again.
This behavior happens all the time once a ppp0 disconnect happened
(e.g. by removing the SIM; manual disconnect via dbus or connmanctl).
A subquestion regarding connman:
Can connmand be configured in such a way that on every connection
loss, ofono is triggered to reconnect to the Internet?
Thank you very muchin advance,
Marko
5 years
Re: ofono Digest, Vol 74, Issue 7
by Tommi Kenakkala
On 18.06.2015 22:00, ofono-request(a)ofono.org wrote:
> Date: Wed, 17 Jun 2015 23:07:53 -0500
> From: Denis Kenzior
> <denkenz(a)gmail.com> To: ofono(a)ofono.org Cc: tommi.kenakkala(a)tieto.com
> Subject: Re: [PATCH 1/2] [sim] Emit LockedPins after pin_type is queried
> Message-ID: <55824419.5080703(a)gmail.com> Content-Type: text/plain;
> charset=ISO-8859-1; format=flowed
...
> There is a subtlety here. OFONO_SIM_PASSWORD_NONE is never considered
> when emitting LockedPins. However, in this proposal you can trigger a
> LockedPins emission even if there's no PIN set.
>
> To me it seems like emitting LockedPins with an empty value seems
> unnecessary. Thoughts?
...
> Regards,
> -Denis
I agree. Initially there was a though but now I don't see any extra
value on emitting it. Updated patch submitted.
Thanks,
--
Tommi
5 years
3G Modem not enabled (Huawei+Vodafone sim)
by Sriram Sagar
Hi,
I am having issue in connecting 3G modem on my arm platform.
I am using connman(1.29) as my network manager and ofonod(1.14) and modem
is not been detected.
I have checked the logs
huawei_probe function is been called and hung there.
Any body can help on this one.
5 years
[PATCH 0/2] Improve support for card hot-swapping
by Tommi Kenakkala
Events after inserting a card are as follows. Problem is
async steps 2 and 3+4 complete independently so client can't
rely on Present, CardIdentifier or other properties to know
when PinRequired and LockedPins are updated.
1. ofono_sim_inserted_notify > emit "Present" ==> sim_initialize
2. sim_iccid_read_cb > emit "CardIdentifier"
3. sim_efpl_read_cb > __ofono_sim_recheck_pin
4. sim_pin_query_cb
==> "PinRequired" emitted at startup but not on pin-enabled hotswaps
==> "LockedPins" never emitted
These patches improve the situation.
Tommi Kenakkala (2):
[sim] Emit LockedPins after pin_type is queried
[sim] Reset pin_type on card remove
src/sim.c | 27 ++++++++++++++++++++++++---
1 file changed, 24 insertions(+), 3 deletions(-)
--
1.7.9.5
5 years
Re: ofono Digest, Vol 74, Issue 6
by Tommi Kenakkala
On 16.06.2015 22:00, ofono-request(a)ofono.org wrote:
> Date: Tue, 16 Jun 2015 11:53:33 -0500 From: Denis Kenzior
> <denkenz(a)gmail.com> To: ofono(a)ofono.org Subject: Re: ofono Digest, Vol
> Today LockedPins is emitted only as a result of locking or unlocking the
> PIN. We can certainly look into emitting it when PinRequired is
> emitted. Do you already have a patch for this handy?
Sure, coming up.
> Yes, this sounds like a bug. We should always emit PinRequired on
> pin-enabled hotswaps.
Proposal sent
>> >OFONO_SIM_PASSWORD_INVALID was used because at startup it's the initial
> Actually, it isn't. OFONO_SIM_PASSWORD_NONE is the initial value.
True. I incorrectly recalled value would be "0" which is what the struct
is initialised to.
>> >Logs about use-case: remove & insert a pin-required usim card.
(...)
>> >There's an additional __ofono_sim_recheck_pin call seen here after
>> >ofono_sim_inserted_notify from driver to core trigger a password query.
>> >Now when I look at it I'm not sure if it's still needed, but
>> >nevertheless even if it's removed monitor-ofono does not show
>> >"LockedPins" or "PinRequired" being emitted
>> >(logs and code analysis confirm that).
...
>> >src/sim.c:__ofono_sim_recheck_pin()
> ??? This seems wrong. Are you running upstream? We should not be
> querying the PIN until after we read EFpl
...
> Regards,
> -Denis
Like I wrote the logs show an additional __ofono_sim_recheck_pin call
but that's besides the point, the property signalling problem is still
valid in upstream even when the extra __ofono_sim_recheck_pin is removed.
Just FYI, it is there because upstream EFpl reading triggers password
query, but sometimes at that time modem returns still an old value. As a
workaround the driver needs to poke "core" ofono to re-query when it's
updated. But let's not focus to that, we're not upstreaming that :)
Let's continue the discussion in the patch thread,
thanks
--
Tommi
5 years
Re: ofono Digest, Vol 74, Issue 5
by Tommi Kenakkala
On 12.06.2015 22:00, ofono-request(a)ofono.org wrote:
> Date: Fri, 12 Jun 2015 11:01:42 -0500
> From: Denis Kenzior<denkenz(a)gmail.com>
> To:ofono@ofono.org
> Subject: Re: SimManager properties and hotswap
> Message-ID:<557B0266.8010707(a)gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>> >Problem1
>> >If a client, for example triggered by the Present property change
>> >signal, asks GetProperties during the time window then PinRequired &
>> >LockedPins values are not updated yet.
>> >
> Then the client should simply wait for the relevant signal to arrive.
> Either SubscriberIdentity or PinRequired.
Thanks for the comments. What about LockedPins? Do you consider emitting
it inappropriate?
>> >Problem2
>> >A client can't work around Problem1, it doesn't know when after a
>> >hotswap PinRequired becomes available. sim_pin_query_cb checks
>> >"sim->pin_type = pin_type" before emitting PinRequired changed signal.
>> >Works for boot when pin_type is 0 but not for card hotswap because
>> >sim->pin_type is not reset, instead the old value is preserved.
> Sounds like a bug. Are you hot-swapping two PIN-locked SIMs? Can you
> share a log of what's happening?
Sure, please see [1] & [2].
[2]:
Do correct me if there's a mistake, but sequence is as follows and there
problem is
async steps 2. and 3+4. complete independently.
As a result to me it's not clear to which property or signalling clients
should rely on.
1. ofono_sim_inserted_notify > emit "Present" > sim_initialize
2. sim_iccid_read_cb > emit "CardIdentifier"
3. sim_efpl_read_cb > __ofono_sim_recheck_pin
4. sim_pin_query_cb
> "PinRequired" emitted at startup but not on pin-enabled hotswaps
> "LockedPins" never emitted
Whether this produces problems depends on timing.
>> >One fix proposal to Problem2 is to reset pin_type to
>> >OFONO_SIM_PASSWORD_INVALID in ofono_sim_inserted_notify when removed.
>> >That requires skipping appending PinRequired in sim_get_properties()
>> >if value is OFONO_SIM_PASSWORD_INVALID, otherwise
>> >ofono_dbus_dict_append crashes because sim_passwd_name() didn't have a
>> >value for OFONO_SIM_PASSWORD_INVALID.
>> >(I would've put resetting to sim_free_main_state(), but that's called
>> >when changing PIN fails due to wrong passwords and sim app switches
>> >PUK lock (OFONO_SIM_STATE_LOCKED_OUT), it would reset the password
>> >type already set as puk.)
> Setting it to OFONO_SIM_PASSWORD_INVALID is definitely not the right way
> to go. But there might be other ways to take care of the problem. Can
> you share the logs of what is happening first?
See [1] & [2].
Ok, did you have alternatives already on your mind?
OFONO_SIM_PASSWORD_INVALID was used because at startup it's the initial
value before state is properly read from card. It seemed logical to
"back up" into that state when card is removed and when looking at
sim_pin_query_cb .
>> >Problem3
>> >Similar for LockedPins, but there reason is sim_pin_query_cb() doesn't
>> >emit property change all.
>> >Fix proposal to Problem3 is to emit a change signal sim_pin_query_cb()
>> >if "sim->locked_pins[pin_type]" wasn't already TRUE.
>> >
>> >Please let me know your comments and improvement ideas. I can submit
>> >patches if you're interested.
>> >
> Regards,
> -Denis
[1]:
Logs about use-case: remove & insert a pin-required usim card.
- Same results if same or different pin-enabled card is inserted back.
- Driver implementation waits until password state is available and only
then notifies ofono core via ofono_sim_inserted_notify.
There's an additional __ofono_sim_recheck_pin call seen here after
ofono_sim_inserted_notify from driver to core trigger a password query.
Now when I look at it I'm not sure if it's still needed, but
nevertheless even if it's removed monitor-ofono does not show
"LockedPins" or "PinRequired" being emitted
(logs and code analysis confirm that).
- monitor-ofono output:
{SimManager} [/ril_0] Present = False
{VoiceCallManager} [/ril_0] EmergencyNumbers = 08 000 999 110 112 911
118 119
{SimManager} [/ril_0] Present = True
{VoiceCallManager} [/ril_0] EmergencyNumbers = 110 08 112 999 911 000
{SimManager} [/ril_0] CardIdentifier = <...>
{SimManager} [/ril_0] PreferredLanguages = fi sv en
{SimManager} [/ril_0] Present = False
{VoiceCallManager} [/ril_0] EmergencyNumbers = 08 000 999 110 112 911
118 119
{SimManager} [/ril_0] Present = True
{VoiceCallManager} [/ril_0] EmergencyNumbers = 110 08 112 999 911 000
{SimManager} [/ril_0] CardIdentifier = <...>
{SimManager} [/ril_0] PreferredLanguages = fi sv en
- Truncated ofono src/sim.c output, including some custom log prints:
oFono version 1.16
...
src/modem.c:modem_change_state() old state: 0, new state: 1
src/sim.c:ofono_sim_add_state_watch() 0xdae2a0
src/sim.c:ofono_sim_add_state_watch() 0xdae2a0
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 0
src/sim.c:sim_initialize()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 0, pin_type: 1
src/sim.c:sim_pin_query_cb() Here could add emit "LockedPins" changed
src/sim.c:sim_pin_query_cb() Emitting PinRequired property changed
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:sim_efpl_read_cb()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change, not
emitting PinRequired
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:ofono_sim_add_state_watch() 0xdae2a0
Requested file structure differs from SIM: 6fb7
src/sim.c:ofono_sim_inserted_notify() inserted: 0, sim->state: 1
src/modem.c:modem_change_state() old state: 1, new state: 1
src/sim.c:ofono_sim_inserted_notify() Here one could reset sim->pin_type
src/sim.c:sim_free_early_state()
src/sim.c:sim_free_main_state()
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 0
src/sim.c:sim_initialize()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
Requested file structure differs from SIM: 6fb7
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 1
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:sim_efpl_read_cb()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:ofono_sim_inserted_notify() inserted: 0, sim->state: 1
src/modem.c:modem_change_state() old state: 1, new state: 1
src/sim.c:ofono_sim_inserted_notify() Here one could reset sim->pin_type
src/sim.c:sim_free_early_state()
src/sim.c:sim_free_main_state()
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 0
src/sim.c:sim_initialize()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
Requested file structure differs from SIM: 6fb7
src/sim.c:ofono_sim_inserted_notify() inserted: 1, sim->state: 1
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
src/sim.c:sim_efpl_read_cb()
src/sim.c:__ofono_sim_recheck_pin()
src/sim.c:sim_pin_query_cb() sim->pin_type: 1, pin_type: 1
src/sim.c:sim_pin_query_cb() Methinks pin_type didn't change so didn't
emit change
src/sim.c:sim_pin_retries_check()
src/sim.c:sim_pin_retries_query_cb()
Ps. What's the mailing list practise on attachments, in case there's a
need to provide longish logs?
Thanks for the answers,
Br.
--
Tommi
5 years
SimManager properties and hotswap
by Tommi Kenakkala
Greetings
There's an issue for which I'd like to hear your opinion.
ofono_sim_inserted_notify signals org.ofono.SimManager Present property true,
but PinRequired and LockedPins are known only after
__ofono_sim_recheck_pin asks them from driver.
Problem can arise at startup but I've met this especially during
hotswap i.e. when I remove and insert the same/different card.
If a driver completes query_passwd_state synchronously there's less
room for problems, but if driver has to find out the values
asynchronously the time window is longer.
I'm using an implementation of rilmodem, but even the default atmodem
driver asks password state asynchronously (AT+CPIN?).
Problem1
If a client, for example triggered by the Present property change
signal, asks GetProperties during the time window then PinRequired &
LockedPins values are not updated yet.
Problem2
A client can't work around Problem1, it doesn't know when after a
hotswap PinRequired becomes available. sim_pin_query_cb checks
"sim->pin_type = pin_type" before emitting PinRequired changed signal.
Works for boot when pin_type is 0 but not for card hotswap because
sim->pin_type is not reset, instead the old value is preserved.
One fix proposal to Problem2 is to reset pin_type to
OFONO_SIM_PASSWORD_INVALID in ofono_sim_inserted_notify when removed.
That requires skipping appending PinRequired in sim_get_properties()
if value is OFONO_SIM_PASSWORD_INVALID, otherwise
ofono_dbus_dict_append crashes because sim_passwd_name() didn't have a
value for OFONO_SIM_PASSWORD_INVALID.
(I would've put resetting to sim_free_main_state(), but that's called
when changing PIN fails due to wrong passwords and sim app switches
PUK lock (OFONO_SIM_STATE_LOCKED_OUT), it would reset the password
type already set as puk.)
Problem3
Similar for LockedPins, but there reason is sim_pin_query_cb() doesn't
emit property change all.
Fix proposal to Problem3 is to emit a change signal sim_pin_query_cb()
if "sim->locked_pins[pin_type]" wasn't already TRUE.
Please let me know your comments and improvement ideas. I can submit
patches if you're interested.
--
Tommi
5 years
Problems provisioning APN from SIMs
by Alex J Lennon
Hi,
A request for some advice.
We're having trouble provisioning APNs for SIMs from certain Telcos, and
it seems to be because of the ordering of providers in serviceproviders.xml
Vodafone and O2 are cases in point. SIMs from either of those two
telcos, used in the UK, will fail to default to the standard APNs upon
provisioning.
In the case of Vodafone it is because an ASDA Mobile provider is present
before the Vodafone provider and both have the same MNC.
It's similar with O2, excepting that in this case there's a Giffgaff
provider before the O2 provider which thus is used for the APN.
I suspect our use case is similar to many others. We have a headless
embedded Linux board and we want an installation technician to be able
to put a SIM in, power the unit, and have everything else automated.
It looks like we may have to implement a custom serviceproviders.xml,
which would be a shame.
I am wondering if there are any other algorithmic or configuration
alternatives we can look at, such as Ofono trying different contexts
until one works? Or some additional Ofono provisioning configuration?
Thanks,
Alex
5 years
[PATCH v2] Connecting a phone with mpty call does not trigger CLCC polling
by Kuba Pawlak
If there is more then one active or held call, we are in mpty calls.
We won't get indicator update if any of them is released by CHLD=1x.
So we have to poll it.
---
drivers/hfpmodem/voicecall.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/hfpmodem/voicecall.c b/drivers/hfpmodem/voicecall.c
index afeb35f..e3e6e0f 100644
--- a/drivers/hfpmodem/voicecall.c
+++ b/drivers/hfpmodem/voicecall.c
@@ -1134,6 +1134,10 @@ static void hfp_clcc_cb(gboolean ok, GAtResult *result, gpointer user_data)
struct ofono_voicecall *vc = user_data;
struct voicecall_data *vd = ofono_voicecall_get_data(vc);
unsigned int mpty_ids;
+ GSList *n;
+ struct ofono_call *nc;
+ unsigned int num_active = 0;
+ unsigned int num_held = 0;
if (!ok)
return;
@@ -1142,6 +1146,22 @@ static void hfp_clcc_cb(gboolean ok, GAtResult *result, gpointer user_data)
g_slist_foreach(vd->calls, voicecall_notify, vc);
ofono_voicecall_mpty_hint(vc, mpty_ids);
+
+ n = vd->calls;
+
+ while (n) {
+ nc = n->data;
+
+ if (nc->status == CALL_STATUS_ACTIVE)
+ num_active++;
+ else if (nc->status == CALL_STATUS_HELD)
+ num_held++;
+
+ n = n->next;
+ }
+
+ if ((num_active > 1 || num_held > 1) && !vd->clcc_source)
+ vd->clcc_source = g_timeout_add(POLL_CLCC_INTERVAL, poll_clcc, vc);
}
static void hfp_voicecall_initialized(gboolean ok, GAtResult *result,
--
1.7.11.7
Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
5 years, 1 month
