Modem contacts

[Anant Kamath]

Hi,

Has the 
org.freedesktop.ModemManager1.Modem.Contactsbeen
tested with any device?

I've been able to send SMS messages using my Huawei E1731 USB modem, but it
doesn't export the Contacts interface on DBus.
Is anyone aware of any (types of) devices that do export this interface?

Regards,
Anant Kamath
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [MM] Question regarding minimum probing time in MMPluginManager

[Dan Williams]

On Fri, 2013-06-28 at 09:32 +0200, Aleksander Morgado wrote:
> > As always, we're very motivated to shave a second or a few hundred
> > milliseconds off the modem startup time :)
> > 
> > I guess a simple solution is to let a plugin specify the max number of
> > ports N, such that the plugin manager will skip the minimum probing
> > time after seeing the completion of N port probes.   A more generic
> > solution would be adding a hook in the plugin to decide whether or not
> > to end the probing process after each port probe finishes.  How do you
> > think?
> 
> Yes, that second option would be cleaner. What I don't know is the
> outcome of that generic method. This is, should the method just disable
> the minimum probing time? Or should it actually ignore further ongoing
> probings (e.g. serial ports being probed for AT or QCDM) once we get the
> minimum set of ports we wanted?

One problem is how the plugin knows that specific ports are primary or
secondary or what.  You typically don't get this information without
tagging specific USB interface numbers like Windows does, and even then
we have had cases of this changing on firmware upgrades.  So I'm not
sure the generic  method should be too aggressive here, instead I think
it should be opt-in on a per-plugin or per-device basis.

Only if you're 100% sure about the layout of a specific modem (and we
have to be very careful that the USB VID/PID aren't re-used bewteen
different devices like ZTE and Huawei often do) should the current probe
process be bypassed.

Dan

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

NM-Applet on F18 fails to save Vpnc Group Password

[Derek Atkins]

Hi,

I just upgraded my system from F15 to F18 and I use the VPNC plugin to
connect to my corporate VPN.  My VPN configuration was working fine in
F15 but didn't seem to transfer correctly to F18.  In particular, even
though the Edit Connections for the VPN config shows a Group Password
and has it marked as "Saved", every time I try to bring up the VPN it
asks me for my password *and* the group password.  This is particularly
the case if I bring the VPN down myself, although I believe it also
happens if the VPN dies on its own after ~24 hours.

Is this a known bug?  Is there some way I can fix this?  It's quite
annoying to have to type in (or even cut-and-paste) this random value
every day I want to bring up the VPN.

Thanks,

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How frequently org.freedektop.ModemManager.Modem.Cdma.SignalQuality signals signal strength?

[satya gowtham kudupudi]

And also i left monitoring signal entire night (6hrs) with out any data
transmission, I got only 40 to 50 signals against 360 signals(a signal for
30sec).


On Fri, Jun 28, 2013 at 7:34 PM, satya gowtham kudupudi <
satyagowtha...@gmail.com> wrote:

> MM really polls every 30s? I got only 5 signals in span of 1hr. during
> that hour im streaming a video. though there is continuous data
> ttransmission does MM polls every 30s?
>
>
> On Fri, Jun 28, 2013 at 11:09 AM, Aleksander Morgado <
> aleksan...@lanedo.com> wrote:
>
>> On 28/06/13 05:05, satya gowtham kudupudi wrote:
>> > Does the proxy signals everytime there is a change in signal strength
>> > asynchonously or ModemManager polls modem periodically to get signal
>> > quality?
>>
>>
>> That depends on the modem being used; if the modem supports unsolicited
>> quality change indications, we'll use them; otherwise MM will poll every
>> 30s for signal quality values. The property values in the interface will
>> be updated once we get the new values (more or less).
>>
>> --
>> Aleksander
>>
>
>
>
> --
> *- Gowtham*
>



-- 
*- Gowtham*
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How frequently org.freedektop.ModemManager.Modem.Cdma.SignalQuality signals signal strength?

[Aleksander Morgado]

On 28/06/13 16:04, satya gowtham kudupudi wrote:
> MM really polls every 30s? I got only 5 signals in span of 1hr. during
> that hour im streaming a video. though there is continuous data
> ttransmission does MM polls every 30s?

If the values don't change they probably won't be re-set in the
interface.  But just run MM in debug mode and check what is doing :)

-- 
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How frequently org.freedektop.ModemManager.Modem.Cdma.SignalQuality signals signal strength?

[satya gowtham kudupudi]

MM really polls every 30s? I got only 5 signals in span of 1hr. during that
hour im streaming a video. though there is continuous data ttransmission
does MM polls every 30s?


On Fri, Jun 28, 2013 at 11:09 AM, Aleksander Morgado
wrote:

> On 28/06/13 05:05, satya gowtham kudupudi wrote:
> > Does the proxy signals everytime there is a change in signal strength
> > asynchonously or ModemManager polls modem periodically to get signal
> > quality?
>
>
> That depends on the modem being used; if the modem supports unsolicited
> quality change indications, we'll use them; otherwise MM will poll every
> 30s for signal quality values. The property values in the interface will
> be updated once we get the new values (more or less).
>
> --
> Aleksander
>



-- 
*- Gowtham*
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: discuss: NM server defaults

[Dan Winship]

So the relevant tweakable options are:


- no-auto-default=[interfaces]

Disables automatically-created DHCP ethernet connections. Everyone
agrees we want "no-auto-default=*" for servers.


- ignore-carrier=[interfaces]

Disables carrier-detect on the indicated interfaces. There's been some
internal RH networking services team discussion about these options, and
the consensus seemed to be that we definitely want this behavior for
interfaces with static IP addresses, but we can't enable it by default
everywhere because its current behavior with DHCP interfaces is sort of
broken. But we can fix that by changing it so that if DHCP times out due
to lack of carrier, and then carrier comes on, we retry dhcp at that
point (but we still ignore carrier in all other cases, and in
particular, we still always ignore carrier-off).

Given that change, then we would want "ignore-carrier=*" set on servers.


- monitor-connection-files=false

I think we also want this by default on servers; it is more consistent
with pre-NM ways of doing things, and makes it less easy to accidentally
shoot yourself in the foot.

In fact, I think we want to change things around so that "false" is the
default value of the option everywhere, and you need to override it if
you want the old behavior.


- dns=none

This disables NM's management of resolv.conf, which some people want for
various reasons, but I don't think we want this in the server defaults.

___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

[ANN] New mailing list for ModemManager

[Aleksander Morgado]

Hey,

We're in the process of moving ModemManager fully to freedesktop.org
(see [1] and [2]), and as part of the move, we now also have a new
mailing list for general ModemManager discussions, including patches and
the like:

  mailto:modemmanager-de...@lists.freedesktop.org

  http://lists.freedesktop.org/mailman/listinfo/modemmanager-devel

So, from now on, please use this mailing list if the topic of the
communication is ModemManager related, not NetworkManager related.

We'll also move MM's bugs to freedesktop.org bugzilla, but that is not
ready yet.

Thanks!

[1] https://bugzilla.gnome.org/show_bug.cgi?id=699402
[2] https://bugs.freedesktop.org/show_bug.cgi?id=64325

-- 
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [MM] Question regarding minimum probing time in MMPluginManager

[Aleksander Morgado]

> As always, we're very motivated to shave a second or a few hundred
> milliseconds off the modem startup time :)
> 
> I guess a simple solution is to let a plugin specify the max number of
> ports N, such that the plugin manager will skip the minimum probing
> time after seeing the completion of N port probes.   A more generic
> solution would be adding a hook in the plugin to decide whether or not
> to end the probing process after each port probe finishes.  How do you
> think?

Yes, that second option would be cleaner. What I don't know is the
outcome of that generic method. This is, should the method just disable
the minimum probing time? Or should it actually ignore further ongoing
probings (e.g. serial ports being probed for AT or QCDM) once we get the
minimum set of ports we wanted?

-- 
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [MM] Question regarding minimum probing time in MMPluginManager

[Ben Chan]

Aleksander,

As always, we're very motivated to shave a second or a few hundred
milliseconds off the modem startup time :)

I guess a simple solution is to let a plugin specify the max number of
ports N, such that the plugin manager will skip the minimum probing
time after seeing the completion of N port probes.   A more generic
solution would be adding a hook in the plugin to decide whether or not
to end the probing process after each port probe finishes.  How do you
think?

Thanks,
Ben

On Fri, Jun 28, 2013 at 12:13 AM, Aleksander Morgado
 wrote:
>
>> The following code in MMPluginManager seems to always wait until the
>> minimum probing time is consumed.
>>
>> /* If we didn't use the minimum probing time, wait for it to finish */
>> else if (ctx->timeout_id > 0) {
>> mm_dbg ("(Plugin Manager) '%s' port probe finished, last one
>> in device, "
>> "but minimum probing time not consumed yet ('%lf'
>> seconds elapsed)",
>> g_udev_device_get_name (port_probe_ctx->port),
>> g_timer_elapsed (ctx->timer, NULL));
>>
>> For a modem with known port layout (assuming we have a way to specify
>> in the plugin), once all port probes finish, should MMPluginManager
>> proceed without waiting for the minimum probing time to expire? Is
>> there a potential downside? The obvious upside is cutting the modem
>> startup time.
>>
>
> This is just to let the kernel some time to expose all the ports, and
> should only be a couple of seconds max. If the first probe is exposed
> and right away probed, and there is no other port around when the
> probing finishes, the whole device probing is assumed finished. Newer
> ports appearing afterwards should still get grabbed by the already
> created modem, but these ports will not take part in the probing
> decisions. But of course, if we have a way to specify the expected port
> layout in the plugin itself (in very device-specific plugins like the
> novatel-lte or altair-lte), then there is no point in waiting the
> minimum probing time if we already got the expected layout, of course.
>
> --
> Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [MM] Question regarding minimum probing time in MMPluginManager

[Aleksander Morgado]

> The following code in MMPluginManager seems to always wait until the
> minimum probing time is consumed.
> 
> /* If we didn't use the minimum probing time, wait for it to finish */
> else if (ctx->timeout_id > 0) {
> mm_dbg ("(Plugin Manager) '%s' port probe finished, last one
> in device, "
> "but minimum probing time not consumed yet ('%lf'
> seconds elapsed)",
> g_udev_device_get_name (port_probe_ctx->port),
> g_timer_elapsed (ctx->timer, NULL));
> 
> For a modem with known port layout (assuming we have a way to specify
> in the plugin), once all port probes finish, should MMPluginManager
> proceed without waiting for the minimum probing time to expire? Is
> there a potential downside? The obvious upside is cutting the modem
> startup time.
> 

This is just to let the kernel some time to expose all the ports, and
should only be a couple of seconds max. If the first probe is exposed
and right away probed, and there is no other port around when the
probing finishes, the whole device probing is assumed finished. Newer
ports appearing afterwards should still get grabbed by the already
created modem, but these ports will not take part in the probing
decisions. But of course, if we have a way to specify the expected port
layout in the plugin itself (in very device-specific plugins like the
novatel-lte or altair-lte), then there is no point in waiting the
minimum probing time if we already got the expected layout, of course.

-- 
Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list