Bearer MTU not recognised by NetworkManager
Hi, I’m observing that NetworkManager (v1.20.2) does not recognise the MTU (=1360) exposed by the ModemManager’s (v1.10.6) bearer object and instead uses some default value (=1500). This seems to lead to issues which are fixed when manually setting the MTU to a lower value. When checking the NetworkManager’s connection settings, gsm.mtu is set to “auto". I’m observing this on a Quectel BG96 hooked up via QMI. My kernel version is 4.19.87. Is this a known issue? Is anyone aware whether this is fixed upstream? Thanks, Sven ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Telit LE910C1 - GPS integration
Hey David, > > > > > > > > With all enable it only shows the 3GPP info with mmcli -m 0 > > > > --loction-get > > > > > > Daniele, any idea why we're not receiving NMEA traces via QMI > > > indications in this case? Do you see something wrong in the sequence > > > to enable the GNSS location gathering? > > > > > > > The sequence is missing request QMI_LOC_SET_NMEA_TYPES that is not in > > libqmi. The request is needed to indicate which NMEA sentences should > > be enabled. > > > > Ah! good to know, thanks. I'll add that. Do you know since when is > this a requirement? I don't think any other modem I tested with > required this message explicitly. > Could you clone and build the following libqmi branch? https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/115 Once you have it, you'll be able to configure the NMEA traces via qmicli, e.g.: $ sudo qmicli -d /dev/cdc-wdm1 -p --loc-set-nmea-types="gga|gsa|gsv" And once you have done that, could you re-run ModemManager to see if we do receive the NMEA traces this time? -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
On Thu, May 7, 2020 at 4:23 PM Enrico Mioso wrote:
>
> Oh, sorry. It makes sense due to the way C structs work, so i may use
> struct _AvModem {
You still need to define the parent GObject here.
>MMObject mmobject;
>/* other members */
> };
>
> Still, if all is OK I should be able to do something like:
> mm_object_get_modem(MM_OBJECT(m));
>
> or am I mistaken?
> currently, this fails...
>
> thanks again,
> Enrico
>
>
> On Thu, 7 May 2020, Enrico Mioso wrote:
>
> > Date: Thu, 7 May 2020 15:59:44
> > From: Enrico Mioso
> > To: Aleksander Morgado
> > Cc: "ModemManager (development)" ,
> > marco.perini1...@gmail.com
> > Subject: Re: Correct connection sequence to maximize chances of e.g.:
> > getting
> > connected :)
> >
> > Ok, now things are a little bit clearer. However, when running my test code
> > I
> > face the issue:
> > Creating object:
> >
> > (process:45799): GLib-GObject-WARNING **: 15:52:57.565: specified instance
> > size for type 'AvModem' is smaller than the parent type's 'GObject' instance
> > size
> >
> > (process:45799): GLib-CRITICAL **: 15:52:57.565: g_once_init_leave:
> > assertion
> > 'result != 0' failed
> >
> > (process:45799): GLib-GObject-CRITICAL **: 15:52:57.565:
> > g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
> > failed
> >
> > (process:45799): GLib-GObject-CRITICAL **: 15:52:57.565: g_object_unref:
> > assertion 'G_IS_OBJECT (object)' failed
> >
> > I guess I am missing some details about declaring MMObjectclass is my parent
> > class.
> > I can't understand them from the GObjects doc, even tough they seem pretty
> > well written, once you grasp the context.
> >
> > With final type I was able to drop some code. Now my objecct skel looks as
> > follows:
> >
> > /* header */
> > #ifndef __main_h__
> > #define __main_h__
> >
> > #include
> > #include
> >
> > G_BEGIN_DECLS
> > #define AV_TYPE_MODEM av_modem_get_type()
> > G_DECLARE_FINAL_TYPE(AvModem, av_modem, AV, MODEM, GObject)
> >
> > AvModem *av_modem_new(void);
> >
> > G_END_DECLS
> >
> > #endif
> >
> > /* source */
> >
> > #include
> > #include
> > #include
> >
> > struct _AvModem {
> > MMObject *mmobject;
> > /* other members */
> > };
> >
> > G_DEFINE_TYPE(AvModem, av_modem, G_TYPE_OBJECT)
> >
> > static void av_modem_init(AvModem *self) {
> > g_print("%s invoked\n",__FUNCTION__);
> > /* here we would g_object_new and things */
> > /* initialize all public and private members to reasonable default
> > values.
> >* They are all automatically initialized to 0 to begin with. */
> > }
> >
> > static void av_modem_dispose(GObject *gobject) {
> > g_print("%s invoked\n",__FUNCTION__);
> > /* In dispose(), you are supposed to free all types referenced from
> > this
> >* object which might themselves hold a reference to self. Generally,
> >* the most simple solution is to unref all members on which you own
> > a
> >* reference.
> >*/
> >
> > /* time to g_object_clear things */
> > G_OBJECT_CLASS (av_modem_parent_class)->dispose (gobject);
> > }
> >
> > static void av_modem_finalize(GObject *gobject) {
> > g_print("%s invoked\n",__FUNCTION__);
> > /* e.g.: g_free for filename */
> > G_OBJECT_CLASS (av_modem_parent_class)->finalize (gobject);
> > }
> >
> > static void av_modem_class_init(AvModemClass *klass) {
> > g_print("%s invoked\n",__FUNCTION__);
> > GObjectClass *object_class = G_OBJECT_CLASS (klass);
> > object_class->dispose = av_modem_dispose;
> > object_class->finalize = av_modem_finalize;
> > }
> >
> > AvModem *av_modem_new(void) {
> > AvModem *m;
> > m = g_object_new(AV_TYPE_MODEM, NULL);
> > return m;
> > }
> >
> > gint main(void) {
> > AvModem *m;
> > g_print("Creating object:\n");
> > m = av_modem_new();
> > g_object_unref(m);
> > return 0;
> > }
> >
> > It works if I use
> > MMObject m;
> > instead of *m as my _AvModem struct member, which is not the right solution
> > I
> > know...
> > Second, the final objective is to have
> >
> > AvModem *av_modem_new(MMObject *m);
> >
> > And I guess inside the function I can use a simple assignment due to the
> > fact
> > the compiler still knows the structure in the C file.
> >
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Hey!
>
> (process:45799): GLib-GObject-WARNING **: 15:52:57.565: specified instance
> size for type 'AvModem' is smaller than the parent type's 'GObject' instance
> size
>
The first element in the AvModem struct that you define must be equal
to the parent object the new type inherits from. In your case, the
first element in the struct must be a "GObject parent;"
>
> struct _AvModem {
GObject parent;
> MMObject *mmobject;
> /* other members */
> };
>
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Telit LE910C1 - GPS integration
Hey Daniele, > > > > Then we need to debug why we were not able to get any LOC indication > > > > with NMEA traces in David's setup. > > > > > > > David, could you retry to setup the location using the QMI protocol > > > > (i.e. without your changes) but enabling both "nmea" and "raw" > > > > locations? > > > > Also, another test could be to enable MSB A-GPS or MSA A-GPS and see > > > > what happens. > > > > > > Sure, here are the logs: > > > > > > mmcli -m 0 > > > --- > > > General |dbus path: /org/freedesktop/ModemManager1/Modem/0 > > >|device id: > > > 3722d156689e3dccd0080cdb2418e5159e13c738 > > > > > > Hardware | manufacturer: QUALCOMM INCORPORATED > > >|model: LE910C1-NA > > >|firmware revision: 25.00.212 1 [Feb 03 2017 10:00:00] > > >| carrier config: default > > >| h/w revision: 1 > > >|supported: gsm-umts, lte > > >| current: gsm-umts, lte > > >| equipment id: * > > > > > > System | device: > > > /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1 > > >| drivers: option1, qmi_wwan > > >| plugin: Telit > > >| primary port: cdc-wdm0 > > >|ports: ttyUSB0 (unknown), ttyUSB1 (gps), > > > ttyUSB2 (at), > > >| cdc-wdm0 (qmi), wwan0 (net), ttyUSB4 > > > (unknown), ttyUSB3 (at) > > > > > > Status | lock: sim-pin2 > > >| unlock retries: sim-pin (5), sim-pin2 (5), sim-puk > > > (10), sim-puk2 (10) > > >|state: connected > > >| power state: on > > >| access tech: umts > > >| signal quality: 57% (recent) > > > > > > Modes|supported: allowed: 2g; preferred: none > > >| allowed: 3g; preferred: none > > >| allowed: 4g; preferred: none > > >| allowed: 2g, 3g; preferred: 3g > > >| allowed: 2g, 3g; preferred: 2g > > >| allowed: 2g, 4g; preferred: 4g > > >| allowed: 2g, 4g; preferred: 2g > > >| allowed: 3g, 4g; preferred: 3g > > >| allowed: 3g, 4g; preferred: 4g > > >| allowed: 2g, 3g, 4g; preferred: 4g > > >| allowed: 2g, 3g, 4g; preferred: 3g > > >| allowed: 2g, 3g, 4g; preferred: 2g > > >| current: allowed: 2g, 3g, 4g; preferred: 3g > > > > > > Bands|supported: egsm, dcs, pcs, g850, utran-1, > > > utran-4, utran-5, utran-8, > > >| utran-2, eutran-2, eutran-4, eutran-12 > > >| current: egsm, dcs, pcs, g850, utran-1, > > > utran-4, utran-5, utran-8, > > >| utran-2, eutran-2, eutran-4, eutran-12 > > > > > > IP |supported: ipv4, ipv6, ipv4v6 > > > > > > 3GPP | imei: * > > >| operator id: * > > >|operator name: * > > >| registration: home > > > > > > 3GPP EPS | ue mode of operation: csps-1 > > > > > > SIM |dbus path: /org/freedesktop/ModemManager1/SIM/0 > > > > > > Bearer |dbus path: /org/freedesktop/ModemManager1/Bearer/0 > > > --- > > > > > > > > > mmcli -m 0 --location-enable-gps-raw > > > --- > > > [1588613175.107558] Setting up location sources: '3gpp-lac-ci, > > > gps-raw' > > > [1588613175.107665] Location '3gpp-lac-ci' gathering is already > > > enabled... > > > [1588613175.107700] Location 'gps-nmea' gathering is already > > > disabled... > > > [1588613175.107729] Location 'agps-msa' gathering is already > > > disabled... > > > [1588613175.107752] Location 'agps-msb' gathering is already > > > disabled... > > > [1588613175.107773] Need to enable the following location > > > sources: 'gps-raw' > > > [/dev/cdc-wdm0] sent message... > > > << RAW: > > > << length = 38 > > > << data = > > >
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Oh, sorry. It makes sense due to the way C structs work, so i may use
struct _AvModem {
MMObject mmobject;
/* other members */
};
Still, if all is OK I should be able to do something like:
mm_object_get_modem(MM_OBJECT(m));
or am I mistaken?
currently, this fails...
thanks again,
Enrico
On Thu, 7 May 2020, Enrico Mioso wrote:
Date: Thu, 7 May 2020 15:59:44
From: Enrico Mioso
To: Aleksander Morgado
Cc: "ModemManager (development)" ,
marco.perini1...@gmail.com
Subject: Re: Correct connection sequence to maximize chances of e.g.: getting
connected :)
Ok, now things are a little bit clearer. However, when running my test code I
face the issue:
Creating object:
(process:45799): GLib-GObject-WARNING **: 15:52:57.565: specified instance
size for type 'AvModem' is smaller than the parent type's 'GObject' instance
size
(process:45799): GLib-CRITICAL **: 15:52:57.565: g_once_init_leave: assertion
'result != 0' failed
(process:45799): GLib-GObject-CRITICAL **: 15:52:57.565:
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)'
failed
(process:45799): GLib-GObject-CRITICAL **: 15:52:57.565: g_object_unref:
assertion 'G_IS_OBJECT (object)' failed
I guess I am missing some details about declaring MMObjectclass is my parent
class.
I can't understand them from the GObjects doc, even tough they seem pretty
well written, once you grasp the context.
With final type I was able to drop some code. Now my objecct skel looks as
follows:
/* header */
#ifndef __main_h__
#define __main_h__
#include
#include
G_BEGIN_DECLS
#define AV_TYPE_MODEM av_modem_get_type()
G_DECLARE_FINAL_TYPE(AvModem, av_modem, AV, MODEM, GObject)
AvModem *av_modem_new(void);
G_END_DECLS
#endif
/* source */
#include
#include
#include
struct _AvModem {
MMObject *mmobject;
/* other members */
};
G_DEFINE_TYPE(AvModem, av_modem, G_TYPE_OBJECT)
static void av_modem_init(AvModem *self) {
g_print("%s invoked\n",__FUNCTION__);
/* here we would g_object_new and things */
/* initialize all public and private members to reasonable default
values.
* They are all automatically initialized to 0 to begin with. */
}
static void av_modem_dispose(GObject *gobject) {
g_print("%s invoked\n",__FUNCTION__);
/* In dispose(), you are supposed to free all types referenced from
this
* object which might themselves hold a reference to self. Generally,
* the most simple solution is to unref all members on which you own
a
* reference.
*/
/* time to g_object_clear things */
G_OBJECT_CLASS (av_modem_parent_class)->dispose (gobject);
}
static void av_modem_finalize(GObject *gobject) {
g_print("%s invoked\n",__FUNCTION__);
/* e.g.: g_free for filename */
G_OBJECT_CLASS (av_modem_parent_class)->finalize (gobject);
}
static void av_modem_class_init(AvModemClass *klass) {
g_print("%s invoked\n",__FUNCTION__);
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->dispose = av_modem_dispose;
object_class->finalize = av_modem_finalize;
}
AvModem *av_modem_new(void) {
AvModem *m;
m = g_object_new(AV_TYPE_MODEM, NULL);
return m;
}
gint main(void) {
AvModem *m;
g_print("Creating object:\n");
m = av_modem_new();
g_object_unref(m);
return 0;
}
It works if I use
MMObject m;
instead of *m as my _AvModem struct member, which is not the right solution I
know...
Second, the final objective is to have
AvModem *av_modem_new(MMObject *m);
And I guess inside the function I can use a simple assignment due to the fact
the compiler still knows the structure in the C file.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Bearer MTU not recognised by NetworkManager
Hi!! The relevant code is in NetworkManager/src/devices/wwan . In my impression NM doesn't ask MM for the MTU, using it's own (default) values for that. Note that it's only my impression from a superficial look. Hence, assuming I am right, I guess this isn't a MM related issue. Enrico On Thu, 7 May 2020, Sven Schwermer wrote: Date: Thu, 7 May 2020 15:43:51 From: Sven Schwermer To: "ModemManager (development)" Subject: Bearer MTU not recognised by NetworkManager Hi, I’m observing that NetworkManager (v1.20.2) does not recognise the MTU (=1360) exposed by the ModemManager’s (v1.10.6) bearer object and instead uses some default value (=1500). This seems to lead to issues which are fixed when manually setting the MTU to a lower value. When checking the NetworkManager’s connection settings, gsm.mtu is set to “auto". I’m observing this on a Quectel BG96 hooked up via QMI. My kernel version is 4.19.87. Is this a known issue? Is anyone aware whether this is fixed upstream? Thanks, Sven ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Ok, now things are a little bit clearer. However, when running my test code I
face the issue:
Creating object:
(process:45799): GLib-GObject-WARNING **: 15:52:57.565: specified instance size
for type 'AvModem' is smaller than the parent type's 'GObject' instance size
(process:45799): GLib-CRITICAL **: 15:52:57.565: g_once_init_leave: assertion
'result != 0' failed
(process:45799): GLib-GObject-CRITICAL **: 15:52:57.565:
g_object_new_with_properties: assertion 'G_TYPE_IS_OBJECT (object_type)' failed
(process:45799): GLib-GObject-CRITICAL **: 15:52:57.565: g_object_unref:
assertion 'G_IS_OBJECT (object)' failed
I guess I am missing some details about declaring MMObjectclass is my parent
class.
I can't understand them from the GObjects doc, even tough they seem pretty well
written, once you grasp the context.
With final type I was able to drop some code. Now my objecct skel looks as
follows:
/* header */
#ifndef __main_h__
#define __main_h__
#include
#include
G_BEGIN_DECLS
#define AV_TYPE_MODEM av_modem_get_type()
G_DECLARE_FINAL_TYPE(AvModem, av_modem, AV, MODEM, GObject)
AvModem *av_modem_new(void);
G_END_DECLS
#endif
/* source */
#include
#include
#include
struct _AvModem {
MMObject *mmobject;
/* other members */
};
G_DEFINE_TYPE(AvModem, av_modem, G_TYPE_OBJECT)
static void av_modem_init(AvModem *self) {
g_print("%s invoked\n",__FUNCTION__);
/* here we would g_object_new and things */
/* initialize all public and private members to reasonable default
values.
* They are all automatically initialized to 0 to begin with. */
}
static void av_modem_dispose(GObject *gobject) {
g_print("%s invoked\n",__FUNCTION__);
/* In dispose(), you are supposed to free all types referenced from this
* object which might themselves hold a reference to self. Generally,
* the most simple solution is to unref all members on which you own a
* reference.
*/
/* time to g_object_clear things */
G_OBJECT_CLASS (av_modem_parent_class)->dispose (gobject);
}
static void av_modem_finalize(GObject *gobject) {
g_print("%s invoked\n",__FUNCTION__);
/* e.g.: g_free for filename */
G_OBJECT_CLASS (av_modem_parent_class)->finalize (gobject);
}
static void av_modem_class_init(AvModemClass *klass) {
g_print("%s invoked\n",__FUNCTION__);
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->dispose = av_modem_dispose;
object_class->finalize = av_modem_finalize;
}
AvModem *av_modem_new(void) {
AvModem *m;
m = g_object_new(AV_TYPE_MODEM, NULL);
return m;
}
gint main(void) {
AvModem *m;
g_print("Creating object:\n");
m = av_modem_new();
g_object_unref(m);
return 0;
}
It works if I use
MMObject m;
instead of *m as my _AvModem struct member, which is not the right solution I
know...
Second, the final objective is to have
AvModem *av_modem_new(MMObject *m);
And I guess inside the function I can use a simple assignment due to the fact
the compiler still knows the structure in the C file.
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
thank you very very much!! Really.
Enrico
On Thu, 7 May 2020, Aleksander Morgado wrote:
Date: Thu, 7 May 2020 09:34:46
From: Aleksander Morgado
To: Enrico Mioso
Cc: "ModemManager (development)" ,
marco.perini1...@gmail.com
Subject: Re: Correct connection sequence to maximize chances of e.g.: getting
connected :)
Hey!
Sorry for deleting the quoted text every time, but without doing so, answers
may result complicated to read confortably for me.
So, in the end I came to the conclusion that using GObjects is probably the
best course of cation :)
So I am studying the GLib GObjects page for details, and started writing some
code to try to understand things better.
Goal: implement a GObject who can act as a container for:
- MMObjects, MMModem objects, MMModemVoice objects
- (long) integers for GSignals handlers and other data.
I managed to get my code to compile, but would like some hints /
recommendations on how I may proceed.
Ok.
My header:
#ifndef __main_h__
#define __main_h__
#include
#include
G_BEGIN_DECLS
#define AV_TYPE_MODEM av_modem_get_type()
G_DECLARE_DERIVABLE_TYPE(AvModem, av_modem, AV, MODEM, GObject)
In your case, you're probably not going to create subclasses of the
AvModem object, so you can easier use G_DECLARE_FINAL_TYPE and
completely avoid the need of having a "private" struct. With final
types, you can have all your internal data in the AvModem struct
itself.
struct _AvModemClass {
MMObjectClass parent_class;
/* functions ... */
The functions in the class are only needed if you're going to subclass
the class, which you're not going to.
/* padding with things like
gpointer padding[12];
*/
And padding is only required if you're making this class "public", in
order to leave some safe space to grow the class in the future. You
can also ignore this.
};
AvModem *av_modem_new(void);
G_END_DECLS
#endif
Source:
#include
#include
#include
typedef struct {
gchar *filename;
} AvModemPrivate;
As said, if you use a final type you could add the filename variable
in the AvModem struct itself in the header. The ModemManager sources
don't do this because these macros were introduced in newer GLib
versions; we could probably do some porting now that we require newer
releases as well.
G_DEFINE_TYPE_WITH_PRIVATE (AvModem, av_modem, G_TYPE_OBJECT)
static void av_modem_init(AvModem *self) {
g_print("__FUNCTION__ invoked\n");
AvModemPrivate *priv = av_modem_get_instance_private(self);
/* here we would g_object_new and things */
/* initialize all public and private members to reasonable default
values.
* They are all automatically initialized to 0 to begin with. */
}
static void av_modem_dispose(GObject *gobject) {
g_print("__FUNCTION__ invoked\n");
AvModemPrivate *priv = av_modem_get_instance_private(AV_MODEM(gobject));
/* In dispose(), you are supposed to free all types referenced from this
* object which might themselves hold a reference to self. Generally,
* the most simple solution is to unref all members on which you own a
* reference.
*/
/* time to g_object_clear things */
Yes. It's very important that pointers in dispose() are re-set to NULL
after freeing. E.g. use g_clear_object(), g_clear_pointer() and such.
This is because dispose may be called multiple times.
G_OBJECT_CLASS (av_modem_parent_class)->dispose (gobject);
}
static void av_modem_finalize(GObject *gobject) {
g_print("__FUNCTION__ invoked\n");
AvModemPrivate *priv = av_modem_get_instance_private(AV_MODEM(gobject));
/* e.g.: g_free for filename */
Finalize is only called once, so no need to re-set pointers to NULL
after freeing.
G_OBJECT_CLASS (av_modem_parent_class)->finalize (gobject);
}
static void av_modem_class_init(AvModemClass *klass) {
g_print("__FUNCTION__ invoked\n");
GObjectClass *object_class = G_OBJECT_CLASS (klass);
object_class->dispose = av_modem_dispose;
object_class->finalize = av_modem_finalize;
}
gint main(void) {
return 0;
}
I see you use various convenience macros in libmm-glib headers, but I am trying
to do things step by step to understand them.
The convenience macros are probably older GLib macros. The new macros
require less amount of them.
I may have used GBoxed to wrap my own structs instead, but I am trying to do
what's better.
You only need GBoxed for your own structs if they're going to be set
as object properties.
I absoulutely need refcounting in this scenario. :)
Yes! (which is good)
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Telit LE910C1 - GPS integration
Hi Aleksander and David, Il giorno mar 5 mag 2020 alle ore 17:14 Aleksander Morgado ha scritto: > > Hey Daniele & David > > > > Then we need to debug why we were not able to get any LOC indication > > > with NMEA traces in David's setup. > > > > > David, could you retry to setup the location using the QMI protocol > > > (i.e. without your changes) but enabling both "nmea" and "raw" > > > locations? > > > Also, another test could be to enable MSB A-GPS or MSA A-GPS and see > > > what happens. > > > > Sure, here are the logs: > > > > mmcli -m 0 > > --- > > General |dbus path: /org/freedesktop/ModemManager1/Modem/0 > >|device id: 3722d156689e3dccd0080cdb2418e5159e13c738 > > > > Hardware | manufacturer: QUALCOMM INCORPORATED > >|model: LE910C1-NA > >|firmware revision: 25.00.212 1 [Feb 03 2017 10:00:00] > >| carrier config: default > >| h/w revision: 1 > >|supported: gsm-umts, lte > >| current: gsm-umts, lte > >| equipment id: * > > > > System | device: > > /sys/devices/soc0/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb2/2-1 > >| drivers: option1, qmi_wwan > >| plugin: Telit > >| primary port: cdc-wdm0 > >|ports: ttyUSB0 (unknown), ttyUSB1 (gps), > > ttyUSB2 (at), > >| cdc-wdm0 (qmi), wwan0 (net), ttyUSB4 > > (unknown), ttyUSB3 (at) > > > > Status | lock: sim-pin2 > >| unlock retries: sim-pin (5), sim-pin2 (5), sim-puk (10), > > sim-puk2 (10) > >|state: connected > >| power state: on > >| access tech: umts > >| signal quality: 57% (recent) > > > > Modes|supported: allowed: 2g; preferred: none > >| allowed: 3g; preferred: none > >| allowed: 4g; preferred: none > >| allowed: 2g, 3g; preferred: 3g > >| allowed: 2g, 3g; preferred: 2g > >| allowed: 2g, 4g; preferred: 4g > >| allowed: 2g, 4g; preferred: 2g > >| allowed: 3g, 4g; preferred: 3g > >| allowed: 3g, 4g; preferred: 4g > >| allowed: 2g, 3g, 4g; preferred: 4g > >| allowed: 2g, 3g, 4g; preferred: 3g > >| allowed: 2g, 3g, 4g; preferred: 2g > >| current: allowed: 2g, 3g, 4g; preferred: 3g > > > > Bands|supported: egsm, dcs, pcs, g850, utran-1, utran-4, > > utran-5, utran-8, > >| utran-2, eutran-2, eutran-4, eutran-12 > >| current: egsm, dcs, pcs, g850, utran-1, utran-4, > > utran-5, utran-8, > >| utran-2, eutran-2, eutran-4, eutran-12 > > > > IP |supported: ipv4, ipv6, ipv4v6 > > > > 3GPP | imei: * > >| operator id: * > >|operator name: * > >| registration: home > > > > 3GPP EPS | ue mode of operation: csps-1 > > > > SIM |dbus path: /org/freedesktop/ModemManager1/SIM/0 > > > > Bearer |dbus path: /org/freedesktop/ModemManager1/Bearer/0 > > --- > > > > > > mmcli -m 0 --location-enable-gps-raw > > --- > > [1588613175.107558] Setting up location sources: '3gpp-lac-ci, > > gps-raw' > > [1588613175.107665] Location '3gpp-lac-ci' gathering is already > > enabled... > > [1588613175.107700] Location 'gps-nmea' gathering is already > > disabled... > > [1588613175.107729] Location 'agps-msa' gathering is already > > disabled... > > [1588613175.107752] Location 'agps-msb' gathering is already > > disabled... > > [1588613175.107773] Need to enable the following location sources: > > 'gps-raw' > > [/dev/cdc-wdm0] sent message... > > << RAW: > > << length = 38 > > << data = > >
Re: Understanding log sequence of events to debug hangup?
Hey! First I'd like to say what a great project! I've got numerous customers > using this now, and am impressed by the capabilities and breadth of support > for modems. > > I've run into an issue with a customer who is using ModemManager with a > u-blox modem, and we're seeing a hangup that is being reported after the > roaming registration is complete on AT When we look at our mobile core, > the modem appears to be connected and given an IP address, and the > connection is still up when the hangup is being reported. > > I'm doing my best to interpret the logs, and they are very readable. I do > see the sequence of events leading up to the " [1588357729.967755] > (ttyACM1) unexpected port hangup!" (in this particular log) but am not > clear on how/why this is happening. I'm assuming that maybe this is > detected with a RTS/CTS indication? > > Here are the relevant logs: [1588357729.881386] (ttyACM1): --> 'AT+CGACT?' [1588357729.967755] (ttyACM1) unexpected port hangup! [1588357729.976456] (ttyACM1) forced to close port [1588357729.981632] (ttyACM1) device open count is 0 (close) [1588357729.988668] (ttyACM1) closing serial port... [1588357730.008063] (ttyACM1) serial port closed [1588357730.018495] checking if connected failed: Couldn't check current list of active PDP contexts: Serial port is now closed [1588357730.024490] (tty/ttyACM0): released by device '/sys/devices/platform/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1' [1588357730.034720] (tty/ttyACM1): released by device '/sys/devices/platform/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1' [1588357730.050015] (tty/ttyACM2): released by device '/sys/devices/platform/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1' [1588357730.076956] (tty/ttyACM3): released by device '/sys/devices/platform/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1' [1588357730.093692] (tty/ttyACM4): released by device '/sys/devices/platform/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1' [1588357730.108045] (tty/ttyACM5): released by device '/sys/devices/platform/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1' [1588357730.115839] Removing empty device '/sys/devices/platform/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1' [1588357730.125628] Removing from DBus bearer at '/org/freedesktop/ModemManager1/Bearer/0' [1588357730.133782] [device /sys/devices/platform/soc/210.aips-bus/2184200.usb/ci_hdrc.1/usb1/1-1] unexported modem from path '/org/freedesktop/ModemManager1/Modem/0' The "released by device" messages shown above are due to the kernel reporting that the ttyACM ports are being removed from the system. I'm afraid this is the TOBY-R200 crashing and self-reseting itself. You'll need to bring this issue to u-blox support so that they can tell you how to capture modem traces and how to analyze them. But I also see these messages just after the ones above: [1588357731.601227] Caught signal, shutting down... [1588357731.615674] Stopping connection in object manager server [1588357731.633252] ModemManager is shut down [1588357731.893688] ModemManager (version 1.8.0) starting in system bus... Are you manually restarting ModemManager for some reason once the modem is removed from DBus? This looks like you have some trigger to do that manually? You definitely don't need this. > The customer is using a u-blox TOBY-R200 modem, and I do not see any > u-blox modems listed on the Supported Devices / compatibility page: > https://www.freedesktop.org/wiki/Software/ModemManager/SupportedDevices/ > > That list was done a very long time ago. If a modem is not reported in that list, it doesn't mean we don't support it. :) -- Aleksander https://aleksander.es ___ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
Re: Correct connection sequence to maximize chances of e.g.: getting connected :)
Hey!
> Sorry for deleting the quoted text every time, but without doing so, answers
> may result complicated to read confortably for me.
>
> So, in the end I came to the conclusion that using GObjects is probably the
> best course of cation :)
>
> So I am studying the GLib GObjects page for details, and started writing some
> code to try to understand things better.
>
> Goal: implement a GObject who can act as a container for:
> - MMObjects, MMModem objects, MMModemVoice objects
> - (long) integers for GSignals handlers and other data.
> I managed to get my code to compile, but would like some hints /
> recommendations on how I may proceed.
>
Ok.
> My header:
> #ifndef __main_h__
> #define __main_h__
>
> #include
> #include
>
> G_BEGIN_DECLS
> #define AV_TYPE_MODEM av_modem_get_type()
> G_DECLARE_DERIVABLE_TYPE(AvModem, av_modem, AV, MODEM, GObject)
>
In your case, you're probably not going to create subclasses of the
AvModem object, so you can easier use G_DECLARE_FINAL_TYPE and
completely avoid the need of having a "private" struct. With final
types, you can have all your internal data in the AvModem struct
itself.
> struct _AvModemClass {
> MMObjectClass parent_class;
>
> /* functions ... */
The functions in the class are only needed if you're going to subclass
the class, which you're not going to.
> /* padding with things like
> gpointer padding[12];
> */
And padding is only required if you're making this class "public", in
order to leave some safe space to grow the class in the future. You
can also ignore this.
> };
>
> AvModem *av_modem_new(void);
>
> G_END_DECLS
>
> #endif
>
>
> Source:
> #include
> #include
> #include
>
> typedef struct {
> gchar *filename;
> } AvModemPrivate;
>
As said, if you use a final type you could add the filename variable
in the AvModem struct itself in the header. The ModemManager sources
don't do this because these macros were introduced in newer GLib
versions; we could probably do some porting now that we require newer
releases as well.
> G_DEFINE_TYPE_WITH_PRIVATE (AvModem, av_modem, G_TYPE_OBJECT)
>
> static void av_modem_init(AvModem *self) {
> g_print("__FUNCTION__ invoked\n");
> AvModemPrivate *priv = av_modem_get_instance_private(self);
>
> /* here we would g_object_new and things */
> /* initialize all public and private members to reasonable default
> values.
> * They are all automatically initialized to 0 to begin with. */
> }
>
> static void av_modem_dispose(GObject *gobject) {
> g_print("__FUNCTION__ invoked\n");
> AvModemPrivate *priv =
> av_modem_get_instance_private(AV_MODEM(gobject));
>
> /* In dispose(), you are supposed to free all types referenced from
> this
> * object which might themselves hold a reference to self. Generally,
> * the most simple solution is to unref all members on which you own a
> * reference.
> */
>
> /* time to g_object_clear things */
Yes. It's very important that pointers in dispose() are re-set to NULL
after freeing. E.g. use g_clear_object(), g_clear_pointer() and such.
This is because dispose may be called multiple times.
> G_OBJECT_CLASS (av_modem_parent_class)->dispose (gobject);
> }
>
> static void av_modem_finalize(GObject *gobject) {
> g_print("__FUNCTION__ invoked\n");
> AvModemPrivate *priv =
> av_modem_get_instance_private(AV_MODEM(gobject));
>
> /* e.g.: g_free for filename */
Finalize is only called once, so no need to re-set pointers to NULL
after freeing.
> G_OBJECT_CLASS (av_modem_parent_class)->finalize (gobject);
> }
>
> static void av_modem_class_init(AvModemClass *klass) {
> g_print("__FUNCTION__ invoked\n");
> GObjectClass *object_class = G_OBJECT_CLASS (klass);
> object_class->dispose = av_modem_dispose;
> object_class->finalize = av_modem_finalize;
> }
>
>
>
> gint main(void) {
> return 0;
> }
>
> I see you use various convenience macros in libmm-glib headers, but I am
> trying to do things step by step to understand them.
The convenience macros are probably older GLib macros. The new macros
require less amount of them.
> I may have used GBoxed to wrap my own structs instead, but I am trying to do
> what's better.
You only need GBoxed for your own structs if they're going to be set
as object properties.
> I absoulutely need refcounting in this scenario. :)
>
Yes! (which is good)
--
Aleksander
https://aleksander.es
___
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
