[PATCH] qmimodem: fix roaming status report
by Christophe Ronco
Hi,
With a MC7304 modem and a roaming SIM card, Status in org.ofono.NetworkRegistration
properties ends up in "registered" instead of roaming.
Both AT command and qmicli indicates we are roaming.
What's happening is the following:
1) first QMI_NAS_SS_INFO_IND indicating we are registered contains a QMI_NAS_RESULT_ROAMING_STATUS parameter.
Parameter inside says we are roaming and qmimidem driver correctly reports status NETWORK_REGISTRATION_STATUS_ROAMING.
2) other QMI_NAS_SS_INFO_IND arrive, saying we are registered without QMI_NAS_RESULT_ROAMING_STATUS parameter.
Driver reports NETWORK_REGISTRATION_STATUS_REGISTERED.
Extract of traces with QMI binary debug interpreted (as far as I can...):
a) first "searching" indication
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 3b 00 80 03 01 04 00 00 24 00 2f 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
22 05 00 01 02 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_LIMITED, QMI_NAS_NETWORK_SERVICE_DOMAIN_PS, ...
15 03 00 01 08 01 LTE, no roaming
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 01 00 00
10 01 00 01 No roaming
01 06 00 02 02 02 02 01 08 QMI_NAS_REGISTRATION_STATE_NOT_REGISTERED_SEARCHING, CS detached, PS detached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_LTE
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=47 [client=1,type=4,tid=0,len=59]
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=41,len=5} {type=34,len=5} {type=21,len=3} {type=18,len=5}
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=17,len=1} {type=16,len=1} {type=1,len=6}
Dec 13 13:19:40 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 2 lac -1 cellid -1 tech 7
b) second "searching" indication
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 21 00 80 03 01 04 00 00 24 00 15 00
22 05 00 03 03 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_LIMITED_REGIONAL, CS_PS, ...
11 01 00 00
01 06 00 02 02 02 02 01 08 QMI_NAS_REGISTRATION_STATE_NOT_REGISTERED_SEARCHING, CS detached, PS detached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_LTE
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=21 [client=1,type=4,tid=0,len=33]
Dec 13 13:19:41 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=34,len=5} {type=17,len=1} {type=1,len=6}
c) First indication while "registered"
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 5e 00 80 03 01 04 00 00 24 00 52 00
2a 01 00 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
28 02 00 15 01 UMTS Primary Scrambling Code
26 08 00 03 00 00 00 03 00 00 00 CS: all calls allowed, PS: all calls allowed
22 05 00 02 03 00 01 00 Detailed Service Status: QMI_NAS_SERVICE_STATUS_AVAILABLE, CS_PS, ...
1e 04 00 f7 00 95 04 CID 3GPP
1d 02 00 fb 50 LAC 3GPP
15 03 00 01 05 00 UMTS: roaming
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 04 00 03 03 04 05
10 01 00 00 ROAMING ON
01 06 00 01 01 01 02 01 05 QMI_NAS_REGISTRATION_STATE_REGISTERED, CS attached, PS attached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_UMTS
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=82 [client=1,type=4,tid=0,len=94]
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=42,len=1} {type=41,len=5} {type=40,len=2} {type=38,len=8}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=34,len=5} {type=30,len=4} {type=29,len=2} {type=21,len=3}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=18,len=5} {type=17,len=4} {type=16,len=1} {type=1,len=6}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_gprs_status_notify modem /sierra_0 status 1
==================> ROAMING status reported <==========================
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 5 lac 20731 cellid 76873975 tech 2
d) second indication while "registered"
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: < 01 31 00 80 03 01 04 00 00 24 00 25 00
29 05 00 d0 00 14 00 00 MCC:208 MNC:20
28 02 00 15 01 UMTS Primary Scrambling Code
12 05 00 d0 00 14 00 00 Current PLMN: MCC:208 MNC:20, no desc
11 04 00 03 03 04 05
01 06 00 01 01 01 02 01 05 QMI_NAS_REGISTRATION_STATE_REGISTERED, CS attached, PS attached, NETWORK_TYPE_3GPP, QMI_NAS_RADIO_INTERFACE_UMTS
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: NAS_ind msg=36 len=37 [client=1,type=4,tid=0,len=49]
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=41,len=5} {type=40,len=2} {type=18,len=5} {type=17,len=4}
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.info ofonod[855]: QMI: {type=1,len=6}
==================> ROAMING information lost <==========================
Dec 13 13:19:56 klk-lpbs-0504B4 daemon.debug ofonod[855]: ofono_netreg_status_notify modem /sierra_0 status 1 lac -1 cellid -1 tech 2
I don't know if this is a problem specific to MC7304 or even to my firmware version or if this is a normal behavior to have ROAMING_STATUS parameter only when status change from anything to registered.
Best Regards,
Christophe
Christophe Ronco (1):
qmimodem: fix roaming status report
drivers/qmimodem/network-registration.c | 50 ++++++++++++++++++++++++++++-----
1 file changed, 43 insertions(+), 7 deletions(-)
--
2.7.4
2 years, 5 months
[PATCH] sim: fix crash in case of invalid sim password type
by Christophe Ronco
Hi,
I have an old Swedish SIM card here that I tried to put in my MC7304 modem.
My ofono version is 1.20 (with some additional patches).
It sometimes return an invalid SIM password type.
After that, ofono crashes. Here is an extract of debug traces when this happens.
Ofono is just starting, modem was here before ofono starts.
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/devinfo.c:string_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/devinfo.c:qmi_query_serial()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.err ofonod[1120]: Requested file structure differs from SIM: 6fb7
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g2_read_cb() 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/devinfo.c:get_ids_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_record() file id 0x6fb7 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/voicecall.c:ecc_g3_read_cb() 1
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x2fe2 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_transparent() file id 0x2fe2 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 10
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x6f05 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_transparent() file id 0x6f05 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 6
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_attributes() file id 0x2f05 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_file_attributes_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_read_transparent() file id 0x2f05 path len 0
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:read_generic_cb()
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/simfs.c:sim_fs_op_read_block_cb() bufoff: 0, dataoff: 0, tocopy: 6
Jun 27 15:28:41 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:qmi_query_passwd_state()
Jun 27 15:28:42 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:get_card_status() info1->app_state:0x6: OFONO_SIM_PASSWORD_INVALID
Jun 27 15:28:42 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/drivers/qmimodem/sim.c:query_passwd_state_cb() passwd state 16
Jun 27 15:28:42 klk-lpbs-0504B4 daemon.debug ofonod[1120]: ../git/src/sim.c:sim_pin_query_cb() sim->pin_type: 0, pin_type: 16
Jun 27 15:28:42 klk-lpbs-0504B4 daemon.err ofonod[1120]: Aborting (signal 11) [/usr/sbin/ofonod]
Problem is just that we don't have a string corresponding to this password type.
Christophe Ronco (1):
sim: fix crash in case of invalid sim password type
src/sim.c | 1 +
1 file changed, 1 insertion(+)
--
2.7.4
2 years, 10 months
Ofono LTE modems and connman services
by Jonas Bonn
The following issue is causing us some grief and I really need some
guidance on how to approach this. This is being sent to both the ofono
and connman mailing lists because it's not really clear to me who's
doing the right/wrong thing here...
The connman ofono plugin does the following:
i) It powers up (enables) the modem
ii) If cellular tech is enabled, it brings the modem online
For an LTE-modem, this second step results in a default bearer being
attached and thereby the modem is 'connected'. The third connman step,
setting the ofono context to Active, is not required for LTE; the
context becomes 'Active=true' right away.
The above effectively means that it's not possible to have an LTE modem
that does not auto-connect (in connman terms).
Now the APN that ofono sets on the LTE context is 'automatic'; that was
selected because connman _requires_ some APN or else it ignores the
context altogther.
If the modem roams away from LTE connectivity and wants to fallback to
UMTS/GSM, it needs another context with a valid APN. So now the modem
has two 'internet' contexts ('automatic' and APN) which connman presents
as two distinct services.
These two services, as far as I can tell, end up competing with each
other when connecting and a mess ensues... if the lower numbered context
is the 3G context, connman goes into an endless loop attempting to set
it Active and continuously failing when the tech switches to LTE.
The question is, what are the expectations here:
i) What does it mean for connman to see two 'internet' contexts since
it sets up two services for them?
ii) How is a modem supposed to roam between LTE and UMTS/GSM networks
when one requires an APN and the other does not.
iii) Not auto-connecting an LTE modem means not bringing it online; what
implications does this have for connman?
The above is currently a bit of a confusing mess and both ofono and
connman get themselves tied in a knot when the modem switches between
LTE and non-LTE techs. Any guidance on how to approach this would be
appreciated.
Thanks,
Jonas
2 years, 12 months
Ofono crashes on SIM notifications
by Mattias Månsson
Hi!
I'm working with integrating a new Gemalto modem with Ofono and is currently working with dynamic SIM card detection. This is not done by any included driver what I can see, so it is possible I have done something wrong. Anyway, I am listening to SIM card URCs and when I get one, I call ofono_sim_inserted_notify with the proper state. This seems to work fine at first, but if I do the following, I get a crash:
1. Insert SIM
2. Remove SIM
3. Insert SIM
4. Remove SIM
In this case I get a SIGABRT in src/sim.c:aid_session_free(). It seems as it tries to free that list sim->aid_sessions, but it has just been freed before. However, after freeing it the first time, it is never set to NULL, so the second time the NULL check doesn't take it and crash. I tried setting it to NULL, but then I realized that it is used in __ofono_sim_remove_session_watch() without allocating it again. So it seems that there is a chain of problems. Any ideas?
Here is some log (with some additional debug prints in sim.c):
ofonod[711]: plugins/verimalto.c:sim_detect_cb() Have SIM: 0
ofonod[711]: src/sim.c:ofono_sim_inserted_notify() SIM: 0x1336f8
ofonod[711]: src/modem.c:modem_change_state() old state: 3, new state: 1
ofonod[711]: src/modem.c:flush_atoms()
ofonod[711]: src/gprs.c:gprs_context_unregister() 0x13bef8, 0x118588
ofonod[711]: src/gprs.c:gprs_context_remove() atom: 0x13bf18
ofonod[711]: drivers/verimaltomodem/gprs-context-wwan.c:verimalto_gprs_context_remove()
ofonod[711]: drivers/verimaltomodem/netmon.c:verimalto_netmon_remove()
ofonod[711]: plugins/bluez5.c:bt_unregister_profile() Bluetooth: Unregistering profile /bluetooth/profile/dun_gw
ofonod[711]: src/gprs.c:gprs_unregister() 0x118588
ofonod[711]: src/network.c:__ofono_netreg_remove_status_watch() 0x13d400
ofonod[711]: src/gprs.c:gprs_remove() atom: 0x1185f0
ofonod[711]: src/sim.c:ofono_sim_remove_spn_watch() 0x1336f8
ofonod[711]: src/network.c:netreg_remove() atom: 0x13d468
ofonod[711]: src/voicecall.c:voicecall_remove() atom: 0x11e430
ofonod[711]: plugins/push-notification.c:push_notification_cleanup() 0x12ffe8
ofonod[711]: plugins/smart-messaging.c:smart_messaging_cleanup() 0x119c30
ofonod[711]: src/sms.c:sms_remove() atom: 0x11e3c8
ofonod[711]: src/sim.c:sim_free_main_state() Free aid_sessions: 0x139c90, SIM: 0x1336f8
ofonod[711]: src/sim.c:aid_session_free() session: 0x130c10 session->watches: 0x1398d0
ofonod[711]: src/sim.c:aid_session_free() session: 0x13ac20 session->watches: 0x117340
ofonod[711]: UnregisterProfile() replied an error: org.freedesktop.DBus.Error.ServiceUnknown, The name org.bluez was not provided by any .service files
ofonod[711]: plugins/verimalto.c:sim_detect_cb() Have SIM: 1
ofonod[711]: src/sim.c:ofono_sim_inserted_notify() SIM: 0x1336f8
ofonod[711]: Interface org.ofono.AllowedAccessPoints not found on the interface_list
ofonod[711]: plugins/verimalto.c:sim_detect_cb() Have SIM: 0
ofonod[711]: src/sim.c:ofono_sim_inserted_notify() SIM: 0x1336f8
ofonod[711]: Interface org.ofono.AllowedAccessPoints not found on the interface_list
ofonod[711]: src/modem.c:modem_change_state() old state: 1, new state: 1
ofonod[711]: src/sim.c:sim_free_main_state() Free aid_sessions: 0x139c90, SIM: 0x1336f8
ofonod[711]: src/sim.c:aid_session_free() session: 0x139cd0 session->watches: 0x139cc0
*** Error in `/usr/sbin/ofonod': free(): invalid pointer: 0x00139cc0 **
Program received signal SIGABRT, Aborted.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47
47 ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
It has also crashed in other parts of sim.c as well as in simfs.c, so I'm starting to doubt it can really handle spontaneous SIM card notifications...
We are currently using Ofono version 1.22.
BRs,
Mattias
3 years
Issue with an URC falling into an AT command response
by Bassem BOUBAKER
Hello Community,
I'm facing an issue with an ofono segfault because of an URC is received between the AT command and its response.
Below is my case:
ofonod[826]: App: > AT^SMONI\r
ofonod[826]: App: < \r\n^SREG: 2,0\r\n
ofonod[826]: App: < \r\n^SMONI: Searching\r\nSearching\r\n\r\nOK\r\n
The URC ^SREG is captured in the callback function related to handling the response of AT^SMONI.
I have two questions here:
i) how can I isolate only the response of AT^SMONI without nasty hacking the response cb function.
ii) How can I force ofono to go through the registered callback of the URC ^SREG in this particular case.
Any ideas?
Thanks,
Bassem.
3 years
Re: Issue with service reporting on a 4G modem
by Daniel Wagner
Hi Bassem,
[added ofono mailing list]
On 02/16/2018 11:24 AM, Bassem BOUBAKER wrote:
> Hello community,
>
> I'm having connman version 1.31 along side with ofono running on my board.
>
> When I activate a context on my 4G modem using ofono, connman creates two services: one is cellular and the other is ethernet.
>
> *AR Wired ethernet_XX_cable
> *AO XXX cellular_XXX_context1
>
> In this case, the ideal state is that connman reports only one cellular technology related to the modem.
>
> When digging into the logs, I feels like a new ethernet device is enumerated and connman creates the appropriate service for it.
>
> Knowing that my modem net interface is using "cdc_ether" driver, does anyone have an idea about what could be the issue here?
From you description I understand that the modem creates an additional
ethernet interface? Could you post the corresponding logs (or post a
link to the logs)?
I am also not sure what the exact question is. I suspect you want to see
only one interface and not two..
Thanks,
Daniel
3 years
[PATCH] phonebook: Fixed double deletion of merge_list
by Slava Monich
---
src/phonebook.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/src/phonebook.c b/src/phonebook.c
index 1e4efa2..f8936c5 100644
--- a/src/phonebook.c
+++ b/src/phonebook.c
@@ -428,7 +428,6 @@ static void export_phonebook_cb(const struct ofono_error *error, void *data)
g_slist_foreach(phonebook->merge_list, print_merged_entry,
phonebook->vcards);
g_slist_free_full(phonebook->merge_list, destroy_merged_entry);
- g_slist_free(phonebook->merge_list);
phonebook->merge_list = NULL;
phonebook->storage_index++;
--
1.9.1
3 years
[PATCH] udevng: Add OFONO_PATHNAME property to set modem dbus path name
by Pau Espin Pedrol
The current udevng.c implementation sets dbus path names for modems
based on type and a number incremented seuqntially for each new modem
found. As a result, the dbus path for a given device is non
deterministic, since it depends on the devices available during ofono
startup.
Furthermore, if a modem crashes and reboots while in operation, then
udev will trigger a remove event followed by a create event, and the
same modem will now be given a different name (as the sequence number is
bigger).
This is non suitable for systems handling several modems which want to
identify them easily based on its path.
This patch introduces a way to be able to set persistent names for
specific devices while still permitting previous dynamic naming
methodology.
One can set a persistent name using udev rules for the target device
which set the OFONO_PATHNAME env property. If ofono finds this property
set, it will use its value as the dbus path name for the modem.
Example:
$ cat /etc/udev/rules.d/90-local.rules
SUBSYSTEMS=="usb", DEVPATH=="/devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.1/3-1.1.4/3-1.1.4.1/3-1.1.4.1.1", ENV{OFONO_PATHNAME}="foo"
$ udevadm info -p /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.1/3-1.1.4/3-1.1.4.1/3-1.1.4.1.1
...
E: OFONO_PATHNAME=foo
...
$ mdbus2 -s org.ofono
/
/bluetooth
/bluetooth/profile
/bluetooth/profile/dun_gw
/bluetooth/profile/hfp_ag
/bluetooth/profile/hfp_hf
/foo
/mbm_0
---
plugins/udevng.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/plugins/udevng.c b/plugins/udevng.c
index 9b78ab47..e9f27977 100644
--- a/plugins/udevng.c
+++ b/plugins/udevng.c
@@ -46,6 +46,7 @@ enum modem_type {
struct modem_info {
char *syspath;
char *devname;
+ char *pathname;
char *driver;
char *vendor;
char *model;
@@ -1302,6 +1303,7 @@ static void destroy_modem(gpointer data)
g_free(modem->syspath);
g_free(modem->devname);
+ g_free(modem->pathname);
g_free(modem->driver);
g_free(modem->vendor);
g_free(modem->model);
@@ -1382,7 +1384,7 @@ static struct udev_device* get_serial_modem_device(struct udev_device *dev)
*/
static void add_serial_device(struct udev_device *dev)
{
- const char *syspath, *devpath, *devname, *devnode;
+ const char *syspath, *devpath, *devname, *devnode, *pathname;
struct modem_info *modem;
struct serial_device_info *info;
const char *subsystem;
@@ -1396,6 +1398,7 @@ static void add_serial_device(struct udev_device *dev)
}
driver = udev_device_get_property_value(mdev, "OFONO_DRIVER");
+ pathname = udev_device_get_property_value(mdev, "OFONO_PATHNAME");
syspath = udev_device_get_syspath(mdev);
devname = udev_device_get_devnode(mdev);
@@ -1415,6 +1418,7 @@ static void add_serial_device(struct udev_device *dev)
modem->type = MODEM_TYPE_SERIAL;
modem->syspath = g_strdup(syspath);
modem->devname = g_strdup(devname);
+ modem->pathname = g_strdup(pathname);
modem->driver = g_strdup(driver);
g_hash_table_replace(modem_list, modem->syspath, modem);
@@ -1440,7 +1444,8 @@ static void add_serial_device(struct udev_device *dev)
static void add_device(const char *syspath, const char *devname,
const char *driver, const char *vendor,
- const char *model, struct udev_device *device)
+ const char *model, const char *pathname,
+ struct udev_device *device)
{
struct udev_device *usb_interface;
const char *devpath, *devnode, *interface, *number;
@@ -1477,6 +1482,7 @@ static void add_device(const char *syspath, const char *devname,
modem->driver = g_strdup(driver);
modem->vendor = g_strdup(vendor);
modem->model = g_strdup(model);
+ modem->pathname = g_strdup(pathname);
modem->sysattr = get_sysattr(driver);
@@ -1512,8 +1518,8 @@ static void add_device(const char *syspath, const char *devname,
DBG("%s", syspath);
DBG("%s", devpath);
- DBG("%s (%s) %s [%s] ==> %s %s", devnode, driver,
- interface, number, label, sysattr);
+ DBG("%s (%s) %s [%s] ==> %s %s %s",
+ devnode, driver, interface, number, label, sysattr, pathname);
info = g_try_new0(struct device_info, 1);
if (info == NULL)
@@ -1611,7 +1617,7 @@ static struct {
static void check_usb_device(struct udev_device *device)
{
struct udev_device *usb_device;
- const char *syspath, *devname, *driver;
+ const char *syspath, *devname, *driver, *pathname;
const char *vendor = NULL, *model = NULL;
usb_device = udev_device_get_parent_with_subsystem_devtype(device,
@@ -1630,6 +1636,8 @@ static void check_usb_device(struct udev_device *device)
vendor = udev_device_get_property_value(usb_device, "ID_VENDOR_ID");
model = udev_device_get_property_value(usb_device, "ID_MODEL_ID");
+ pathname = udev_device_get_property_value(usb_device, "OFONO_PATHNAME");
+
driver = udev_device_get_property_value(usb_device, "OFONO_DRIVER");
if (!driver) {
struct udev_device *usb_interface =
@@ -1685,7 +1693,7 @@ static void check_usb_device(struct udev_device *device)
return;
}
- add_device(syspath, devname, driver, vendor, model, device);
+ add_device(syspath, devname, driver, vendor, model, pathname, device);
}
static void check_device(struct udev_device *device)
@@ -1723,7 +1731,7 @@ static gboolean create_modem(gpointer key, gpointer value, gpointer user_data)
DBG("driver=%s", modem->driver);
- modem->modem = ofono_modem_create(NULL, modem->driver);
+ modem->modem = ofono_modem_create(modem->pathname, modem->driver);
if (modem->modem == NULL)
return TRUE;
--
2.16.1
3 years
GPRS Attach/Detach
by Nikolas Sepos
Hello ofono maintainers,
i had an issue with a modem and the GPRS attach/detach command. It was
hanging my modem for 3 seconds (modem issue not ofono). So in order to work
around it i implemented attach and detach as NoOp (not sending
AT+CGATT=0/1) but still had to callback to ofono that i am attached or
detached. But in order for that to make it work i had to patch src/gprs.c
Here is the function i made changes to:
static void gprs_attached_update(struct ofono_gprs *gprs)
{
ofono_bool_t attached;
attached = gprs->driver_attached &&
(gprs->status == NETWORK_REGISTRATION_STATUS_REGISTERED ||
gprs->status ==
NETWORK_REGISTRATION_STATUS_ROAMING);
if (attached == gprs->attached)
return;
/*
* If an active context is found, a PPP session might be still
active
* at driver level. "Attached" = TRUE property can't be signalled to
* the applications registered on GPRS properties.
* Active contexts have to be release at driver level.
*/
if (attached == FALSE) {
release_active_contexts(gprs);
gprs->bearer = -1;
} else if (have_active_contexts(gprs) == TRUE) {
/*
* Some times the context activates after a detach event and
* right before an attach. We close it to avoid unexpected
open
* contexts.
*/
release_active_contexts(gprs);
gprs->flags |= GPRS_FLAG_ATTACHED_UPDATE;
return;
}
gprs_set_attached_property(gprs, attached);
}
I had to remove the `else if (have_active_contexts(gprs) == TRUE) { ... }`
block because when attached was TRUE i still had active context and i
didn't want it to be deactivated.
As the comments say it's to mitigate some PPP issues. Should that be the
case for all type of connections? What if my connection is RNDIS and not
PPP?
I hope i explained this well enough. If not please ask me to explain more.
Looking forward to your reply.
All the best,
---
Nikolas Sepos
DevOps Engineer @ Endocode AG
nikolas(a)endocode.com
------
Endocode AG, Brückenstraße 5A, 10179 Berlin
info(a)endocode.com | www.endocode.com
Vorstandsvorsitzender: Mirko Boehm
Vorstände: Dr. Thomas Fricke, Sebastian Sucker
Aufsichtsratsvorsitzende: Alexandra Boehm
Registergericht: Amtsgericht
Charlottenburg - HRB 150748 B
3 years
[PATCH 1/4] build: Install DBus policy in /usr/share/dbus-1/system.d
by Jonas Bonn
The default location for DBus policy files should be
/usr/share/dbus-1/system.d and the corresponding directory under /etc
should be reserved for administrative changes to default/packaged
settings. This removes a dependency of ofono on a populated /etc.
---
configure.ac | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index f3148a40..79436adc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,9 +83,9 @@ AC_SUBST(DBUS_LIBS)
AC_ARG_WITH(dbusconfdir, AC_HELP_STRING([--with-dbusconfdir=PATH],
[path to D-Bus config directory]), [path_dbusconf=${withval}],
- [path_dbusconf="`$PKG_CONFIG --variable=sysconfdir dbus-1`"])
+ [path_dbusconf="`$PKG_CONFIG --variable=datadir dbus-1`"])
if (test -z "${path_dbusconf}"); then
- DBUS_CONFDIR="${sysconfdir}/dbus-1/system.d"
+ DBUS_CONFDIR="${datadir}/dbus-1/system.d"
else
DBUS_CONFDIR="${path_dbusconf}/dbus-1/system.d"
fi
--
2.14.1
3 years
