Re: [PATCH 0/5] Add Bluetooth HFP memory index dialing V3
Hi Denis, On 13/02/2018, Denis Kenzior wrote: > I went ahead and applied the entire series. I did fix up a few minor > style & whitespace issues. And the unneeded strcat I forgot to remove ;) Thanks! Philippe ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
Re: [PATCH 2/4] xmm7modem: drop executable bit from C source file
On 02/05/2018 05:20 PM, Denis Kenzior wrote: Hi Jonas, On 02/04/2018 04:55 PM, Jonas Bonn wrote: --- drivers/xmm7modem/ims.c | 0 1 file changed, 0 insertions(+), 0 deletions(-) mode change 100755 => 100644 drivers/xmm7modem/ims.c Applied, thanks. What about the other three patches? Are they being silently rejected or did they just fall off the radar? In particular, patch 1/4 is important... /Jonas Regards, -Denis ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
GPRS Attach/Detach
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
niko...@endocode.com
--
Endocode AG, Brückenstraße 5A, 10179 Berlin
i...@endocode.com | www.endocode.com
Vorstandsvorsitzender: Mirko Boehm
Vorstände: Dr. Thomas Fricke, Sebastian Sucker
Aufsichtsratsvorsitzende: Alexandra Boehm
Registergericht: Amtsgericht
Charlottenburg - HRB 150748 B
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
Re: [PATCH 2/4] xmm7modem: drop executable bit from C source file
Hi Jonas, What about the other three patches? Are they being silently rejected or did they just fall off the radar? In particular, patch 1/4 is important... They're not ignored, but I'm not competent enough to review the build system changes. They need to be acked by Marcel first who can be a bit slow to respond. Regards, -Denis ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
Re: GPRS Attach/Detach
Hi Nikolas,
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.
This particular logic was added in commit:
154f4aca65b3b419239be75d0def276bd7f4dc8e
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?
Doesn't seem to have anything to do with PPP actually. Anyway, there
should be no active contexts if we're detached. Otherwise this will
confuse ConnMan, NetworkManager, etc. The core tries to work around
some of the more common issues, but ultimately the driver needs to make
sure the transitions are well behaved.
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
Re: [PATCH] udevng: Add OFONO_PATHNAME property to set modem dbus path name
Hi Pau,
On 02/13/2018 01:53 PM, Pau Espin Pedrol wrote:
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.
Why should it be deterministic?
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).
Yes, and?
This is non suitable for systems handling several modems which want to
identify them easily based on its path.
This sounds like a very specific non-real world usecase, right? I mean
why don't you simply compare the IMEI if you really care?
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.
I'm hesitant to take this patch as udev logic is already complex and
this doesn't seem to be relevant for anyone else besides your test system.
Example:
$ cat /etc/udev/rules.d/90-local.rules
SUBSYSTEMS=="usb",
DEVPATH=="/devices/pci:00/: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/pci:00/: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
How are you making sure that dbus path is valid? ofono_modem_create
can fail after all...
/mbm_0
---
plugins/udevng.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
Regards,
-Denis
___
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
Re: [PATCH] udevng: Add OFONO_PATHNAME property to set modem dbus path name
Hi Denis, On 14/02/18 18:04, Denis Kenzior wrote: This sounds like a very specific non-real world usecase, right? I mean why don't you simply compare the IMEI if you really care? First of all, I like thinking that I'm part of the real world! As far as I understand the IMEI is available in org.ofono.Modem.GetProperties "Serial" property. To be able to access this information, I need to previously power on the modem (SetProperty Powered true), otherwise it doesn't show up. Which means that for an ofono user, it is a requirement to power on the modem and thus use it before being able to identify it. Simple case: Several modems attached to a PC, in order to find the one I'm interested in I need to power on all of them and find which one matches a given IMEI. Really? Do I need this if I know where is my device always physically attached? Are you going through all your network interfaces and check against its MAC address to find the one you are interested in? Or you configure your network manager based on interface names? Would you enjoy it if your enp0s25 interface was suddenly named enp1s67? Specially if you have iptables rules, I bet that's going to be funny. More complex case (my scenario): Again, I repeat: To identify a modem, as of now, you seem to require to power it on (use it, change its state) before identifying it. Now think of a system which has a config file with modems available on the system (with its dbus paths) and a resources database of modems (and other types of resources) currently in use. Now imagine several processes reserving any specific subset of modems with specific capabilities (in parallel) against the resources database, then using them and among the use cases they power off and power them on. Even if you have locking mechanism in the database, it's a nightmare, because again, you must use a modem before identifying it, meaning you either race condition with other processes using the modem you are identifying (eg. by powering it on, or leaving it powered on after identifying it, or while powering it off after identifying while other process is starting to use it). Then the easy way: Each modem is assigned a unique persistent path, and that's the one always being presented and used. No need to identify it, I already know which modem is which. If I have several system setups, I can assign same names in all systems for easy use, etc. So the question should be better: Why should it NOT be deterministic? How are you making sure that dbus path is valid? ofono_modem_create can fail after all... Yes, it can fail while validating the path (dbus_validate_path) which is expected if a bad OFONO_PATHMNAME is supplied. If it's fine for you, I can add an error message there stating that dbus_validate_path failed and printing the pathname. Agree? -- - Pau Espin Pedrol http://www.sysmocom.de/ === * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
Re: [PATCH] udevng: Add OFONO_PATHNAME property to set modem dbus path name
Hi Pau, As far as I understand the IMEI is available in org.ofono.Modem.GetProperties "Serial" property. To be able to access this information, I need to previously power on the modem (SetProperty Powered true), otherwise it doesn't show up. Which means that for an ofono user, it is a requirement to power on the modem and thus use it before being able to identify it. Correct, but why is this a problem? Under normal circumstances the modems are auto-powered by connman anyway. That's the only reason that oFono doesn't do this automagically. Simple case: Several modems attached to a PC, in order to find the one I'm interested in I need to power on all of them and find which one matches a given IMEI. Really? Do I need this if I know where is my device always physically attached? Are you going through all your network interfaces and check against its MAC address to find the one you are interested in? Or you configure your network manager based on interface names? Would you enjoy it if your enp0s25 interface was suddenly named enp1s67? Specially if you have iptables rules, I bet that's going to be funny. More complex case (my scenario): Again, I repeat: To identify a modem, as of now, you seem to require to power it on (use it, change its state) before identifying it. Now think of a system which has a config file with modems available on the system (with its dbus paths) and a resources database of modems (and other types of resources) currently in use. Now imagine several processes reserving any specific subset of modems with specific capabilities (in parallel) against the resources database, then using them and among the use cases they power off and power them on. Even if you have locking mechanism in the database, it's a nightmare, because again, you must use a modem before identifying it, meaning you either race condition with other processes using the modem you are identifying (eg. by powering it on, or leaving it powered on after identifying it, or while powering it off after identifying while other process is starting to use it). oFono doesn't expose hardware details, only hardware capabilities. So I understand how this is helpful for your usecase, but I'm not convinced this is relevant for what oFono was designed to do. Then the easy way: Each modem is assigned a unique persistent path, and that's the one always being presented and used. No need to identify it, I already know which modem is which. If I have several system setups, I can assign same names in all systems for easy use, etc. > So the question should be better: Why should it NOT be deterministic? In general oFono does not use deterministic paths, the Manager APIs should be used to query the list of objects. In fact the docs even specifically state that the modem object path might have a variable prefix (e.g. a random number) and that variable prefix can change across oFono boots. This is mainly to encourage UI/client writers to use the APIs properly. We have used hardcoded paths in one or two cases for synthetic test cases (e.g. stktest) but those are highly special and not user-visible anyhow. How are you making sure that dbus path is valid? ofono_modem_create can fail after all... Yes, it can fail while validating the path (dbus_validate_path) which is expected if a bad OFONO_PATHMNAME is supplied. If it's fine for you, I can add an error message there stating that dbus_validate_path failed and printing the pathname. Agree? Go ahead and send a V2, I'll let it sit for a week or so to see if anyone else gives any feedback. Regards, -Denis ___ ofono mailing list ofono@ofono.org https://lists.ofono.org/mailman/listinfo/ofono
