AW: AW: AW: Problems with Sierra MC 8790 with older firmware revision
> -Ursprüngliche Nachricht-
> Von: Dan Williams [mailto:d...@redhat.com]
> Gesendet: Mittwoch, 3. April 2013 20:20
> An: Gerald Richter
> Cc: Aleksander Morgado; Marius Kotsbak; Harald Jung; networkmanager-
> l...@gnome.org
> Betreff: Re: AW: AW: Problems with Sierra MC 8790 with older firmware
> revision
>
> On Wed, 2013-04-03 at 19:37 +0200, Gerald Richter - ECOS wrote:
> > Hi,
> >
> > we have a similar case here (Also firmware version 2_*). We are
> investigating at the moment. As soon as I have more information, we will try
> to create an updated patch.
>
> If there's any chance you can run the ENTERCND thing, then AT!CUSTOM to
> see if your MUXMODE has been modified, that would be great. I'm really
> poking around in the dark here, but it would be very, very nice to have a way
> of detecting this automatically rather than doing something like;
>
> strstr (info, "8790") && strstr (fwver, "2_")
>
Sorry, I don't have direct access to this modem in this case, so in this case
this will not be possible
Gerald
> Dan
>
> > Gerald
> >
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Aleksander Morgado [mailto:aleksan...@lanedo.com]
> > > Gesendet: Mittwoch, 3. April 2013 19:00
> > > An: Dan Williams
> > > Cc: Gerald Richter; Marius Kotsbak; Harald Jung; networkmanager-
> > > l...@gnome.org
> > > Betreff: Re: AW: Problems with Sierra MC 8790 with older firmware
> > > revision
> > >
> > > On 03/04/2013 03:33 PM, Dan Williams wrote:
> > > > On Fri, 2013-03-01 at 15:08 +0100, Gerald Richter - ECOS wrote:
> > > >> The following patch solves the problem for us. It works with all
> > > >> revisions we have available for testing
> > > >
> > > > Pushed to git master and 0.6, thanks!
> > > >
> > > > Dan
> > > >
> > > >> Gerald
> > > >>
> > > >> --- mm-plugin-sierra.c~2012-08-29 17:02:18.0 +0200
> > > >> +++ mm-plugin-sierra.c 2013-03-01 13:22:09.0 +0100
> > > >> @@ -78,6 +78,9 @@
> > > >> if (strstr (response, "C885"))
> > > >> g_object_set_data (G_OBJECT (task),
> > > >> TAG_SIERRA_APP_PPP_OK, GUINT_TO_POINTER (TRUE));
> > > >>
> > > >> +if (strstr (response, "MC8790"))
> > > >> +g_object_set_data (G_OBJECT (task),
> > > >> + TAG_SIERRA_APP_PPP_OK, GUINT_TO_POINTER (TRUE));
> > > >> +
> > > >> /* For debugging: let users figure out if their device
> > > >> supports it or not
> > > */
> > > >> if (getenv ("MM_SIERRA_APP1_PPP_OK")) {
> > > >> mm_dbg ("Sierra: APP1 PPP OK '%s'", response);
> > > >>
> > >
> > >
> > > Ah, the fun... :)
> > >
> > > So I've got a MC8790 here which does *not* like the APP1 port for PPP.
> > > It has the following revision:
> > > 'K2_0_7_35AP C:/WS/FW/K2_0_7_35AP/MSM6290/SRC 2010/03/04
> 17:37:08'
> > >
> > > This is what we get from the probing:
> > >
> > > log_port(): (/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.7)
> > > tty/ttyUSB3 at (primary)
> > > log_port(): (/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.7)
> > > tty/ttyUSB4 data (primary)
> > > log_port(): (/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.7)
> > > tty/ttyUSB1 qcdm
> > >
> > > And it just stalls when we try to launch the ATD call in ttyUSB4:
> > >
> > > [1365007565.579948] [mm-broadband-bearer.c:200]
> > > common_get_at_data_port(): Connection through a plain serial AT port
> > > (ttyUSB4)
> > > [1365007565.579997] [mm-serial-port.c:958] mm_serial_port_open():
> > > (ttyUSB4) device open count is 2 (open) [1365007565.580036]
> > > [mm-serial-port.c:1003] mm_serial_port_close():
> > > (ttyUSB3) device open count is 1 (close) [1365007565.580080]
> > > [mm-at-serial- port.c:408] debug_log(): (ttyUSB4):
> > > --> 'ATD*99***2#'
> > > ...
> > > And that's it, won't reply.
> > >
> > > Running the ATD call in the primary ttyUSB3 port (without the patch
> > > above) kind of works; in that case ttyUSB4 is marked as secondary,
> > > but again
> > > ttyUSB4 doesn't know how to properly work not even as secondary and
> > > either reports error or times out most messages...
> > >
> > > Some additional info for Dan, surely not very useful :)
> > >
> > > AT!NVPORTSET?
> > > ERROR
> > > AT!MXPORTMAP?
> > > ERROR
> > > AT!NVMUXMODE?
> > > ERROR
> > > AT!NVMUXMODE=?
> > > ERROR
> > > AT!MAPUART=?
> > > ERROR
> > > AT!MAPUART?
> > > ERROR
> > > AT!NVPORTMAP?
> > > ERROR
> > >
> > > --
> > > Aleksander
> >
>
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
AW: AW: Problems with Sierra MC 8790 with older firmware revision
Hi,
we have a similar case here (Also firmware version 2_*). We are investigating
at the moment. As soon as I have more information, we will try to create an
updated patch.
Gerald
> -Ursprüngliche Nachricht-
> Von: Aleksander Morgado [mailto:aleksan...@lanedo.com]
> Gesendet: Mittwoch, 3. April 2013 19:00
> An: Dan Williams
> Cc: Gerald Richter; Marius Kotsbak; Harald Jung; networkmanager-
> l...@gnome.org
> Betreff: Re: AW: Problems with Sierra MC 8790 with older firmware revision
>
> On 03/04/2013 03:33 PM, Dan Williams wrote:
> > On Fri, 2013-03-01 at 15:08 +0100, Gerald Richter - ECOS wrote:
> >> The following patch solves the problem for us. It works with all
> >> revisions we have available for testing
> >
> > Pushed to git master and 0.6, thanks!
> >
> > Dan
> >
> >> Gerald
> >>
> >> --- mm-plugin-sierra.c~2012-08-29 17:02:18.0 +0200
> >> +++ mm-plugin-sierra.c 2013-03-01 13:22:09.0 +0100
> >> @@ -78,6 +78,9 @@
> >> if (strstr (response, "C885"))
> >> g_object_set_data (G_OBJECT (task),
> >> TAG_SIERRA_APP_PPP_OK, GUINT_TO_POINTER (TRUE));
> >>
> >> +if (strstr (response, "MC8790"))
> >> +g_object_set_data (G_OBJECT (task),
> >> + TAG_SIERRA_APP_PPP_OK, GUINT_TO_POINTER (TRUE));
> >> +
> >> /* For debugging: let users figure out if their device supports
> >> it or not
> */
> >> if (getenv ("MM_SIERRA_APP1_PPP_OK")) {
> >> mm_dbg ("Sierra: APP1 PPP OK '%s'", response);
> >>
>
>
> Ah, the fun... :)
>
> So I've got a MC8790 here which does *not* like the APP1 port for PPP.
> It has the following revision:
> 'K2_0_7_35AP C:/WS/FW/K2_0_7_35AP/MSM6290/SRC 2010/03/04 17:37:08'
>
> This is what we get from the probing:
>
> log_port(): (/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.7)
> tty/ttyUSB3 at (primary)
> log_port(): (/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.7)
> tty/ttyUSB4 data (primary)
> log_port(): (/sys/devices/pci:00/:00:1d.0/usb2/2-1/2-1.7)
> tty/ttyUSB1 qcdm
>
> And it just stalls when we try to launch the ATD call in ttyUSB4:
>
> [1365007565.579948] [mm-broadband-bearer.c:200]
> common_get_at_data_port(): Connection through a plain serial AT port
> (ttyUSB4)
> [1365007565.579997] [mm-serial-port.c:958] mm_serial_port_open():
> (ttyUSB4) device open count is 2 (open)
> [1365007565.580036] [mm-serial-port.c:1003] mm_serial_port_close():
> (ttyUSB3) device open count is 1 (close) [1365007565.580080] [mm-at-serial-
> port.c:408] debug_log(): (ttyUSB4):
> --> 'ATD*99***2#'
> ...
> And that's it, won't reply.
>
> Running the ATD call in the primary ttyUSB3 port (without the patch
> above) kind of works; in that case ttyUSB4 is marked as secondary, but again
> ttyUSB4 doesn't know how to properly work not even as secondary and
> either reports error or times out most messages...
>
> Some additional info for Dan, surely not very useful :)
>
> AT!NVPORTSET?
> ERROR
> AT!MXPORTMAP?
> ERROR
> AT!NVMUXMODE?
> ERROR
> AT!NVMUXMODE=?
> ERROR
> AT!MAPUART=?
> ERROR
> AT!MAPUART?
> ERROR
> AT!NVPORTMAP?
> ERROR
>
> --
> Aleksander
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
AW: Problems with Sierra MC 8790 with older firmware revision
The following patch solves the problem for us. It works with all revisions we
have available for testing
Gerald
--- mm-plugin-sierra.c~ 2012-08-29 17:02:18.0 +0200
+++ mm-plugin-sierra.c 2013-03-01 13:22:09.0 +0100
@@ -78,6 +78,9 @@
if (strstr (response, "C885"))
g_object_set_data (G_OBJECT (task), TAG_SIERRA_APP_PPP_OK,
GUINT_TO_POINTER (TRUE));
+if (strstr (response, "MC8790"))
+g_object_set_data (G_OBJECT (task), TAG_SIERRA_APP_PPP_OK,
GUINT_TO_POINTER (TRUE));
+
/* For debugging: let users figure out if their device supports it or
not */
if (getenv ("MM_SIERRA_APP1_PPP_OK")) {
mm_dbg ("Sierra: APP1 PPP OK '%s'", response);
> -Ursprüngliche Nachricht-
> Von: networkmanager-list [mailto:networkmanager-list-
> boun...@gnome.org] Im Auftrag von Gerald Richter - ECOS
> Gesendet: Montag, 25. Februar 2013 13:10
> An: Dan Williams; Harald Jung
> Cc: Marius Kotsbak; networkmanager-list@gnome.org
> Betreff: AW: Problems with Sierra MC 8790 with older firmware revision
>
> Hi Dan,
>
> we have now tested with two MC8790 cards. One has work ever since with
> modem-manger, the other didn't (as Harald reported last week).
>
> From an usb point of view there is no difference (same product/vendor id
> etc.).
>
> The only difference is, that the card that isn't working reports Revision
> K1_0_3_0AP, while the one that is working reports K1_1_1_9AP.
>
> Running with
>
> MM_SIERRA_APP1_PPP_OK=1 /modem-manager --debug
>
> Both cards are working correctly and both use ttyUSB4 for pppd (while the
> one that worked before uses ttyUSB3 without that setting).
>
> So as far as we can test, it's safe to always use ttyUSB4 on MC8790.
>
> Could you please let us know how to tell modem-manager to always use this
> setting for MC8790
>
> Thanks & Regards
>
> Gerald
>
>
>
> > -Ursprüngliche Nachricht-
> > Von: Dan Williams [mailto:d...@redhat.com]
> > Gesendet: Freitag, 22. Februar 2013 04:57
> > An: Harald Jung
> > Cc: Marius Kotsbak; networkmanager-list@gnome.org
> > Betreff: Re: Problems with Sierra MC 8790 after kernel upgrade to
> > 3.7.x
> >
> > On Thu, 2013-02-21 at 19:36 +0100, Harald Jung wrote:
> > > Hi,
> > >
> > > after a coldstart your hint worked.
> > > Is there a possibility to pass manage this by udev?
> > > modem-manager uses an enviroment variable and is triggered itself by
> > dbus.
> > > So it seems to be difficult in the first place.
> >
> > The environment variable is only there for testing. Once we have a
> > positive test, we can tell ModemManager that the 8790 is OK to do this for
> everyone.
> >
> > Dan
> >
> > >
> > > Harald
> > >
> > > Am 18.02.2013 12:24, schrieb Harald Jung:
> > > > the output looks a bit different but i wasn't able to establish a
> > > > connection :(
> > > >
> > > > modem-manager[6820]: [mm-manager.c:859]
> device_added():
> > > > (net/ppp0): could not get port's parent device
> > > > modem-manager[6820]: [mm-at-serial-port.c:334]
> debug_log():
> > > > (ttyUSB3): <-- '+CIEV: 1,3'
> > > > modem-manager[6820]: [mm-at-serial-port.c:334]
> debug_log():
> > > > (ttyUSB3): <-- '+CIEV: 7,0'
> > > > modem-manager[6820]: [mm-serial-port.c:697]
> > data_available():
> > > > (ttyUSB4) unexpected port hangup!
> > > >
> > > > Harald
> > > >
> > > > Am 15.02.2013 22:07, schrieb Dan Williams:
> > > >> On Fri, 2013-02-15 at 09:26 +0100, Harald Jung wrote:
> > > >>> I've cleaned up to log, because i have no access to the notebook
> > > >>> at the moment.
> > > >>> ipv6 should be deactived and is not activated in the config.
> > > >> Once you have access to the notebook again, can you stop MM the
> > > >> normal
> > > >> way:
> > > >>
> > > >> mv /usr/sbin/modem-manager /
> > > >> killall -TERM modem-manager
> > > >>
> > > >> and then run MM like this?
> > > >>
> > > >> MM_SIERRA_APP1_PPP_OK=1 /modem-manager --debug
> > > >>
> > > >> and attempt a connection? Older Sierra devices allow PPP on the
> > > >> APP1 port (ttyUSB4 on your device) but unfortunately we have to
> > > >> whitelist that. It's actually impossible to test which tty
> > > >> accepts PPP on most Sierra devices, so we really have no idea.
> > > >> For examply, my C885 and
> > > >> USB306 allow it, but none of my (four) 8775s or my 8781 allows it.
> > > >>
> > > >> Dan
> > > >>
> > > > ___
> > > > networkmanager-list mailing list
> > > > networkmanager-list@gnome.org
> > > > https://mail.gnome.org/mailman/listinfo/networkmanager-list
> > >
> >
>
>
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
AW: Problems with Sierra MC 8790V and wrong primary port
>... > On a side note, a user just reported an issue with a MC8790V (see the trailing > 'V' there), log attached. In this case, the issue is not about using the APP1 > port for PPP; the issue is that there is no non-APP port shown, so we don't > specify any port being 'primary', and we end up choosing an incorrect one. > > So, with: > > ttyUSB3 --> APP1 > ttyUSB4 --> APP2 > ttyUSB5 --> APP3 > > We end up getting: > > tty/ttyUSB4 primary > tty/ttyUSB3 secondary > tty/ttyUSB4 data > > And ttyUSB4 doesn't like being the primary port here. Possibly ttyUSB3 > should be the one treated as primary? > Before we started to use network-manager we used a self made script (which only supports the ppp interface) and if I remember correctly, we always used the lowest ttyUSB Port as primary in case there was no other setup known for a card. This had worked for us very well. Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
AW: Problems with Sierra MC 8790 with older firmware revision
Hi Dan, we have now tested with two MC8790 cards. One has work ever since with modem-manger, the other didn't (as Harald reported last week). From an usb point of view there is no difference (same product/vendor id etc.). The only difference is, that the card that isn't working reports Revision K1_0_3_0AP, while the one that is working reports K1_1_1_9AP. Running with MM_SIERRA_APP1_PPP_OK=1 /modem-manager --debug Both cards are working correctly and both use ttyUSB4 for pppd (while the one that worked before uses ttyUSB3 without that setting). So as far as we can test, it's safe to always use ttyUSB4 on MC8790. Could you please let us know how to tell modem-manager to always use this setting for MC8790 Thanks & Regards Gerald > -Ursprüngliche Nachricht- > Von: Dan Williams [mailto:d...@redhat.com] > Gesendet: Freitag, 22. Februar 2013 04:57 > An: Harald Jung > Cc: Marius Kotsbak; networkmanager-list@gnome.org > Betreff: Re: Problems with Sierra MC 8790 after kernel upgrade to 3.7.x > > On Thu, 2013-02-21 at 19:36 +0100, Harald Jung wrote: > > Hi, > > > > after a coldstart your hint worked. > > Is there a possibility to pass manage this by udev? > > modem-manager uses an enviroment variable and is triggered itself by > dbus. > > So it seems to be difficult in the first place. > > The environment variable is only there for testing. Once we have a positive > test, we can tell ModemManager that the 8790 is OK to do this for everyone. > > Dan > > > > > Harald > > > > Am 18.02.2013 12:24, schrieb Harald Jung: > > > the output looks a bit different but i wasn't able to establish a > > > connection :( > > > > > > modem-manager[6820]: [mm-manager.c:859] device_added(): > > > (net/ppp0): could not get port's parent device > > > modem-manager[6820]: [mm-at-serial-port.c:334] debug_log(): > > > (ttyUSB3): <-- '+CIEV: 1,3' > > > modem-manager[6820]: [mm-at-serial-port.c:334] debug_log(): > > > (ttyUSB3): <-- '+CIEV: 7,0' > > > modem-manager[6820]: [mm-serial-port.c:697] > data_available(): > > > (ttyUSB4) unexpected port hangup! > > > > > > Harald > > > > > > Am 15.02.2013 22:07, schrieb Dan Williams: > > >> On Fri, 2013-02-15 at 09:26 +0100, Harald Jung wrote: > > >>> I've cleaned up to log, because i have no access to the notebook > > >>> at the moment. > > >>> ipv6 should be deactived and is not activated in the config. > > >> Once you have access to the notebook again, can you stop MM the > > >> normal > > >> way: > > >> > > >> mv /usr/sbin/modem-manager / > > >> killall -TERM modem-manager > > >> > > >> and then run MM like this? > > >> > > >> MM_SIERRA_APP1_PPP_OK=1 /modem-manager --debug > > >> > > >> and attempt a connection? Older Sierra devices allow PPP on the > > >> APP1 port (ttyUSB4 on your device) but unfortunately we have to > > >> whitelist that. It's actually impossible to test which tty accepts > > >> PPP on most Sierra devices, so we really have no idea. For > > >> examply, my C885 and > > >> USB306 allow it, but none of my (four) 8775s or my 8781 allows it. > > >> > > >> Dan > > >> > > > ___ > > > networkmanager-list mailing list > > > networkmanager-list@gnome.org > > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Novatel based Mobile Broadband does not respond anymore
Hi Dan,
it has taken me very long time until I got back to this issue. I tested the
patch below (which changes charset from UCS2 to IRA) you send me with
modem-manager 6.0.0.0 and it works :-)
Is there any chance to get this into standard modem-manager, maybe as some kind
of config option or maybe some kind of blacklist for charsets? As far as I
understand this mainly effects the SMS charset, so it cannot be globally
changed.
Thanks & Regards
Gerald
> -Original Message-
> From: networkmanager-list-boun...@gnome.org [mailto:networkmanager-
> list-boun...@gnome.org] On Behalf Of Gerald Richter - ECOS
> Sent: Friday, February 03, 2012 11:42 AM
> To: Dan Williams
> Cc: networkmanager-list@gnome.org
> Subject: RE: Novatel based Mobile Broadband does not respond anymore
>
> Hi Dan,
>
> thanks for your feedback.
>
> I will setup a build environment for modem manger and give it a try (it will
> take some time until I get the time to do so).
>
> In case this solves the problem, I would suggest to add a udev variable to
> configure the charset order depending on the modem type ( I don't think it's
> necessary to create an extra plugin for this special case).
>
> Would this make sense to you?
>
> Thanks & Regards
>
> Gerald
>
>
> > -Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Thursday, February 02, 2012 8:46 PM
> > To: Gerald Richter - ECOS
> > Cc: networkmanager-list@gnome.org
> > Subject: Re: Novatel based Mobile Broadband does not respond anymore
> >
> > On Thu, 2012-01-26 at 16:13 +0100, rich...@ecos.de wrote:
> > > Hi,
> > >
> > > we've problems with a Novatel based Mobile Broadband card.
> > >
> > > The serial device doesn't respond to AT Commands after it has been
> > > initialized and a successfully registration to an apn.
> > > The modem-manager falls back in an endless loop after that behavior.
> > >
> > > Bus 004 Device 002: ID 413c:8137 Dell Computer Corp. Wireless 5520
> > > Voda L Mobile Broadband (3G HSDPA) Minicard Status Port
> > >
> > > The logfile is attached.
> > >
> > > Before we used network manager, we had a very simply umts solution,
> > which only uses a few AT commands. This did work for quite a long time.
> > >
> > > It seems that the firmware crashes on some of the AT command
> > > (coldstart
> > is necessary, to get the card working again).
> > >
> > > Any ideas?
> >
> > I've seen the firmware of my 5510 (which is basically the EU870D
> > except in ExpressCard form) crash when doing SMS-related stuff. If
> > you're able to rebuild ModemManager, try this patch and see if that helps
> anything:
> >
> > diff --git a/src/mm-generic-gsm.c b/src/mm-generic-gsm.c index
> > 3a1c62e..be63d97 100644
> > --- a/src/mm-generic-gsm.c
> > +++ b/src/mm-generic-gsm.c
> > @@ -1260,10 +1260,10 @@ enable_failed (MMModem *modem, GError
> *error,
> > MMCallbackInfo *info) }
> >
> > static guint32 best_charsets[] = {
> > +MM_MODEM_CHARSET_IRA,
> > MM_MODEM_CHARSET_UTF8,
> > MM_MODEM_CHARSET_UCS2,
> > MM_MODEM_CHARSET_8859_1,
> > -MM_MODEM_CHARSET_IRA,
> > MM_MODEM_CHARSET_GSM,
> > MM_MODEM_CHARSET_UNKNOWN
> > };
> >
> > Some modems don't deal well with UCS2 and my 5510 is one of them. The
> > charset doesn't just affect SMS so it might be causing the crashes.
> >
> > Dan
>
>
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: PATCH: Auto-Enable WWAN after PIN entry
Hi, I would expect that it works, when either there is no PIN on the SIM card or when the PIN is in the system configuration. If nm-applet is running it should also ask for the PIN, but nm-applet has unfortunately two PIN dialogs, the one that will be used here is not able to ask for a PUK in case the PIN is locked, neither will it save the PIN with the SIM card identifier, but it will save the PIN in system connection information. So it is a good workaround for many cases, but from my point of view also not the real solution. Gerald From: Marius Kotsbak [mailto:marius.kots...@gmail.com] Sent: Wednesday, August 29, 2012 9:28 AM To: Gerald Richter - ECOS Cc: networkmanager-list@gnome.org Subject: RE: PATCH: Auto-Enable WWAN after PIN entry On Jul 31, 2012 10:03 AM, mailto:rich...@ecos.de> > wrote: > > Hi, > > > > > Looking at the patched code, the most likely cause I think is that I have > > disabled PIN check at the SIM card and then the patch code that hooks into > > the PIN dialog is never executed. > > [[GR]] That's right. As far as I see nm-applet will not get noticed when > there is no PIN required, so I don't see a chance to handle this case here. > This could of cause be solved, if we moved the code to network and modem > manger, as you and Dan already suggested. There is a script here that solves both the enabling and reconnection of the modem: http://www.thefanclub.co.za/how-to/how-auto-connect-ubuntu-1204-gsm-mobile-broadband-connection-on-boot-startup-service#version2 <http://www.thefanclub.co.za/how-to/how-auto-connect-ubuntu-1204-gsm-mobile-broadband-connection-on-boot-startup-service#version2> And since it only uses nmcli it seems like this is possible to solve without any modification of the applet or the api? Or does it not work if the modem requires a PIN? -- Marius ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: PATCH: Auto-Enable WWAN after PIN entry
Hi, > > Looking at the patched code, the most likely cause I think is that I have > disabled PIN check at the SIM card and then the patch code that hooks into > the PIN dialog is never executed. [[GR]] That's right. As far as I see nm-applet will not get noticed when there is no PIN required, so I don't see a chance to handle this case here. This could of cause be solved, if we moved the code to network and modem manger, as you and Dan already suggested. > I guess the same would happen when the > PIN is found in the keystore, so the patch code should be moved out of that > part. > [[GR]] No, the patch handles this case. If the PIN is coming from the keystore WWAN will also be enabled. Regards Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: PATCH: Auto-Enable WWAN after PIN entry
Hi, > > Great, that is mainly what I had in mind WRT autoconnect. But as Marius > says, it only solves it for nm-applet, and not for other DEs. However, I'm > not > sure we can solve it in general unless we modify the NM secret agent API, > which we certainly could do. > > > If we did move this functionality more into NM, then we'd add a second class > of GetSecrets() type functions for a device, where the existing ones are for a > connection. ModemManager gives us a SIM ID and a Device ID, and we'd > pass these to this function, which would then ask whatever registered agent > for the secrets. The agent could look them up and return then, and > depending on that response, NM could enable the device or not, in > conjunction with the current rfkill/airplane mode status and whether any > connections matching that device had autoconnect=true. > [[GR]] That makes sense, this also could solve the point that we have at the moment two different Pin dialogs (one on nm-applet startup and another when a connection starts that need a PIN and requests it via the agent interface). However since this is only one a lot of other tasks I am working on and fighting thru several layers of state machines and interprocess communication is not the easiest thing, if you only part time working on this stuff, I will for the moment stick with my current patch, since it solves at least most of my problems. I will keep this in mind for my next patch Regards Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: PATCH: Auto-Enable WWAN after PIN entry
Hi, I tried testing this patch with Ubuntu Precise packages, but nm-applet crashes: [[GR]] Sorry, I am not an Ubuntu User, so I don't know what Precise packages are Program received signal SIGSEGV, Segmentation fault. gsm_add_menu_item (device=0x811d380, n_devices=1, active=0x0, menu=0x81b72e8, applet=0x80e6038) at applet-device-gsm.c:463 463text = mobile_helper_get_connection_label (NULL, [[GR]] As far as I can see, this seems not to be related to my patch. At least I do not change anything during menu update. Maybe you did not correctly recompile nm-applet, because the applet.h changes and if not every file gets recompiled, that might be the reason for the crash. So I suggest to make a make clean first and retry. If it still persists, that I would need more information about when it occurs. Did you build it on the current git master head? [[GR]] The patch is against 0.9.4, because that ist he latest stable version and the one which we are using. But I don't see any changes in HEAD, which might be related to that issue Anyway, I find it strange to fix this bug in the nm-applet GUI, when I see changes related to this in network manager previously: [[GR]] "we need to explicitly make nm_device_interface_get_enabled() == true a prerequisite for autoconnecting.". That is exactly what the patch does, it enables the WWAN if there are any autoconnect conntions _after_ the PIN has entered. The point is that the patch waits for the Pin entry and only on successful pin entry, enable the WWAN. Which makes sense from my point of view and is a necessary addition to the commit you mentioned. Maybe this could also be done in network manger, I am not sure if this would be a better place. I leave this decision up to the people that know the code better than me. Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
PATCH: applet_get_device_for_connection fails sometimes
Hi, if a gsm connection has not PIN and I have canceled the initial PIN dialog, the network manger tries to request a PIN via an agent. For me this fails most the time, because the connection that I have started manualy is not active (yet) and therefor applet_get_device_for_connection does not find the device for the connection. The attached patch just uses the first available gsm device in this case, which seems to be a good solution for me. Maybe it would be better to move the code into applet-device-gsm, but this one least works. Gerald find_device_for_connection.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
PATCH: Auto-Enable WWAN after PIN entry
Hi, there seems to be a lot of questions about automatically starting GSM connections, but not so much answers.. Here is a patch that solves it at least for me. It does the following: - Wait for starting of the devices until all connections are read - Check if there is any gsm connection that should be automatically started - If yes, ask for the PIN (or use the saved one) - After successful Pin entry, enable WWAN (which will in turn start the auto connections) - If there is no auto start gsm connection, don't ask for the PIN and don't enable WWAN. This makes sure WWAN is only enable (and GSM cards powered up), if necessary and it will make sure the user will not be bother with a PIN dialog, unless it's necessary to start a connection (it's very annoying at least for me, if I get this PIN dialog, because I have a build in gsm modem when I am working via LAN or WLAN). If later on a connection is started manually and the PIN is not known, then the PIN is requested from the user. BTW. Is there a reason why there exists two sorts of PIN dialogs? I think it would be better to use just one dialog and also to always tie the PIN to SIM ID like it is done in the startup dialog? Hopefully this patch is helpful for somebody Regards Gerald gsm_enable_unlock.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: modem-manager hangs while starting up
Hi, it was not crashing, but simply doing nothing anymore (not detect any modem at all). It waits forever inside of poll and the backtrace Harald sent, was the place where the poll occurs. Hope this clarifies things a bit Gerald > -Original Message- > From: Dan Williams [mailto:d...@redhat.com] > Sent: Monday, July 16, 2012 8:23 PM > To: Harald Jung > Cc: networkmanager-list@gnome.org > Subject: Re: modem-manager hangs while starting up > > On Thu, 2012-07-12 at 09:07 +0200, Harald Jung wrote: > > Hi, > > > > finally the reason was the missing udev rule 80-mm-candidate.rules > > Odd, ideally MM shouldn't be crashing there. So that file was simply missing? > If that's the case, I'll test that and see if I can get the crash. > > Dan > > > > > Harald > > > > Am Dienstag, den 03.07.2012, 20:35 + schrieb Harald Jung: > > > okay .. i got the debugging symbols, but: > > > > > > (gdb) bt > > > #0 0xa3455c81 in poll () from /lib/libc.so.6 > > > #1 0xa35361b0 in g_poll () from /usr/lib/libglib-2.0.so.0 > > > #2 0x0011 in ?? () > > > #3 0x in ?? () > > > #4 0xa356c775 in g_mutex_unlock () from /usr/lib/libglib-2.0.so.0 > > > #5 0xb044ca04 in ?? () > > > Backtrace stopped: previous frame inner to this frame (corrupt > > > stack?) > > > > > > :( > > > > > > Am Dienstag, den 03.07.2012, 20:21 + schrieb Dan Williams: > > > > On Tue, 2012-07-03 at 21:44 +0200, Harald Jung wrote: > > > > > strange thing.. i've used the unstripped version and i get: > > > > > > > > > > GNU gdb (Gentoo 7.3.1 p2) 7.3.1 > > > > > ...blah. > > > > > Reading symbols from /tmp/modem-manager...(no debugging > symbols > > > > > found)...done. > > > > > > > > > > is there a special configure or Makefile hook? > > > > > > > > Not specifically, but you could use CFLAGS including "-g -O0" to > > > > build the debugging into and turn off optimization. That's > > > > usually enough to get at least function names in the stack traces. > > > > > > > > Dan > > > > > > > > > > > > > > Harald > > > > > > > > > > Am Dienstag, den 03.07.2012, 19:30 + schrieb Dan Williams: > > > > > > Any chance you could get some debug symbols there? > > > > > > > > > > > > Dan > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___ > > > > networkmanager-list mailing list > > > > networkmanager-list@gnome.org > > > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > > > > > > > ___ > > > networkmanager-list mailing list > > > networkmanager-list@gnome.org > > > https://mail.gnome.org/mailman/listinfo/networkmanager-list > > > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
Disable roaming for new WWAN connection
Hi, when I add a new mobile broadband connection, roaming is enabled by default. Could this default be changed somehow (most people like to disable roaming by default, because it's very expensive, at least in Europe). If there is no simple way to change this, could somebody tell me which is the right place to patch network manager to change this default? Thanks & Regards Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
WWAN is disabled at startup
Hi, when I startup networkmanager and nm-applet, WWAN is disabled. It also does not get enabled, if I enter a valid pin. I can start WWAN connections without problems and it works as it should, but I doesn't understand why WWAN is initially disabled? Is this the intended behavior or is there something wrong with our setup? If this is the intended behavior, could it be changed somehow? Thanks & Regards Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Novatel based Mobile Broadband does not respond anymore
Hi Dan,
thanks for your feedback.
I will setup a build environment for modem manger and give it a try (it will
take some time until I get the time to do so).
In case this solves the problem, I would suggest to add a udev variable to
configure the charset order depending on the modem type ( I don't think it's
necessary to create an extra plugin for this special case).
Would this make sense to you?
Thanks & Regards
Gerald
> -Original Message-
> From: Dan Williams [mailto:d...@redhat.com]
> Sent: Thursday, February 02, 2012 8:46 PM
> To: Gerald Richter - ECOS
> Cc: networkmanager-list@gnome.org
> Subject: Re: Novatel based Mobile Broadband does not respond anymore
>
> On Thu, 2012-01-26 at 16:13 +0100, rich...@ecos.de wrote:
> > Hi,
> >
> > we've problems with a Novatel based Mobile Broadband card.
> >
> > The serial device doesn't respond to AT Commands after it has been
> > initialized and a successfully registration to an apn.
> > The modem-manager falls back in an endless loop after that behavior.
> >
> > Bus 004 Device 002: ID 413c:8137 Dell Computer Corp. Wireless 5520
> > Voda L Mobile Broadband (3G HSDPA) Minicard Status Port
> >
> > The logfile is attached.
> >
> > Before we used network manager, we had a very simply umts solution,
> which only uses a few AT commands. This did work for quite a long time.
> >
> > It seems that the firmware crashes on some of the AT command (coldstart
> is necessary, to get the card working again).
> >
> > Any ideas?
>
> I've seen the firmware of my 5510 (which is basically the EU870D except in
> ExpressCard form) crash when doing SMS-related stuff. If you're able to
> rebuild ModemManager, try this patch and see if that helps anything:
>
> diff --git a/src/mm-generic-gsm.c b/src/mm-generic-gsm.c index
> 3a1c62e..be63d97 100644
> --- a/src/mm-generic-gsm.c
> +++ b/src/mm-generic-gsm.c
> @@ -1260,10 +1260,10 @@ enable_failed (MMModem *modem, GError
> *error, MMCallbackInfo *info) }
>
> static guint32 best_charsets[] = {
> +MM_MODEM_CHARSET_IRA,
> MM_MODEM_CHARSET_UTF8,
> MM_MODEM_CHARSET_UCS2,
> MM_MODEM_CHARSET_8859_1,
> -MM_MODEM_CHARSET_IRA,
> MM_MODEM_CHARSET_GSM,
> MM_MODEM_CHARSET_UNKNOWN
> };
>
> Some modems don't deal well with UCS2 and my 5510 is one of them. The
> charset doesn't just affect SMS so it might be causing the crashes.
>
> Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Persistent 3G connection fails, not sure why
Hi, I also have some problems with persistent network connections and adapted the patch below (you should find the mail in August or September list archive), but it's solves only a part of my problems, also it makes things much better, I have still problems from time to time, where I need to disable and reenable the mobile broadband to get the modem reseted and didn't found a solution so far... Gerald > -Original Message- > From: alexan...@karlstad.be [mailto:networkmanager-list- > boun...@gnome.org] On Behalf Of Alexander Karlstad > Sent: Thursday, October 27, 2011 4:46 PM > To: networkmanager-list@gnome.org > Subject: Re: Persistent 3G connection fails, not sure why > > Den 27. okt. 2011 14:17, skrev David Pfeffer: > > Actually, that patch seems to be exactly what's needed. Can this be > > patched into the main codebase? > > > > https://launchpadlibrarian.net/75684426/nm-reconnect.patch > > > > I haven't tested it specifically but it solves the problem that seems > > to be identical to mine. > > I don't see where you see that they say it didn't work well for them. > > It seems like everyone was happy with it. > > Yup. The people commenting on it seemed happy, but I emailed the guy > directly and he didn't seem to enthusiastic about it now, but again, he was > using a USB modem and not a built-in Mini PCI-e device like mine. > > I personally tried applying the patch to the latest network-manager in > Ubuntu a couple a days ago, but it never compiled. I'm guessing the code has > changed a bit since the patch was written. (I think it was the NMDeviceType > thing that didn't work.) > > If this actually is what it takes, then I hope someone is willing to have a > look > at it and eventually push it upstream :-) > > -- > Alexander Karlstad > ___ > networkmanager-list mailing list > networkmanager-list@gnome.org > http://mail.gnome.org/mailman/listinfo/networkmanager-list ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: PATCH / no gsm unlock
Hi, you are totally right that using the SIM identifier is the right solution. I am aware of this fact, but I have the same problem as you: missing time. Even the problem is a little bit more complicated for us, because, at least sometimes, the PIN is brought into the configuration from a different configuration system via DBUS. This system does not know the SIM ID and there is nobody to type in the initial PIN. Maybe the PIN could be automatically attached to the SIM Identifier after the first successful login (which might be because of a PIN saved in the connection). My patch solved my problem for now, without costing too much time, to get a proper solution, but I keep this in mind if there is some free time. Gerald > -Original Message- > From: Dan Williams [mailto:d...@redhat.com] > Sent: Thursday, September 15, 2011 5:30 PM > To: Gerald Richter - ECOS > Cc: networkmanager-list@gnome.org > Subject: Re: PATCH / no gsm unlock > > On Thu, 2011-09-15 at 17:24 +0200, rich...@ecos.de wrote: > > Hi, > > > > sometime ago I ask for some way to disable the initial PIN dialog for > situations where an automatic UMTS connection should be initiated and the > PIN is already saved in the connection. > > > > Attached is a patch that adds this functionality to nm-applet. It only > > brings > up the initial dialog if a PUK is required, but not if only the PIN is > required. > > The best solution here is to use the ModemManager "SIM Identifier" (or if > not available the "Device Identifier") properties to recognize the SIM. The > first time, the applet would pop up the dialog and ask you for the PIN. It > would save this PIN into the keyring along with the SIM identifier and device > identifier. Next time you plug the modem in, it would look in the keyring for > the SIM ID and send that PIN to modem-manager, without showing the > dialog. That's the preferred way of doing it I think. Shouldn't be too hard > to > do, but I've had no time to do it. > > THe problem with the PIN in the connection is that connections can apply to > more than one device, and the connection is independent of the SIM. > The PIN is specific to the SIM. So if you swap SIM cards and the new SIM has > a different PIN, then NM would try to send the wrong PIN. Hence the > modifications I did for MM 0.5 that provide a SIM ID and Device ID. > > Dan > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Modems access fails after pppd hang up
Hi, after doing a lot of testing with bad UMTS connections, I was able to solve most of my problems with my patches from http://mail.gnome.org/archives/networkmanager-list/2011-September/msg00040.html . There is one problem still left, which I am not able to solve on my own. If pppd hangs up for whatever reason (for example because of on lcp echo failure), often the modem remains in an unusable state, because the modem is still in data mode and modem manger tries to send AT commands and does not get an answer. In this state it often helps to disable UMTS at all (using the right mouse menu) and enable it again. Then the modem gets reseted and everything works again. I have tried to automatically disable/enable the modem in case there is no response to the AT commands and also tried to send flash or AT hangup command on the secondary line (as far as available), but I was not able to get the different state machines of network manager and modem manger to do the right thing. I have found this behavior with at least 5 different UMTS modems, so I think it's a general issue. At least from my point of view it would be very imported to automatically recover from errors (as far as possible). Since I didn't found a solution I would need an idea or a pointer what can be done to make modem manger better handle such situations. Thanks Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: GlobeTrotter HSDPA Modem -> Failed to find a usable modem character set
Hi, it was not easy get and upgrade the firmware on the old stick (it requires not only windows but it requires win xp and you need the correctly branded firmware), but after the update I didn't saw the error again Thanks Gerald > -Original Message- > From: Dan Williams [mailto:d...@redhat.com] > Sent: Thursday, September 15, 2011 5:26 PM > To: Gerald Richter - ECOS > Cc: Aleksander Morgado; networkmanager-list@gnome.org > Subject: RE: GlobeTrotter HSDPA Modem -> Failed to find a usable modem > character set > > On Thu, 2011-09-15 at 17:15 +0200, rich...@ecos.de wrote: > > Here are the modem type: > > It looks like you've got an iCON 225, right? I've got one too that works > pretty > well, but I've got updated firmware that fixed issues like this. I'm pretty > sure > it shipped with a 2007-era firmware originally and it was somewhat buggy. > > Manufacturer: Option N.V. > Model: GlobeTrotter HSDPA Modem > Revision: 2.5.24Hd (Date: Apr 17 2009, Time: 08:59:36) > > Unfortunately a firmware upgrade requires Windows. > > http://www.option.com/en/support/software-download/mobile-devices- > solutions/icon225/ > > You're looking for the "iCON® 225: SuperFire FW only" update link there. > If you have a locked or branded 225 though, you might not be able to use this > specific update, and you might need to find an updater from the operator > you purchased the device from. > > Dan > > > : (ttyHS0): --> 'AT+GMI' > > : (ttyHS0): <-- 'Option N.V.OK' > > : (ttyHS0): --> 'AT+GMM' > > : (ttyHS0): <-- 'GlobeTrotter HSDPA > ModemOK' > > : (ttyHS0): --> 'AT+GMR' > > : (ttyHS0): <-- '2.4.6Hd (Date: Oct 04 2007, Time: > 14:11:38)OK' > > : (ttyHS0): --> 'AT+CGMI' > > : (ttyHS0): <-- 'Option N.V.OK' > > : (ttyHS0): --> 'AT+CGMM' > > : (ttyHS0): <-- 'GlobeTrotter HSDPA > ModemOK' > > : (ttyHS0): --> 'AT+CGMR' > > : (ttyHS0): <-- '2.4.6Hd (Date: Oct 04 2007, Time: > 14:11:38)OK' > > : (ttyHS0): --> 'ATI' > > : (ttyHS0): <-- 'Manufacturer: Option N.V.Model: > GlobeTrotter HSDPA ModemRevision: 2.4.6Hd (Date: Oct 04 2007, > Time: 14:11:38)OK' > > : (ttyHS0): --> 'ATI1' > > : (ttyHS0): <-- 'Manufacturer: Option N.V.Model: > GlobeTrotter HSDPA ModemRevision: 2.4.6Hd (Date: Oct 04 2007, > Time: 14:11:38)OK' > > > > > > Bus 002 Device 013: ID 0af0:6971 Option Globetrotter HSDPA Modem > > Device Descriptor: > > bLength18 > > bDescriptorType 1 > > bcdUSB 1.10 > > bDeviceClass 255 Vendor Specific Class > > bDeviceSubClass 255 Vendor Specific Subclass > > bDeviceProtocol 255 Vendor Specific Protocol > > bMaxPacketSize064 > > idVendor 0x0af0 Option > > idProduct 0x6971 Globetrotter HSDPA Modem > > bcdDevice0.00 > > iManufacturer 1 Option N.V. > > iProduct2 Globetrotter HSDPA Modem > > iSerial 4 Serial Number > > bNumConfigurations 1 > > > > > > Gerald > > > > > > > -Original Message- > > > From: Dan Williams [mailto:d...@redhat.com] > > > Sent: Thursday, September 15, 2011 5:06 PM > > > To: Aleksander Morgado > > > Cc: Gerald Richter - ECOS; networkmanager-list@gnome.org > > > Subject: Re: GlobeTrotter HSDPA Modem -> Failed to find a usable > > > modem character set > > > > > > On Thu, 2011-09-15 at 13:22 +0200, Aleksander Morgado wrote: > > > > > (ttyHS0): --> 'AT_OPSYS?' > > > > > Sep 15 10:43:34 ThinClient modem-manager[2081]: > > > > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- > > > > > 'ERROR' > > > > > Sep 15 10:43:34 ThinClient modem-manager[2081]: > > > > > [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got > > > > > failure code 100: Unknown error Sep 15 10:43:34 ThinClient > > > > > modem-manager[2081]: [mm-at-serial-port.c:298] > debug_log(): > > > > > (ttyHS0): --> 'AT+CSCS=?' > > > > > Sep 15 10:43:34 ThinClient modem-manager[2081]: > > > > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- > '_OPSYS: > > > > > 3,2OK' > > > > > Sep 15 10:43:34 ThinClient modem-mana
PATCH / no gsm unlock
Hi, sometime ago I ask for some way to disable the initial PIN dialog for situations where an automatic UMTS connection should be initiated and the PIN is already saved in the connection. Attached is a patch that adds this functionality to nm-applet. It only brings up the initial dialog if a PUK is required, but not if only the PIN is required. It is turned on and off via a command line option. That was the easiest way for me to go. Maybe it would better to have some other way to configure it (like a config file) Gerald no_gsm_unlock.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: No autostart for UMTS connections in 0.9
Hi, > > > > It seems that all the UMTS modems I have tested, are disabled after NM > startup, so they will not automatically start. > > > > Is it intended that a modem is disabled after plug in/startup also the > modem is fully working? Or is this some mistake on my side? > > Would you mind if we fixed this via a config file option, like 'mb- > autoenable=true'? > That's fine for me. Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: GlobeTrotter HSDPA Modem -> Failed to find a usable modem character set
Here are the modem type: : (ttyHS0): --> 'AT+GMI' : (ttyHS0): <-- 'Option N.V.OK' : (ttyHS0): --> 'AT+GMM' : (ttyHS0): <-- 'GlobeTrotter HSDPA ModemOK' : (ttyHS0): --> 'AT+GMR' : (ttyHS0): <-- '2.4.6Hd (Date: Oct 04 2007, Time: 14:11:38)OK' : (ttyHS0): --> 'AT+CGMI' : (ttyHS0): <-- 'Option N.V.OK' : (ttyHS0): --> 'AT+CGMM' : (ttyHS0): <-- 'GlobeTrotter HSDPA ModemOK' : (ttyHS0): --> 'AT+CGMR' : (ttyHS0): <-- '2.4.6Hd (Date: Oct 04 2007, Time: 14:11:38)OK' : (ttyHS0): --> 'ATI' : (ttyHS0): <-- 'Manufacturer: Option N.V.Model: GlobeTrotter HSDPA ModemRevision: 2.4.6Hd (Date: Oct 04 2007, Time: 14:11:38)OK' : (ttyHS0): --> 'ATI1' : (ttyHS0): <-- 'Manufacturer: Option N.V.Model: GlobeTrotter HSDPA ModemRevision: 2.4.6Hd (Date: Oct 04 2007, Time: 14:11:38)OK' Bus 002 Device 013: ID 0af0:6971 Option Globetrotter HSDPA Modem Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 255 Vendor Specific Subclass bDeviceProtocol 255 Vendor Specific Protocol bMaxPacketSize064 idVendor 0x0af0 Option idProduct 0x6971 Globetrotter HSDPA Modem bcdDevice0.00 iManufacturer 1 Option N.V. iProduct2 Globetrotter HSDPA Modem iSerial 4 Serial Number bNumConfigurations 1 Gerald > -Original Message- > From: Dan Williams [mailto:d...@redhat.com] > Sent: Thursday, September 15, 2011 5:06 PM > To: Aleksander Morgado > Cc: Gerald Richter - ECOS; networkmanager-list@gnome.org > Subject: Re: GlobeTrotter HSDPA Modem -> Failed to find a usable modem > character set > > On Thu, 2011-09-15 at 13:22 +0200, Aleksander Morgado wrote: > > > (ttyHS0): --> 'AT_OPSYS?' > > > Sep 15 10:43:34 ThinClient modem-manager[2081]: > > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- > > > 'ERROR' > > > Sep 15 10:43:34 ThinClient modem-manager[2081]: > > > [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got failure > > > code 100: Unknown error Sep 15 10:43:34 ThinClient > > > modem-manager[2081]: [mm-at-serial-port.c:298] debug_log(): > > > (ttyHS0): --> 'AT+CSCS=?' > > > Sep 15 10:43:34 ThinClient modem-manager[2081]: > > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- '_OPSYS: > > > 3,2OK' > > > Sep 15 10:43:34 ThinClient modem-manager[2081]: > > > [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT > > > +CMER=3,0,0,1' > > > > To me the real issue here seems to be that the reply to "AT_OPSYS?" is > > split in a first "ERROR" string and then "_OPSYS: 3,2 OK". The serial > > parsers will consider the ERROR part as being a full response, and > > therefore ModemManager issues the "AT+CSCS?" command next, and > then we > > get the second chunk of the OPSYS reply as if it were the reply to the > > AT+CSCS... The fix could be to let "ERROR" be considered as a partial > > reply by providing a custom regex in the response parsers, similar to > > what it was done here: > > > > > http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id > =262ed > > b96d50138a724173840fc63ca93ede322c2 > > That's a really weird response though. I can't recall having seen a modem > return ERROR *and* a valid response. Perhaps the response there is actually > an unsolicited response that's been enabled by the AT_OSSYS=1. It may be > that the modem simply isn't quite ready yet when we start poking it? That > could also be the reason why AT_OSQI=1 is failing. > > What Option modem is this again? > > Dan > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
No autostart for UMTS connections in 0.9
Hi, the commit http://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ac27e33f0c948cad916305ff9e32d1ac59cfb27e is the cause that UMTS connection are not automatically started anymore after update to Network Manager 0.9 . It seems that all the UMTS modems I have tested, are disabled after NM startup, so they will not automatically start. Is it intended that a modem is disabled after plug in/startup also the modem is fully working? Or is this some mistake on my side? Regards Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: ip-config -> failed for GlobeTrotter HSDPA Modem
Hi,
updating udev from 1.5x to 1.71 solved the problem finally
Gerald
> -Original Message-
> From: rich...@ecos.de [mailto:networkmanager-list-boun...@gnome.org]
> On Behalf Of Gerald Richter - ECOS
> Sent: Tuesday, September 13, 2011 9:42 PM
> To: Dan Williams
> Cc: networkmanager-list@gnome.org
> Subject: RE: ip-config -> failed for GlobeTrotter HSDPA Modem
>
> Hi,
>
> usb_id etc is ok, but I found that the properties are not written to the udev
> database. After some research (actually more try&error) I found the reason
> is, that there is no NAME for the hso0 device. I added a line
>
> KERNEL=="hso0", NAME="hso0"
>
> And now it works :-)
>
> Question is, is there any udev rule file that is missing on my system that is
> supposed to do that job or could it be a missing kernel option?
>
> I saw a similar behavior for Ericsson MBM device (unfortunately I don't have
> one here to test), so it seems to be a general issue on that system.
>
> Thanks very much for your support, this was a long standing issue on that
> system and I am very happy to found the reason!
>
> Regards
>
> Gerald
>
>
> > -----Original Message-
> > From: Dan Williams [mailto:d...@redhat.com]
> > Sent: Tuesday, September 13, 2011 7:08 PM
> > To: Gerald Richter - ECOS
> > Cc: networkmanager-list@gnome.org
> > Subject: RE: ip-config -> failed for GlobeTrotter HSDPA Modem
> >
> > On Tue, 2011-09-13 at 18:07 +0200, rich...@ecos.de wrote:
> > > Hi,
> > >
> > > here ist he output for hso0.
> >
> > Which version of udev do you have, and do you have the 'usb_id'
> > program in /lib/udev anywhere, and the corresponding
> > /lib/udev/rules.d/75-net- description.rules file that includes a rule like
> > so?
> >
> > SUBSYSTEMS=="usb", ENV{ID_MODEL}=="", IMPORT{program}="usb_id --
> > export %p"
> >
> > That appears to be what provides the ID_MODEL / ID_VENDOR stuff that
> > ModemManager will be looking for.
> >
> > Dan
> >
> > > Regards
> > >
> > > Gerald
> > >
> > > --
> > > Name: hso0
> > > Type: wwan
> > > Subsys: net
> > > Number: 0
> > > Path: /sys/devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-
> > 1:1.0/net/hso0
> > > Driver: (null)
> > > Action: (null)
> > > Seq Num: 0
> > > Dev File: (null)
> > >
> > > Properties:
> > > UDEV_LOG: 3
> > > DEVPATH: /devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-
> > 1:1.0/net/hso0
> > > DEVTYPE: wwan
> > > INTERFACE: hso0
> > > IFINDEX: 36
> > > SUBSYSTEM: net
> > >
> > > --
> > > Name: 2-1:1.0
> > > Type: usb_interface
> > > Subsys: usb
> > > Number: 0
> > > Path:
> > > /sys/devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-
> > 1:1.0
> > > Driver: hso
> > > Action: (null)
> > > Seq Num: 0
> > > Dev File: (null)
> > >
> > > Properties:
> > > UDEV_LOG: 3
> > > DEVPATH: /devices/pci:00/:00:11.0/:02:00.0/usb2/2-
> 1/2-
> > 1:1.0
> > > DEVTYPE: usb_interface
> > > DRIVER:hso
> > > DEVICE:/proc/bus/usb/002/027
> > > PRODUCT: af0/6971/0
> > > TYPE: 255/255/255
> > > INTERFACE: 255/255/255
> > > MODALIAS: usb:v0AF0p6971ddcFFdscFFdpFFicFFiscFFipFF
> > > SUBSYSTEM: usb
> > >
> > > --
> > > Name: 2-1
> > > Type: usb_device
> > > Subsys: usb
> > > Number: 1
> > > Path:
> > > /sys/devices/pci:00/:00:11.0/:02:00.0/usb2/2-1
> > > Driver: usb
> > > Action: (null)
> > > Seq Num: 0
> > > Dev File: /dev/bus/usb/002/027
> > >
> > > Properties:
> > > UDEV_LOG: 3
> > > DEVPATH:
> > /devices/pci:00/:00:11.0/:02:00.0/usb2/2-1
> > > MAJOR: 189
> > > MINOR: 154
> > > DEVNAME
GlobeTrotter HSDPA Modem -> Failed to find a usable modem character set
m-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT+CIND=?' Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- 'OK' Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT_OPSYS?' Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- 'ERROR' Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-serial-parsers.c:412] mm_serial_parser_v1_parse(): Got failure code 100: Unknown error Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT+CSCS=?' Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- '_OPSYS: 3,2OK' Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT+CMER=3,0,0,1' Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-modem.c:742] mm_modem_set_state(): Modem /org/freedesktop/ModemManager/Modems/0: state changed (enabling -> disabled) Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-serial-port.c:844] mm_serial_port_close(): (ttyHS0) device open count is 0 (close) Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-serial-port.c:859] mm_serial_port_close(): (ttyHS0) closing serial port... Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-serial-port.c:880] mm_serial_port_close(): (ttyHS0) serial port closed Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-serial-port.c:844] mm_serial_port_close(): (ttyHS1) device open count is 0 (close) Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-serial-port.c:859] mm_serial_port_close(): (ttyHS1) closing serial port... Sep 15 10:43:34 ThinClient modem-manager[2081]: [mm-serial-port.c:880] mm_serial_port_close(): (ttyHS1) serial port closed Sep 15 10:43:34 ThinClient NetworkManager[2069]: GSM modem enable failed: (32) Failed to find a usable modem character set Sep 15 10:43:34 ThinClient NetworkManager[2069]: (hso0): device state change: prepare -> failed (reason 'modem-init-failed') [40 120 28] Sep 15 10:43:34 ThinClient NetworkManager[2069]: Activation (hso0) failed. --- Gerald Richter Tel. +49 (6133) 939-122 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
PATCH / novj is not set
Hi, the setting for novj is missing in ppp-manager. Patch is attached Regards Gerald nm_no_vj.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: ip-config -> failed for GlobeTrotter HSDPA Modem
Hi,
usb_id etc is ok, but I found that the properties are not written to the udev
database. After some research (actually more try&error) I found the reason is,
that there is no NAME for the hso0 device. I added a line
KERNEL=="hso0", NAME="hso0"
And now it works :-)
Question is, is there any udev rule file that is missing on my system that is
supposed to do that job or could it be a missing kernel option?
I saw a similar behavior for Ericsson MBM device (unfortunately I don't have
one here to test), so it seems to be a general issue on that system.
Thanks very much for your support, this was a long standing issue on that
system and I am very happy to found the reason!
Regards
Gerald
> -Original Message-
> From: Dan Williams [mailto:d...@redhat.com]
> Sent: Tuesday, September 13, 2011 7:08 PM
> To: Gerald Richter - ECOS
> Cc: networkmanager-list@gnome.org
> Subject: RE: ip-config -> failed for GlobeTrotter HSDPA Modem
>
> On Tue, 2011-09-13 at 18:07 +0200, rich...@ecos.de wrote:
> > Hi,
> >
> > here ist he output for hso0.
>
> Which version of udev do you have, and do you have the 'usb_id' program in
> /lib/udev anywhere, and the corresponding /lib/udev/rules.d/75-net-
> description.rules file that includes a rule like so?
>
> SUBSYSTEMS=="usb", ENV{ID_MODEL}=="", IMPORT{program}="usb_id --
> export %p"
>
> That appears to be what provides the ID_MODEL / ID_VENDOR stuff that
> ModemManager will be looking for.
>
> Dan
>
> > Regards
> >
> > Gerald
> >
> > --
> > Name: hso0
> > Type: wwan
> > Subsys: net
> > Number: 0
> > Path: /sys/devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-
> 1:1.0/net/hso0
> > Driver: (null)
> > Action: (null)
> > Seq Num: 0
> > Dev File: (null)
> >
> > Properties:
> > UDEV_LOG: 3
> > DEVPATH: /devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-
> 1:1.0/net/hso0
> > DEVTYPE: wwan
> > INTERFACE: hso0
> > IFINDEX: 36
> > SUBSYSTEM: net
> >
> > --
> > Name: 2-1:1.0
> > Type: usb_interface
> > Subsys: usb
> > Number: 0
> > Path: /sys/devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-
> 1:1.0
> > Driver: hso
> > Action: (null)
> > Seq Num: 0
> > Dev File: (null)
> >
> > Properties:
> > UDEV_LOG: 3
> > DEVPATH: /devices/pci:00/:00:11.0/:02:00.0/usb2/2-1/2-
> 1:1.0
> > DEVTYPE: usb_interface
> > DRIVER:hso
> > DEVICE:/proc/bus/usb/002/027
> > PRODUCT: af0/6971/0
> > TYPE: 255/255/255
> > INTERFACE: 255/255/255
> > MODALIAS: usb:v0AF0p6971ddcFFdscFFdpFFicFFiscFFipFF
> > SUBSYSTEM: usb
> >
> > --
> > Name: 2-1
> > Type: usb_device
> > Subsys: usb
> > Number: 1
> > Path: /sys/devices/pci:00/:00:11.0/:02:00.0/usb2/2-1
> > Driver: usb
> > Action: (null)
> > Seq Num: 0
> > Dev File: /dev/bus/usb/002/027
> >
> > Properties:
> > UDEV_LOG: 3
> > DEVPATH:
> /devices/pci:00/:00:11.0/:02:00.0/usb2/2-1
> > MAJOR: 189
> > MINOR: 154
> > DEVNAME: /dev/bus/usb/002/027
> > DEVTYPE: usb_device
> > DRIVER:usb
> > DEVICE:/proc/bus/usb/002/027
> > PRODUCT: af0/6971/0
> > TYPE: 255/255/255
> > BUSNUM:002
> > DEVNUM:027
> > SUBSYSTEM: usb
> > ID_VENDOR: Option_N.V.
> > ID_VENDOR_ENC: Option\x20N.V.
> > ID_VENDOR_ID: 0af0
> > ID_MODEL: Globetrotter_HSDPA_Modem
> > ID_MODEL_ENC: Globetrotter\x20HSDPA\x20Modem\x20\x20
> > ID_MODEL_ID: 6971
> > ID_REVISION:
> > ID_SERIAL:
> Option_N.V._Globetrotter_HSDPA_Modem_Serial_Number
> > ID_SERIAL_SHORT: Serial_Number
> > ID_BUS:usb
> > ID_USB_INTERFACES: :ff:
&g
RE: ip-config -> failed for GlobeTrotter HSDPA Modem
: pci:v8086d7112sv15ADsd1976bc0Csc03i00 SUBSYSTEM: pci -- Name: :00:11.0 Type: (null) Subsys: pci Number: 0 Path: /sys/devices/pci:00/:00:11.0 Driver: (null) Action: (null) Seq Num: 0 Dev File: (null) Properties: UDEV_LOG: 3 DEVPATH: /devices/pci:00/:00:11.0 PCI_CLASS: 60401 PCI_ID:15AD:0790 PCI_SUBSYS_ID: 15AD:0790 PCI_SLOT_NAME: :00:11.0 MODALIAS: pci:v15ADd0790sv15ADsd0790bc06sc04i01 SUBSYSTEM: pci -- Name: pci:00 Type: (null) Subsys: (null) Number: 00 Path: /sys/devices/pci:00 Driver: (null) Action: (null) Seq Num: 0 Dev File: (null) Properties: UDEV_LOG: 3 DEVPATH: /devices/pci:00 > -Original Message- > From: Dan Williams [mailto:d...@redhat.com] > Sent: Monday, September 12, 2011 11:29 PM > To: Gerald Richter - ECOS > Cc: networkmanager-list@gnome.org > Subject: RE: ip-config -> failed for GlobeTrotter HSDPA Modem > > On Fri, 2011-09-09 at 06:46 +0200, rich...@ecos.de wrote: > > Hi Dan, > > > > my teststick was "Out Of Office", but now I have it back again and here is > what I found.. > > > > > For your device we're not seeing the OWANDATA call there. That > > > appears to be because MM is not recognizing your modem's network > > > device which should be called 'hso0'. Can you provide logs of > > > starting up ModemManager with the device plugged in so we can debug > > > what's not happening about the detection process? Also, when you > > > plug the modem in, do you see 'hso0' (or > > > hso1 or whatever) in the output of 'ifconfig -a' ? > > > > > > > Attached are two log files. Umts3.log shows starting up modem manager > with device already pluged in, umts_plugin.log shows pluging in the device, > while modem manager is already running. > > So here's the issue: > > Sep 9 06:22:38 ThinClient modem-manager[3980]: [mm- > manager.c:574] do_grab_port(): plugin 'Option High-Speed' claimed to > support net/hso0 but couldn't: (0) Could not get modem product ID. > > That indicates something odd with the sysfs/udev hierarchy, which is how > you figure out what USB vendor and product the device has. This could > indicate a buggy kernel driver, though the upstream kernel 'hso' driver hasn't > changed in a while. It could also indicate something wrong with udev or > sysfs. So heres what we do: > > 1) grab > http://cgit.freedesktop.org/ModemManager/ModemManager/plain/test/ls > udev.c > 2) grab udev development headers (libudev-dev or libudev-devel or > libudev1-dev or whatever your distro calls them) > 3) grab gudev development headers (libgudev-dev or libgudev1-devel or > whatever) > 4) build lsudev.c like so: > > gcc -o lsudev `pkg-config --cflags --libs gudev-1.0` lsudev.c > > 5) with the modem plugged in and already switched to modem mode, run > lsudev like so: > > sudo lsudev net > > And report the output. That will print out the sysfs/udev device hierarchy > for > this device and let us figure out what's wrong. > > Dan > > > Ifconfig -a shows the hso0 device (see ifconfig.log) and the kernel loads > > the > hso driver (start of umts3.log). Also /sys/class/net has an entry for hso0. > > > > Are there any hso udev rules necessary? I saw in the internet that there is > > a > hso udev rule file which sets several devices with fixed names. It seems that > this is not necessary for ModemManager, but maybe I am wrong? > > > > Thanks & Regards > > > > Gerald > > > > > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
RE: Gobi firmware (was: Not detecting broadband card)
Hi, is there a place to get the all gobi firmware "for linux". Until now we extracted it from the windows drivers and I am not sure if we have pick up the right one. Would be cool if there is some download possibility. Thanks & Regards Gerald > -Original Message- > From: d...@redhat.com [mailto:networkmanager-list- > boun...@gnome.org] On Behalf Of Dan Williams > Sent: Tuesday, September 13, 2011 5:23 PM > To: Levi Stanley > Cc: networkmanager-list@gnome.org > Subject: Re: Not detecting broadband card > > On Tue, 2011-09-13 at 09:05 -0400, Levi Stanley wrote: > > I have a Broadband card (Bus 001 Device 010: ID 413c:8185 Dell > > Computer Corp. Gobi 2000 Wireless Modem (QDL mode)), I use to be able > > to get it recognized by killing the modem-manager, and starting it up > > again, however, recently, even that doesn't seem to get it recognized. > > > > When I type: > > > > sudo ./lsudev net > > For the Gobi devices though, you'll want 'lsudev tty' since they don't expose > network interfaces, they are currently plain serial devices. > Just to verify, you do have the gobi_loader firmware stuff all set up with > all 3 > firmware files present? > > Dan > > > > > I get a list, but it seems to hang, so it never finishes. Output of > > command: > > > > -- > > Name: wlan0 > > Type: wlan > > Subsys: net > > Number: 0 > > Path: /sys/devices/pci:00/:00:1c.1/:0c:00.0/net/wlan0 > > Driver: (null) > > Action: (null) > > Seq Num: 0 > > Dev File: (null) > > > > Properties: > > UDEV_LOG:3 > > DEVPATH: > > /devices/pci:00/:00:1c.1/:0c:00.0/net/wlan0 > > DEVTYPE: wlan > > INTERFACE: wlan0 > > IFINDEX: 5 > > SUBSYSTEM: net > > ID_VENDOR_FROM_DATABASE: Intel Corporation > > ID_MODEL_FROM_DATABASE: PRO/Wireless 5300 AGN [Shiloh] Network > Connection > > ID_BUS: pci > > ID_VENDOR_ID:0x8086 > > ID_MODEL_ID: 0x4235 > > > > -- > > Name: :0c:00.0 > > Type: (null) > > Subsys: pci > > Number: 0 > > Path: /sys/devices/pci:00/:00:1c.1/:0c:00.0 > > Driver: iwlagn > > Action: (null) > > Seq Num: 0 > > Dev File: (null) > > > > Properties: > > UDEV_LOG: 3 > > DEVPATH: /devices/pci:00/:00:1c.1/:0c:00.0 > > DRIVER:iwlagn > > PCI_CLASS: 28000 > > PCI_ID:8086:4235 > > PCI_SUBSYS_ID: 8086:1121 > > PCI_SLOT_NAME: :0c:00.0 > > MODALIAS: > pci:v8086d4235sv8086sd1121bc02sc80i00 > > SUBSYSTEM: pci > > > > -- > > Name: :00:1c.1 > > Type: (null) > > Subsys: pci > > Number: 1 > > Path: /sys/devices/pci:00/:00:1c.1 > > Driver: pcieport > > Action: (null) > > Seq Num: 0 > > Dev File: (null) > > > > Properties: > > UDEV_LOG: 3 > > DEVPATH: /devices/pci:00/:00:1c.1 > > DRIVER:pcieport > > PCI_CLASS: 60400 > > PCI_ID:8086:3B44 > > PCI_SUBSYS_ID: 1028:02EF > > PCI_SLOT_NAME: :00:1c.1 > > MODALIAS: > > pci:v8086d3B44sv1028sd02EFbc06sc04i00 > > SUBSYSTEM: pci > > > > -- > > Name: pci:00 > > Type: (null) > > Subsys: (null) > > Number: 00 > > Path: /sys/devices/pci:00 > > Driver: (null) > > Action: (null) > > Seq Num: 0 > > Dev File: (null) > > > > Properties: > > UDEV_LOG: 3 > > DEVPATH: /devices/pci:00 > > > > > > -- > > Name: eth0 > > Type: (null) > > Subsys: net > > Number: 0 > > Path: /sys/devices/pci:00/:00:1c.5/:09:00.0/net/eth0 > > Driver: (null) > > Action: (null) > > Seq Num: 0 > > Dev File: (null) > > > > Properties: > > UDEV_LOG:3 > > DEVPATH: > > /devices/pci:00/:00:1c.5/:09:00.0/net/eth0 > > INTERFACE: eth0 > > IFINDEX: 2 > > SUBSYSTEM: net > > ID_VENDOR_FROM_DATABASE: Broadcom Corporation > > ID_MODEL_FROM_DATABASE: NetXtreme BCM5761e Gigabit Ethernet > PCIe > > ID_BUS: pci > > ID_VENDOR_ID:0x14e4 > > ID_MODEL_ID: 0x1680 > > > > -- > > Name: :09:00.0 > > Type: (null) > > Subsys: pci > >
Problems/Patches auto reconnect lost UMTS connections
Hi, I am trying to get automatic reconnection of UMTS connections that are disconnected for example due to low signal to get working. I seems that are some problems, that comes up to time to time again, but I don't see a solution. I am using network manager 0.9 and modem manager 0.5. I have identified the following problems: 1.) Auto reconnection stops after some retries. This makes sense for many types of connections, but not for UMTS connections. I want to reconnect over and over again until signal is good enough again. The patch auto_act.patch changes this behavior. Not sure if this is the best solution, but it works for me. 2.) When pppd ends, for example because of lcp echo request failure, the ppp device gets removed, which in turn causes network manger to move the ttyUSB device in an unmanaged state. So it's now the same as if I remove my USB stick. The only chance to get it working again, is to really unplug the stick and insert it again. Bad luck if you have an internal UMTS modem... The patch no_device_disable.patch changes this behavior. It directly compares the device name to ppp, which might not be the best idea, but I haven't found a more clean way. 3.) If the pppd has already started the first ttyUSB device is in data mode, which is not reseted anymore. In this state, the only chance to get a new connection, is to disable UMTS at all and to reenable it. Then the modem gets initialized again and everything is working fine. So what I think what would be necessary here is that if pppd is stopped that the modem is reseted. I didn't found a way to do it and hope somebody on the list can point me a way. As a fallback I think it would be a good idea if modem-manager, in case it gets an timeout when speaking the ttyUSB port, it just resets the modem and tries it again. Again I didn't find the right place to implement this. Any hints are welcome. 4.) We have an UMTS connection which requires username and password, which are save in a system connection. If pppd fails during handshaking, the users gets ask for a chap password, which he does not know, should not know. The no_ppp_pw.patch changes this behavior. I think it's not a real solution, because it disables asking for a password in case of failure at all, but it shows the problem (and solves the problem for me). I would be very happy if somebody can give me some help how to solve problems in 3.) Regards Gerald auto_act.patch Description: Binary data no_device_disable.patch Description: Binary data no_ppp_pw.patch Description: Binary data ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Disable initial UMTS PIN Dialog
Hi, is it possible to disable the initial UMTS PIN dialog? The background is, we have a lot of Laptops which has just one UMTS connection, where the PIN is saved in the PIN settings. The connection set to autostart. If the connection doesn't come up fast enough or even if it gets interrupted, a PIN dialog shows up. In the later case, if you do not answer the PIN dialog, the connection still gets connected with the saved PIN and if you enter the PIN in the dialog afterwards, you got an error that the connection is already connected. This is very confusing to the end user. As far as I see all this trouble can be avoided if a PIN is only requested when a UMTS connection is made and the PIN is not saved. Is there any chance to get this kind of behavior or does somebody has any pointer where in the code I have to dig to make a patch to implement this behavior? We are using network manger 0.9 and modem manger 0.5 Thanks & Regards Gerald --- Gerald Richter Tel. +49 (6133) 939-122 ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
ip-config -> failed for GlobeTrotter HSDPA Modem
Hi, I am trying to get GlobeTrotter HSDPA Modem to run with network manager 0.9 and modem manager 0.5. Both are build from Gentoo ebuild system. Everything works fine until the ip configuration should happen, which fails. Here is the debug output: Sep 5 08:47:28 ThinClient modem-manager[2056]: [mm-generic-gsm.c:4988] simple_state_machine(): (ttyHS0): simple connect state 5 Sep 5 08:47:28 ThinClient modem-manager[2056]: [mm-modem.c:742] mm_modem_set_state(): Modem /org/freedesktop/ModemManager/Modems/1: state changed (registered -> connecting) Sep 5 08:47:28 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT_OCTI?' Sep 5 08:47:28 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- '_OCTI: 1,3OK' Sep 5 08:47:28 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT$QCPDPP=1,1,"vodafone","vodafone"' Sep 5 08:47:29 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- 'OK' Sep 5 08:47:29 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT_OWANCALL=1,0,1' Sep 5 08:47:29 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- 'OK' Sep 5 08:47:29 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): --> 'AT_OWANCALL=1,1,1' Sep 5 08:47:29 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- 'OK' Sep 5 08:47:30 ThinClient modem-manager[2056]: [mm-at-serial-port.c:298] debug_log(): (ttyHS0): <-- '_OWANCALL: 1, 1' Sep 5 08:47:30 ThinClient modem-manager[2056]: [mm-port.c:181] mm_port_set_connected(): (ttyHS0): port now connected Sep 5 08:47:30 ThinClient modem-manager[2056]: [mm-modem.c:742] mm_modem_set_state(): Modem /org/freedesktop/ModemManager/Modems/1: state changed (connecting -> connected) Sep 5 08:47:30 ThinClient modem-manager[2056]: [mm-generic-gsm.c:4988] simple_state_machine(): (ttyHS0): simple connect state 6 Sep 5 08:47:30 ThinClient NetworkManager[2044]: Activation (ttyHS0) Stage 2 of 5 (Device Configure) scheduled... Sep 5 08:47:30 ThinClient NetworkManager[2044]: Activation (ttyHS0) Stage 2 of 5 (Device Configure) starting... Sep 5 08:47:30 ThinClient NetworkManager[2044]: (ttyHS0): device state change: prepare -> config (reason 'none') [40 50 0] Sep 5 08:47:30 ThinClient NetworkManager[2044]: Activation (ttyHS0) Stage 2 of 5 (Device Configure) successful. Sep 5 08:47:30 ThinClient NetworkManager[2044]: Activation (ttyHS0) Stage 3 of 5 (IP Configure Start) scheduled. Sep 5 08:47:30 ThinClient NetworkManager[2044]: Activation (ttyHS0) Stage 2 of 5 (Device Configure) complete. Sep 5 08:47:30 ThinClient NetworkManager[2044]: Activation (ttyHS0) Stage 3 of 5 (IP Configure Start) started... Sep 5 08:47:30 ThinClient NetworkManager[2044]: (ttyHS0): device state change: config -> ip-config (reason 'none') [50 70 0] Sep 5 08:47:30 ThinClient NetworkManager[2044]: [1315205250.785194] [NetworkManagerUtils.c:878] nm_utils_get_proc_sys_net_value(): (ttyHS0): error reading /proc/sys/net/ipv6/conf/ttyHS0/accept_ra: (4) Failed to open file '/proc/sys/net/ipv6/conf/ttyHS0/accept_ra': No such file or directory Sep 5 08:47:30 ThinClient NetworkManager[2044]: Activation (ttyHS0) Stage 3 of 5 (IP Configure Start) complete. Sep 5 08:47:30 ThinClient NetworkManager[2044]: retrieving IP4 configuration failed: (32) Sending command failed: device is connected Sep 5 08:47:30 ThinClient NetworkManager[2044]: (ttyHS0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5] Sep 5 08:47:30 ThinClient NetworkManager[2044]: Activation (ttyHS0) failed. Sep 5 08:47:30 ThinClient NetworkManager[2044]: [1315205250.789933] [nm-device.c:3649] failed_to_disconnected(): (ttyHS0): running failed->disconnected transition Sep 5 08:47:30 ThinClient NetworkManager[2044]: (ttyHS0): device state change: failed -> disconnected (reason 'none') [120 30 0] Sep 5 08:47:30 ThinClient NetworkManager[2044]: (ttyHS0): deactivating device (reason: 0). Sep 5 08:47:30 ThinClient NetworkManager[2044]: [1315205250.790191] [nm-system.c:1349] flush_routes(): (ttyHS0) failed to lookup interface index Sep 5 08:47:30 ThinClient NetworkManager[2044]: [1315205250.790589] [nm-system.c:1349] flush_routes(): (ttyHS0) failed to lookup interface index And this is what dbus-monitor shows me, when the ip config is retrieved: signal sender=:1.7 -> dest=(null destination) serial=789 path=/org/freedesktop/NetworkManager/Devices/3; interface=org.freedesktop.NetworkManager.Device.Modem; member=PropertiesChanged array [ dict entry( string "State" variant uint32 30 ) dict entry( string "Ip6Config" variant object path "/" ) dict entry( string "Ip4Config" variant
Modem Manger fails after low mobile signal quality
Hi, I am testing the current git version (as of yesterday) of NetworkManger and ModemManger. It works fine, until I have low mobile signal quality. In the case the umts device cannot register with the mobile provider (of course). When I now move my laptop to a place where I have a good mobile signal quality, I still cannot connect. I need to kill modem-manger, then it get's restarted by NetworkManger and everything is fine again. I attach two logfiles. The mess_bad show the problem (signal is already ok again, so a connection should be possible) and mess_ok show what happeing after modem-manager restart (without changing anythingelse). In addition in such a low signal situations, sometimes strange things are happeing, for example, when pppd start's I get a dialog, asks me for the password (which was saved in the connection settings and worked before, but now it seems to got lost) or even worse the mobile device is disabled at all and is removed from the network manager applet. These thing are occuring randomly... I would expect that when the signal quality improves, the mobile device gets connected again, at least after a manual start from network manager applet's menu. Any idea how to fix it or how to futher debug it? Thanks & Regards Gerald ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Selfcompiled NetworkManager doesnt start
Am Tue, 14 Aug 2007 10:45:23 -0400 schrieb Dan Williams <[EMAIL PROTECTED]>: > On Tue, 2007-08-14 at 18:26 +0200, Fabian Richter wrote: > Try sending a SIGHUP to your system messagebus process to get it to > reload the config files. Also, which distribution? This error > basically means that dbus doesn't know anything about a security > policy for NM, possibly because it hasn't been told about one yet. > > Dan > I dont know if SIGHUP is any better than /etc/init.d/dbus restart which i already did after is changed all deny to allow in the policy configs but ill give it a try tomorrow! Distro is debian sid. kernel is 2.6.22.2 and wlan is iwl3945. Regards Fabian ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Selfcompiled NetworkManager doesnt start
Hi folks! I just downloaded and compiled NetworkManager but after make install nothing works! Configure and make both finish successfully but when I do NetworkManager in a root shell afterwards nothin happens. With the --no-daemon option i get the following: # NetworkManager --no-daemon NetworkManager: starting... NetworkManager: nm_dbus_init(): nm_dbus_init() could not acquire the NetworkManager service. Message: 'Connection ":1.8" is not allowed to own the service "org.freedesktop.NetworkManager" due to security policies in the configuration file' NetworkManager: [1187108554.318532] main/etc/dbus-1/system.d/NetworkManger.conf (): nm_dbus_init() failed, exiting. Either dbus is not running, or the NetworkManager dbus security policy was not loaded. NetworkManager: traceback: NetworkManager:NetworkManager(main+0x744) [0x8069174] NetworkManager: /lib/i686/cmov/libc.so.6(__libc_start_main+0xe0) [0xb7c71050] NetworkManager: NetworkManager [0x80540c1] Trace/Breakpoint ausgelöst # I already googled and found something about dbus policys, then i changed the /etc/dbus-1/system.d/nm-applet.conf and /etc/dbus-1/system.d/NetworkManger.conf but nothing changed :( Somebody any idea? Greetings Fabian ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
