Re: A general (learning) query
On Monday 18 June 2012, Ajay Garg wrote: > Sorry, > > forgot ATI. > > > > ### > ### Welcome to minicom 2.5 > > OPTIONS: I18n > Compiled on Feb 24 2011, 11:25:55. > Port /dev/ttyUSB0 > > Press CTRL-A Z for help on special > keys > > > AT S7=45 S0=0 L1 V1 X4 &c1 E1 > Q0 > OK > > AT&V > > &C: 1; &D: 2; &F: 0; E: 1; L: 1; M: 0; Q: 0; V: 1; X: 4; Z: 0; S0: 0; > S3: 13; S4: 10; S5: 8; S6: 2; S7: 45; S8: 2; S9: 6; S10: 14; S11: 95; > +FCLASS: 0; +ICF: 3,3; +IFC: 2,2; +IPR: 115200; +DR: 0; +DS: 0,0,2048,6; > +WS46: 12; +CBST: 0,0,1; > +CRLP: (61,61,48,6,0),(61,61,48,6,1),(240,240,52,6,2); > +CV120: 1,1,1,0,0,0; +CHSN: 0,0,0,0; +CSSN: 0,0; +CREG: 0; +CGREG: 0; > +CFUN:; +CSCS: "IRA"; +CSTA: 129; +CR: 0; +CRC: 0; +CMEE: 0; +CGDCONT: > (1,"IP","","0.0.0.0",0,0),(2,"IP","Ceibal","0.0.0.0",0,0),(3,"IP","gprs.anc > el1","0.0.0.0",0,0),() ; +CGDSCONT: ; +CGTFT: ; +CGEQREQ: > (1,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(2,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(3, > 2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(4,2,0,0,0,0,2,0,"0E0",") ; +CGEQMIN: ; > +CGQREQ: ; +CGQMIN: ; ; +CGEREP: 0,0; +CGCLASS: "A"; +CGSMS: 0; +CSMS: 0; > +CMGF: 0; +CSCA: "",; +CSMP: ,,0,0; +CSDH: 0; +CSCB: 0,"",""; +FDD: 0; > +FAR: 0; +FCL: 0; +FIT: 0,0; +ES: ,,; > +ESA: 00,0,255,; +CMOD: 0; +CVHU: 1; ; +CPIN: ,; +CMEC: 0,0,0; > +CKPD: 1,1; +CGATT: 0; +CGACT: 0; +CPBS: "SM"; +CPMS: "SM","SM","SM"; > +CNMI: 0,0,0,0,0; +CMMS: 2; +FTS: 0; +FRS: 0; +FTH: 3; +FRH: 3; +FTM: 96; > +FRM: 96; +CCUG: 0,0,0; +COPS: 0,2,""; +CUSD: 0; +CAOC: 1; +CCWA: 0; > +CLVL: 2; +CMUT: 0; +CPOL: 0,2,"",0,0,0; +CPLS: 0; +CTZR: 0; +CLIP: 0; > +COLP: 0; +CLIR: 0; ^PORTSEL: 0; ^CPIN: ,; ^ATRECORD: 0; > ^FREQLOCK: 10226476,12482272 > > OK > AT+CLAC > ERROR > AT+CPIN? > +CPIN: SIM PIN > > OK > ATI > Manufacturer: huawei > Model: E226 > Revision: 11.310.15.00.255 > IMEI: > +GCAP: +CGSM,+DS,+ES > > OK > ### > ### > > > > > Thanks and Regards, > Ajay > > On Mon, Jun 18, 2012 at 7:07 PM, Ajay Garg wrote: > > Hi Dan. > > > > Here is the output of "AT+CPIN?" (along with other commands, for brevity) > > > > > > > > > > > > # > > ### > > > > Welcome to minicom 2.5 > > > > OPTIONS: I18n > > Compiled on Feb 24 2011, 11:25:55. > > Port /dev/ttyUSB0 > > > > Press CTRL-A Z for help on special > > keys > > > > > > AT S7=45 S0=0 L1 V1 X4 &c1 E1 > > Q0 > > OK > > > > AT&V > > > > &C: 1; &D: 2; &F: 0; E: 1; L: 1; M: 0; Q: 0; V: 1; X: 4; Z: 0; S0: 0; > > S3: 13; S4: 10; S5: 8; S6: 2; S7: 45; S8: 2; S9: 6; S10: 14; S11: 95; > > +FCLASS: 0; +ICF: 3,3; +IFC: 2,2; +IPR: 115200; +DR: 0; +DS: 0,0,2048,6; > > +WS46: 12; +CBST: 0,0,1; > > +CRLP: (61,61,48,6,0),(61,61,48,6,1),(240,240,52,6,2); > > +CV120: 1,1,1,0,0,0; +CHSN: 0,0,0,0; +CSSN: 0,0; +CREG: 0; +CGREG: 0; > > +CFUN:; +CSCS: "IRA"; +CSTA: 129; +CR: 0; +CRC: 0; +CMEE: 0; +CGDCONT: > > (1,"IP","","0.0.0.0",0,0),(2,"IP","Ceibal","0.0.0.0",0,0),(3,"IP","gprs.a > > ncel1","0.0.0.0",0,0),() ; +CGDSCONT: ; +CGTFT: ; +CGEQREQ: > > (1,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(2,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),( > > 3,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(4,2,0,0,0,0,2,0,"0E0",") ; +CGEQMIN: > > ; +CGQREQ: ; +CGQMIN: ; ; +CGEREP: 0,0; +CGCLASS: "A"; +CGSMS: 0; +CSMS: > > 0; +CMGF: 0; +CSCA: "",; +CSMP: ,,0,0; +CSDH: 0; +CSCB: 0,"",""; +FDD: > > 0; +FAR: 0; +FCL: 0; +FIT: 0,0; +ES: ,,; > > +ESA: 00,0,255,; +CMOD: 0; +CVHU: 1; ; +CPIN: ,; +CMEC: 0,0,0; > > +CKPD: 1,1; +CGATT: 0; +CGACT: 0; +CPBS: "SM"; +CPMS: "SM","SM","SM"; > > +CNMI: 0,0,0,0,0; +CMMS: 2; +FTS: 0; +FRS: 0; +FTH: 3; +FRH: 3; +FTM: 96; > > +FRM: 96; +CCUG: 0,0,0; +COPS: 0,2,""; +CUSD: 0; +CAOC: 1; +CCWA: 0; > > +CLVL: 2; +CMUT: 0; +CPOL: 0,2,"",0,0,0; +CPLS: 0; +CTZR: 0; +CLIP: 0; > > +COLP: 0; +CLIR: 0; ^PORTSEL: 0; ^CPIN: ,; ^ATRECORD: 0; > > ^FREQLOCK: 10226476,12482272 > > > > OK > > AT+CLAC > > ERROR > > AT+CPIN? > > +CPIN: SIM PIN > > > > OK > > > > # > > ### > > > > > > > > Is it, in fact, an issue with the SIM? > > > > > > > > Regards, > > Ajay > > > > On Fri, Jun 15, 2012 at 10:39 PM, Dan Williams wrote: > >> On Thu, 2012-06-14 at 08:07 -0400, Ajay Garg wrote: > >> > Hi Dan. > >> > >> > The minicom output :: > >> > >> ## > >> > >> > AT&V > >> > &C: 1; &D: 2; &F: 0; E: 1; L: 1; M: 0; Q: 0; V: 1; X: 4; Z: 0; S0: 0; > >> > S3: 13; S4: 10; S5: 8; S6: 2; S7: 45; S8: 2; S9: 6; S10: 14; S11: 95; > >> > +FCLASS: 0; +ICF: 3,3; +IFC: 2,2; +IPR: 115200; +DR: 0; +DS: > >> > 0,0,2048,6; > >> > +WS46: 12; +CBST: 0,0,1; > >> > +CRLP: (61,61,48,6,0),(61,6
Re: A general (learning) query
On Monday 18 June 2012, Ajay Garg wrote: > Thanks Andrew for the reply. > > I ran "AT+CFUN=1". > Following are the outputs subsequently :: > > > ### > # Welcome to minicom 2.5 > > OPTIONS: I18n > Compiled on Feb 24 2011, 11:25:55. > Port /dev/ttyUSB0 > > Press CTRL-A Z for help on special > keys > > > AT S7=45 S0=0 L1 V1 X4 &c1 E1 > Q0 > OK > > AT+CFUN? > > +CFUN: 1 > > OK > AT&V > &C: 1; &D: 2; &F: 0; E: 1; L: 1; M: 0; Q: 0; V: 1; X: 4; Z: 0; S0: 0; > S3: 13; S4: 10; S5: 8; S6: 2; S7: 45; S8: 2; S9: 6; S10: 14; S11: 95; > +FCLASS: 0; +ICF: 3,3; +IFC: 2,2; +IPR: 115200; +DR: 0; +DS: 0,0,2048,6; > +WS46: 12; +CBST: 0,0,1; > +CRLP: (61,61,48,6,0),(61,61,48,6,1),(240,240,52,6,2); > +CV120: 1,1,1,0,0,0; +CHSN: 0,0,0,0; +CSSN: 0,0; +CREG: 0; +CGREG: 0; > +CFUN:; +CSCS: "IRA"; +CSTA: 129; +CR: 0; +CRC: 0; +CMEE: 0; +CGDCONT: > (1,"IP","","0.0.0.0",0,0),(2,"IP","Ceibal","0.0.0.0",0,0),(3,"IP","gprs.anc > el1","0.0.0.0",0,0),() ; +CGDSCONT: ; +CGTFT: ; +CGEQREQ: > (1,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(2,2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(3, > 2,0,0,0,0,2,0,"0E0","0E0",3,0,0),(4,2,0,0,0,0,2,0,"0E0",") ; +CGEQMIN: ; > +CGQREQ: ; +CGQMIN: ; ; +CGEREP: 0,0; +CGCLASS: "A"; +CGSMS: 0; +CSMS: 0; > +CMGF: 0; +CSCA: "",; +CSMP: ,,0,0; +CSDH: 0; +CSCB: 0,"",""; +FDD: 0; > +FAR: 0; +FCL: 0; +FIT: 0,0; +ES: ,,; > +ESA: 00,0,255,; +CMOD: 0; +CVHU: 1; ; +CPIN: ,; +CMEC: 0,0,0; > +CKPD: 1,1; +CGATT: 0; +CGACT: 0; +CPBS: "SM"; +CPMS: "SM","SM","SM"; > +CNMI: 0,0,0,0,0; +CMMS: 2; +FTS: 0; +FRS: 0; +FTH: 3; +FRH: 3; +FTM: 96; > +FRM: 96; +CCUG: 0,0,0; +COPS: 0,2,""; +CUSD: 0; +CAOC: 1; +CCWA: 0; > +CLVL: 2; +CMUT: 0; +CPOL: 0,2,"",0,0,0; +CPLS: 0; +CTZR: 0; +CLIP: 0; > +COLP: 0; +CLIR: 0; ^PORTSEL: 0; ^CPIN: ,; ^ATRECORD: 0; > ^FREQLOCK: 10226476,12482272 > > OK > AT+CLAC > ERROR > AT+CPIN? > +CPIN: SIM PIN > > OK > ### > # > > > > > > > > However, the same old problem, when running "sudo wvdial" > > ### > # -bash-4.1# sudo wvdial > --> WvDial: Internet dialer version 1.61 > --> Cannot get information for serial port. > --> Initializing modem. > --> Sending: ATZ > ATZ > OK > --> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 > ATQ0 V1 E1 S0=0 &C1 &D2 > OK > --> Sending: AT+CGDCONT=1,"IP","gprs.ancel","0.0.0.0",0,0 > AT+CGDCONT=1,"IP","gprs.ancel","0.0.0.0",0,0 > ERROR > --> Bad init string. > --> Cannot get information for serial port. > --> Initializing modem. > --> Sending: ATZ > ATZ > OK > --> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 > ATQ0 V1 E1 S0=0 &C1 &D2 > OK > --> Sending: AT+CGDCONT=1,"IP","gprs.ancel","0.0.0.0",0,0 > AT+CGDCONT=1,"IP","gprs.ancel","0.0.0.0",0,0 > ERROR > --> Bad init string. > --> Cannot get information for serial port. > --> Initializing modem. > --> Sending: ATZ > ATZ > OK > --> Sending: ATQ0 V1 E1 S0=0 &C1 &D2 > ATQ0 V1 E1 S0=0 &C1 &D2 > OK > --> Sending: AT+CGDCONT=1,"IP","gprs.ancel","0.0.0.0",0,0 > AT+CGDCONT=1,"IP","gprs.ancel","0.0.0.0",0,0 > ERROR > --> Bad init string. > -bash-4.1# > ### > # > > > > > One thing I noticed, that the last line of output of ATI for Dan's and my > case, were different (Dan's output said "+GCAP: +CGSM,+FCLASS,+DS", while > my output said "+GCAP: +CGSM,+DS,+ES"). > > > Could that be an issue? > > > Regards, > Ajay > > On Mon, Jun 18, 2012 at 7:42 PM, Andrew Bird (Sphere Systems) < > > a...@spheresystems.co.uk> wrote: > > On Monday 18 June 2012, Ajay Garg wrote: > > > Sorry, > > > > > > forgot ATI. > > > > # > > ## > > > > &
Re: [PATCH] gsm: pass the PPP auth preferences for STATIC and DHCP device use
On Thursday 15 March 2012, Dan Williams wrote:
> On Mon, 2012-03-12 at 20:01 +, Andrew Bird wrote:
> > When using the either DHCP or STATIC IpMethods the modem manager
> > or device itself negotiates the PPP session so we need to pass
> > the authentication preferences through to MM.
> >
> > Notes:
> > 1/ Using a bitfield now that happens to match the Ericsson
> >
> > in the lower orders so that it's far more tidy.
> >
> > 2/ Devices that wish to utilise this should observe the
> >
> > following:
> > If the bitfield doesn't exist in the dict, then MM uses the
> >
> > modem default, if it does, MM tries to fulfill the request. If the
> > modem can only accept one value (Qualcomm-type devices accept only
> > None, PAP or CHAP with AT$QCPDPP) then MM picks the appropriate one
> > from the dict if only one of PAP or CHAP was given, otherwise we
> > default to PAP.
>
> Pushed, thanks; changed the enum entries to be the actual bitfield
> values themselves instead of the bit position though to be a bit
> clearer.
>
> Dan
>
> > Signed-off-by: Andrew Bird
> > ---
> >
> > src/modem-manager/nm-modem-gsm.c | 26 ++
> > 1 files changed, 26 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/modem-manager/nm-modem-gsm.c
> > b/src/modem-manager/nm-modem-gsm.c index 66b7ad9..37edd55 100644
> > --- a/src/modem-manager/nm-modem-gsm.c
> > +++ b/src/modem-manager/nm-modem-gsm.c
> > @@ -62,6 +62,17 @@ typedef enum {
> >
> > MM_MODEM_GSM_ALLOWED_MODE_LAST = MM_MODEM_GSM_ALLOWED_MODE_3G_ONLY
> >
> > } MMModemGsmAllowedMode;
> >
> > +typedef enum {
> > +/* bits 0..4 order match Ericsson device bitmap */
> > +MM_MODEM_GSM_ALLOWED_AUTH_NONE = 0,
> > +MM_MODEM_GSM_ALLOWED_AUTH_PAP = 1,
> > +MM_MODEM_GSM_ALLOWED_AUTH_CHAP = 2,
> > +MM_MODEM_GSM_ALLOWED_AUTH_MSCHAP = 3,
> > +MM_MODEM_GSM_ALLOWED_AUTH_MSCHAPV2 = 4,
> > +MM_MODEM_GSM_ALLOWED_AUTH_EAP = 5,
> > +
> > +MM_MODEM_GSM_ALLOWED_AUTH_LAST = MM_MODEM_GSM_ALLOWED_AUTH_EAP
> > +} MMModemGsmAllowedAuth;
> >
> > G_DEFINE_TYPE (NMModemGsm, nm_modem_gsm, NM_TYPE_MODEM)
> >
> > @@ -326,6 +337,7 @@ static GHashTable *
> >
> > create_connect_properties (NMConnection *connection)
> > {
> >
> > NMSettingGsm *setting;
> >
> > + NMSettingPPP *s_ppp;
> >
> > GHashTable *properties;
> > const char *str;
> >
> > @@ -384,6 +396,20 @@ create_connect_properties (NMConnection *connection)
> >
> > if (nm_setting_gsm_get_home_only (setting))
> >
> > value_hash_add_bool (properties, "home_only", TRUE);
> >
> > + /* For IpMethod == STATIC or DHCP */
> > + s_ppp = nm_connection_get_setting_ppp (connection);
> > + if (s_ppp) {
> > + guint32 auth = 0;
> > + auth |= (nm_setting_ppp_get_noauth (s_ppp) <<
> > MM_MODEM_GSM_ALLOWED_AUTH_NONE); + auth |=
> > ((!nm_setting_ppp_get_refuse_pap (s_ppp)) <<
> > MM_MODEM_GSM_ALLOWED_AUTH_PAP); + auth |=
> > ((!nm_setting_ppp_get_refuse_chap (s_ppp)) <<
> > MM_MODEM_GSM_ALLOWED_AUTH_CHAP); + auth |=
> > ((!nm_setting_ppp_get_refuse_mschap (s_ppp)) <<
> > MM_MODEM_GSM_ALLOWED_AUTH_MSCHAP); +auth |=
> > ((!nm_setting_ppp_get_refuse_mschapv2 (s_ppp)) <<
> > MM_MODEM_GSM_ALLOWED_AUTH_MSCHAPV2); + auth |=
> > ((!nm_setting_ppp_get_refuse_eap (s_ppp)) <<
> > MM_MODEM_GSM_ALLOWED_AUTH_EAP); +
> > + value_hash_add_uint (properties, "allowed_auth", auth);
> > + }
> > +
> >
> > return properties;
> >
> > }
Hi Dan,
Thanks for pushing / refining this, it looks far less ugly now! I also
just sent a patch to add the corresponding definitions to MM.
Andrew
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] gsm: pass the PPP auth preferences for STATIC and DHCP device use
Hi Dan,
On Monday 12 March 2012, Dan Williams wrote:
> On Wed, 2012-03-07 at 12:37 +, Andrew Bird wrote:
> > When using the either DHCP or STATIC IpMethods the modem manager
> > or device itself negotiates the PPP session, so we need to pass
> > the authentication preferences through to MM.
>
> Instead of individual keys, lets use a u32 bitfield here. If the
> bitfield doesn't exist in the dict, then MM uses modem default, if it
> does, MM tries to fulfill the request. If the modem can only accept one
> value (Qualcomm-type devices accept only PAP *or* CHAP with AT$QCPDPP)
> then MM picks the appropriate one from the dict if only one of PAP or
> CHAP was given, otherwise we default to PAP I suppose.
>
> Dan
>
> > Signed-off-by: Andrew Bird
> > ---
> >
> > src/modem-manager/nm-modem-gsm.c | 12
> > 1 files changed, 12 insertions(+), 0 deletions(-)
> >
> > diff --git a/src/modem-manager/nm-modem-gsm.c
> > b/src/modem-manager/nm-modem-gsm.c index 66b7ad9..e2c4cc4 100644
> > --- a/src/modem-manager/nm-modem-gsm.c
> > +++ b/src/modem-manager/nm-modem-gsm.c
> > @@ -326,6 +326,7 @@ static GHashTable *
> >
> > create_connect_properties (NMConnection *connection)
> > {
> >
> > NMSettingGsm *setting;
> >
> > + NMSettingPPP *s_ppp;
> >
> > GHashTable *properties;
> > const char *str;
> >
> > @@ -384,6 +385,17 @@ create_connect_properties (NMConnection *connection)
> >
> > if (nm_setting_gsm_get_home_only (setting))
> >
> > value_hash_add_bool (properties, "home_only", TRUE);
> >
> > + /* For IpMethod STATIC or DHCP */
> > + s_ppp = nm_connection_get_setting_ppp (connection);
> > + if (s_ppp) {
> > + value_hash_add_bool (properties, "noauth",
nm_setting_ppp_get_noauth
> > (s_ppp)); + value_hash_add_bool (properties, "refuse_eap",
> > nm_setting_ppp_get_refuse_eap (s_ppp)); + value_hash_add_bool
> > (properties, "refuse_pap", nm_setting_ppp_get_refuse_pap (s_ppp));
> > + value_hash_add_bool (properties, "refuse_chap",
> > nm_setting_ppp_get_refuse_chap (s_ppp)); + value_hash_add_bool
> > (properties, "refuse_mschap", nm_setting_ppp_get_refuse_mschap (s_ppp));
> > + value_hash_add_bool (properties, "refuse_mschapv2",
> > nm_setting_ppp_get_refuse_mschapv2 (s_ppp)); + }
> > +
> >
> > return properties;
> >
> > }
Is the patch I just sent more along the lines of what you'd expect?
Best regards,
Andrew
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
[PATCH] gsm: pass the PPP auth preferences for STATIC and DHCP device use
Hi all, Currently when GSM devices are connected using Simple.Connect() they have no idea of the user's PPP auth preferences, but either Modem Manager or the device itself has to negotiate the PPP session. The patch just sent does nothing more than pass through those values in the preferences dict, would you consider it or perhaps propose an alternative? Many thanks, Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager port grabbing rework
On Tuesday 14 February 2012, Dan Williams wrote: > On Tue, 2012-02-14 at 13:02 +0100, Aleksander Morgado wrote: > > On 02/13/2012 09:33 PM, Andrew Bird (Sphere Systems) wrote: > > >Will this redesign allow you to change the udev rule assigned names > > > > > > from > > > ID_MM_ZTE_PORT_TYPE_MODEM > > > to > > > ID_MM_PORT_TYPE_MODEM > > > etc? I don't think there can be any clash requiring a different > > > namespace as the items are fully identified by Vendor / Product IDs > > > already. > > > > That is fine for me, but not sure if there is any reason for the vendor > > namespace in port-type tags. Dan? > > I think it's fine too; the question at the time was whether or not > different modems had different port needs. I think for now we have > enough information to standardize the udev port type tags between > vendors. > Excellent news, I guess that's a 0.6 thing only? Are you changing anything else in the udev tagging, say AUX -> AT/QCDM or adding GPS port etc? Thanks, Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager port grabbing rework
On Monday 13 February 2012, Aleksander Morgado wrote: > Hey Dan, > > I really do like the new approach, and I would even include it for > 0.5.x. Some comments below. > > > The core problem was that some devices need to specify a PPP port that's > > *not* the primary port. In these cases the primary port always stays > > open for command and status, while some other port is used for PPP. > > This is different than the current model where the primary port is used > > for command and status until PPP is started, whereupon command and > > status switches to a secondary port. The internal MM model was too > > inflexible here. > > > > In the 'ports' branch, the core change here is to make MM_PORT_TYPE_xxx > > only about types like AT, QCDM, etc. A new flags enum is created for AT > > ports specifically (since these are currently the only ones we care > > about for primary/secondary) called MM_AT_PORT_FLAG_xxx which is what > > plugins now use to give hints to the core about > > primary/secondary/data/etc. > > > > 'ports' now uses the correct port layout on the Huawei E220, and even > > makes newer Sierra devices more functional by using the limited APP > > ports for PPP instead of command and status when connected. > > > > Any review appreciated; it's a pretty big patch and it changes how > > plugins tag ports and interact with the core. If it looks good we'll > > merge to git master for 0.6, and maybe merge it later for 0.5.x. > > One of the main behaviour changes is that now all modem initialization > (e.g. PIN lock checking) is done only after all ports were probed and > organized. I do like that, as we shouldn't run the initialization on a > secondary port even if it was grabbed first. From the current point of > view it shouldn't be a big deal, as we were anyway exporting the modem > only when all ports were probed, but I was hoping to improve the > situation by exporting the modem as soon as we got the first AT port and > the initialization sequence run, so that we could unlock PIN even while > other ports were still being probed. With this new behaviour, that will > not be possible, but no big deal as it could have been anyway an issue > if the primary port was not the one being used for that. I still have > some other ideas to mitigate the problem of spending too much time > probing ports that end up being not AT, which shouldn't be affected by > this new behaviour. > > MMPortType seems redundant now, as we already have > MM_IS_AT_SERIAL_PORT() and MM_IS_QCDM_SERIAL_PORT(). But we can also > keep it and add a MM_PORT_TYPE_NET to be set when creating a MMPort for > net devices; that would simplify organize_ports() as you don't need to > look for net devices based on comparing the subsystem of the port with > "net". I would just add the new MM_PORT_TYPE_NET here, and then > MMPortType would be useful again. > > In mm-manager.c, the call to mm_modem_organize_ports() could have been > done in check_export_modem(), after checking if there are support tasks > pending. Also, I would just allow multiple calls to > mm_modem_organize_ports(), and just return TRUE if they were already > organized. > > In mm_modem_base_organize_ports(), I would just iterate the hashtable > instead of creating a GSList from the hash table and then iterating the > list; and also remove mm_modem_base_get_ports() which seems nowhere else > used. > > In 06-api, and now that we postpone all initialization until we organize > all ports, port_grabbed() and ports_organized() will possibly not be > needed. A first "setup ports" step in the initialization sequence of the > MMBroadbandModem may be enough, which should take care of setting up all > expected unsolicited message handlers (either in primary or in both), > before any command is sent. > > Cheers! Hi Aleksander, Dan, Will this redesign allow you to change the udev rule assigned names from ID_MM_ZTE_PORT_TYPE_MODEM to ID_MM_PORT_TYPE_MODEM etc? I don't think there can be any clash requiring a different namespace as the items are fully identified by Vendor / Product IDs already. It would be really useful for reuse in Wader as we use these before plugin selection and if we have info for modem / aux port we don't need to probe. It seems a shame not to share each others' modem interface description data, what do you think? Thanks, Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Add GetMsIsdn method to return the phone number
On Monday 23 January 2012, Dan Williams wrote: > On Sat, 2012-01-21 at 21:28 +0100, Aleksander Morgado wrote: > > >>> On Thu, 2011-06-30 at 18:18 -0400, Eric Shienbrood wrote: > > I can look at doing that. What should we call it? I think MSISDN is > > a GSM term. How does GetPhoneNumber() sound? > > >>> > > >>> Hm, old message. Yes, that method sounds fine. > > >> > > >> Where did this end up? > > >> > > >> Also, AT+CNUM may report a list of numbers, not just one. > > >> > > >> For the 0.6 API I was going to add it as a "PhoneNumbers" property > > >> (signature 'as') in the Modem interface. > > >> > > >> Anyway, in my own tests, it really didn't report any number, as some > > >> others noticed. :-/ > > > > > > Well IMHO if you are going to get the values from +CNUM, you should > > > also allow setting of it, would you agree? Essentially it's a list of > > > SIM contacts, other than that it having a dedicated AT command to > > > get/set as it's in a different phonebook, there's not really anything > > > special about it. > > > > Given that we have a "Contacts" interface in the 0.6 API, maybe we could > > handle own numbers, if retrievable, as any other number in the different > > available phonebooks. > > CDMA devices always have a command (either AT or QCDM/DIAG) to return > the MDN since it's stored in the phone and not on a SIM (unless you have > a RUIM of course, then it's on the RUIM I think). For the GSM devices, > it's often programmed as phonebook #0 but that's easy to change, delete, > or screw up. So I think there's value in exposing the current phone > number where we can get it, if we can't then we should probably leave it > blank. > That seems a reasonable approach to me as long as on GSM you don't return a result based on a query to +CNUM. The +CNUM approach to GetOwnNumber is flawed but if you really do wish to use it, I think you need to be able to read and write the values, so that if it's wrong you can at least correct the entry. ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Add GetMsIsdn method to return the phone number
On Saturday 21 January 2012, Aleksander Morgado wrote: > On 07/31/2011 12:52 AM, Dan Williams wrote: > > On Thu, 2011-06-30 at 18:18 -0400, Eric Shienbrood wrote: > >> I can look at doing that. What should we call it? I think MSISDN is a > >> GSM term. How does GetPhoneNumber() sound? > > > > Hm, old message. Yes, that method sounds fine. > > Where did this end up? > > Also, AT+CNUM may report a list of numbers, not just one. > > For the 0.6 API I was going to add it as a "PhoneNumbers" property > (signature 'as') in the Modem interface. > > Anyway, in my own tests, it really didn't report any number, as some > others noticed. :-/ Well IMHO if you are going to get the values from +CNUM, you should also allow setting of it, would you agree? Essentially it's a list of SIM contacts, other than that it having a dedicated AT command to get/set as it's in a different phonebook, there's not really anything special about it. ___ 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 David,
So is the harddisk device that complains the storage device on the 3G
stick itself, or a different device altogether? If it's the same device I'd
suspect that the 3G stick is resetting itself and momentarily disappearing
from the system.
Best regards,
Andrew
On Thursday 20 October 2011, David Pfeffer wrote:
> (This thought was furthered by the fact that the USB modem in question is
> one that modeswitches, so it does have internal storage. Am I wrong in this
> assumption?)
>
> On Thu, Oct 20, 2011 at 8:54 AM, David Pfeffer
>
> wrote:
> > The hard disk complaint actually only occurs at the same time as a
> > network drop. I assumed they were somehow related to the 3G issue,
> > because this occurs on several machines, each with identical hardware
> > and disk image.
> >
> >
> > On Thu, Oct 20, 2011 at 8:53 AM, Andrew Bird (Sphere Systems) <
> >
> > a...@spheresystems.co.uk> wrote:
> >> Hi David,
> >>
> >>I'd be looking at why the hard disk is complaining first, the
> >>
> >> connection
> >> problem may be an unlikely consequence of failing hardware.
> >>
> >> Best regards,
> >>
> >>
> >> Andrew
> >>
> >> On Thursday 20 October 2011, David Pfeffer wrote:
> >> > >> Oct 13 22:25:26 tracker kernel: [12441.840088] ata1.00: exception
> >>
> >> Emask
> >>
> >> > >> 0x0 SAct 0x0 SErr 0x0 action 0x6 Oct 13 22:25:26 tracker kernel:
> >> > >> [12441.846744] ata1.00: BMDMA stat 0x66 Oct 13 22:25:26 tracker
> >>
> >> kernel:
> >> > >> [12441.850446] ata1.00: failed command: WRITE DMA Oct 13 22:25:26
> >> > >> tracker kernel: [12441.855020] ata1.00: cmd
> >> > >> ca/00:02:c4:fb:5b/00:00:00:00:00/e0 tag 0 dma 1024 out Oct 13
> >>
> >> 22:25:26
> >>
> >> > >> tracker kernel: [12441.855024] res
> >> > >> 51/84:00:c4:fb:5b/00:00:00:00:00/e0 Emask 0x30 (host bus error) Oct
> >>
> >> 13
> >>
> >> > >> 22:25:26 tracker kernel: [12441.870623] ata1.00: status: { DRDY ERR
> >> > >> } Oct 13 22:25:26 tracker kernel: [12441.874708] ata1.00: error: {
> >> > >> ICRC ABRT } Oct 13 22:25:26 tracker kernel: [12441.878820] ata1:
> >> > >> soft resetting link
___
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 David,
I'd be looking at why the hard disk is complaining first, the
connection
problem may be an unlikely consequence of failing hardware.
Best regards,
Andrew
On Thursday 20 October 2011, David Pfeffer wrote:
> >> Oct 13 22:25:26 tracker kernel: [12441.840088] ata1.00: exception Emask
> >> 0x0 SAct 0x0 SErr 0x0 action 0x6 Oct 13 22:25:26 tracker kernel:
> >> [12441.846744] ata1.00: BMDMA stat 0x66 Oct 13 22:25:26 tracker kernel:
> >> [12441.850446] ata1.00: failed command: WRITE DMA Oct 13 22:25:26
> >> tracker kernel: [12441.855020] ata1.00: cmd
> >> ca/00:02:c4:fb:5b/00:00:00:00:00/e0 tag 0 dma 1024 out Oct 13 22:25:26
> >> tracker kernel: [12441.855024] res
> >> 51/84:00:c4:fb:5b/00:00:00:00:00/e0 Emask 0x30 (host bus error) Oct 13
> >> 22:25:26 tracker kernel: [12441.870623] ata1.00: status: { DRDY ERR }
> >> Oct 13 22:25:26 tracker kernel: [12441.874708] ata1.00: error: { ICRC
> >> ABRT } Oct 13 22:25:26 tracker kernel: [12441.878820] ata1: soft
> >> resetting link
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: PATCH] sms_decode_text(): Sanitize 8-bit data so that it is UTF8-clean.
On Tuesday 27 September 2011, Dan Williams wrote: > On Mon, 2011-09-26 at 18:29 -0400, Nathan Williams wrote: > > This keeps ModemManager from crashing deep in the DBus libraries when > > a SMS Get() or List() DBus operation finds a message that isn't valid > > UTF-8 and/or has embedded NUL characters. > > > > I'll be putting up a separate patch as a proposal for how to avoid > > this problem in the new API. > > Sounds fine; though in general we know the encoding that the message > comes in with, and we know we need to convert to UTF-8 for D-Bus (and > really, everything should be UTF-8 at the boundaries, it would be just > horrid to expose any charset encoding details to clients and I don't > think we have to). So we should be able to convert to UTF-8 without any > real loss of fidelity when reading the message from the modem, and we > should be able to convert from UTF-8 to a suitable charset (whatever > we've selected from CSCS) when sending messages too. > > In what cases would we want to send or receive essentially binary data > via SMS? AFAIK most of these cases show up as base64 or hex-string SMS > if they aren't intended for human consumption. > > In any case, applied, thanks! > > Dan > > > - Nathan > > > > ___ > > 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 Hi Dan, Here's a case you might want to consider. Sometimes mobile networks send WAP pushes to signify that an MMS is ready for retrieval, or send the user revised phone settings etc. Now we can't currently do much with those but they are binary and can contain embedded \x00 which Dbus really won't transfer in a string. But it's no good just ignoring them and not showing the client the message because they take up valuable SIM based SMS slots, if we did then the user would not know of their existence and eventually the SIM would silently fill. I had one WAP push last week that spanned 4 SMS slots. On Wader we worked around this problem by Zipping and Base64 encoding the message before sending over Dbus [0] [1], but I couldn't think of a elegant solution without changing the spec. If you come up with a better solution please let me know and we can revise what we have. [0]:https://forge.betavine.net/plugins/scmsvn/viewcvs.php/trunk/src/core/wader/common/mal.py?root=bcm&rev=1210&r1=1193&r2=1210 [1]:https://forge.betavine.net/plugins/scmsvn/viewcvs.php/trunk/src/core/wader/common/encoding.py?root=bcm&rev=1210&r1=1194&r2=1210 Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: New USB 3G modem
On Sunday 11 September 2011, pera...@portugalmail.pt wrote: > I don't see the option module load first. Just to make sure do a reboot, > then > > su - > > modprobe -a option > echo "0685 7000" > /sys/bus/usb-serial/drivers/option1/new_id > ls -l /dev/ttyUSB* # see if you have tty devices > > ==> > > [root@server yossi]# modprobe -s > Message from syslogd@server at Sep 11 18:52:01 ... > kernel:[ 211.456887] Oops: [#1] SMP > > Message from syslogd@server at Sep 11 18:52:01 ... > kernel:[ 211.456890] last sysfs file: > /sys/devices/pci:00/:00:1d.0/usb5/5-1/5-1:1.0/host6/target6:0:0/6:0 > :0:0/evt_media_change > > Message from syslogd@server at Sep 11 18:52:01 ... > kernel:[ 211.456972] Process udisks-daemon (pid: 3212, ti=f0be2000 > task=f0bb4bc0 task.ti=f0be2000) > > Message from syslogd@server at Sep 11 18:52:01 ... > kernel:[ 211.456974] Stack: > > Message from syslogd@server at Sep 11 18:52:01 ... > kernel:[ 211.456996] Call Trace: > > Message from syslogd@server at Sep 11 18:52:01 ... > kernel:[ 211.457017] Code: Bad EIP value. > > Message from syslogd@server at Sep 11 18:52:01 ... > kernel:[ 211.457017] EIP: [<67726174>] 0x67726174 SS:ESP 0068:f0be3b78 > > Message from syslogd@server at Sep 11 18:52:01 ... > kernel:[ 211.457017] CR2: 67726174 > a ^C > [root@server yossi]# modprobe -a option > [root@server yossi]# echo "0685 7000" > > /sys/bus/usb-serial/drivers/option1/new_id > [root@server yossi]# ls -l /dev/ttyUSB* > crw-rw. 1 root dialout 188, 0 Sep 11 18:52 /dev/ttyUSB0 > crw-rw. 1 root dialout 188, 1 Sep 11 18:52 /dev/ttyUSB1 > crw-rw. 1 root dialout 188, 2 Sep 11 18:52 /dev/ttyUSB2 > crw-rw. 1 root dialout 188, 3 Sep 11 18:52 /dev/ttyUSB3 > [root@server yossi]# ls -l /dev/ttyUSB* > crw-rw. 1 root dialout 188, 0 Sep 11 18:52 /dev/ttyUSB0 > crw-rw. 1 root dialout 188, 1 Sep 11 18:52 /dev/ttyUSB1 > crw-rw. 1 root dialout 188, 2 Sep 11 18:52 /dev/ttyUSB2 > crw-rw. 1 root dialout 188, 3 Sep 11 18:52 /dev/ttyUSB3 > [root@server yossi]# screen /dev/ttyUSB0 > > Manufacturer: HSDPA USB Modem > Model: 209 > Revision: HSDPA_6281_V002 1 [May 30 2007 11:00:00] > IMEI: > +GCAP: +CGSM,+DS,+ES > > OK 1/ This looks good, now repeat for other devices, to determine which is the auxilary port that can be used to command / retrieve status whilst the data connection is up. 2/ You'll now need some help from an MM guy to figure out which plugin to use and how to configure it. > > > NOTE: I am not sure if the kernel OOPS was caused by insertion of this > device. Maybe, looks to be connected to USB storage and your modem composite device does have one USB storage interface > > Perazim > ___ > 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: New USB 3G modem
On Sunday 11 September 2011, pera...@portugalmail.pt wrote: > Last part of dmesg: > > [369755.015037] usb 5-1: new full speed USB device using uhci_hcd and > address 9 > [369755.168183] usb 5-1: New USB device found, idVendor=0685, > idProduct=7000 [369755.168189] usb 5-1: New USB device strings: Mfr=1, > Product=2, SerialNumber=3 > [369755.168193] usb 5-1: Product: HSDPA USB Modem > [369755.168195] usb 5-1: Manufacturer: HSDPA USB Modem > [369755.168198] usb 5-1: SerialNumber: Data Interface > [369755.199686] scsi18 : usb-storage 5-1:1.0 > [369756.207213] scsi 18:0:0:0: CD-ROMHSDPACDROM > Storage2.31 PQ: 0 ANSI: 2 > [369756.210209] scsi 18:0:0:1: Direct-Access HSDPAMMC Storage > 2.31 PQ: 0 ANSI: 2 > [369756.263198] sr2: scsi-1 drive > [369756.264481] sr 18:0:0:0: Attached scsi CD-ROM sr2 > [369756.264624] sr 18:0:0:0: Attached scsi generic sg3 type 5 > [369756.269298] sd 18:0:0:1: Attached scsi generic sg4 type 0 > [369756.313203] sd 18:0:0:1: [sdc] Attached SCSI removable disk > [root@server yossi]# > > > last part of /var/log/messages: > > Sep 11 17:45:53 server kernel: [370239.681038] usb 5-1: new full speed > USB device using uhci_hcd and address 11 > Sep 11 17:45:54 server kernel: [370239.833081] usb 5-1: New USB device > found, idVendor=0685, idProduct=7000 > Sep 11 17:45:54 server kernel: [370239.833087] usb 5-1: New USB device > strings: Mfr=1, Product=2, SerialNumber=3 > Sep 11 17:45:54 server kernel: [370239.833091] usb 5-1: Product: > HSDPA USB Modem > Sep 11 17:45:54 server kernel: [370239.833094] usb 5-1: Manufacturer: > HSDPA USB Modem > Sep 11 17:45:54 server kernel: [370239.833096] usb 5-1: SerialNumber: > Data Interface > Sep 11 17:45:54 server kernel: [370239.837721] scsi20 : usb-storage 5-1:1.0 > Sep 11 17:45:54 server mtp-probe: checking bus 5, device 11: > "/sys/devices/pci:00/:00:1d.0/usb5/5-1" > Sep 11 17:45:54 server mtp-probe: bus: 5, device: 11 was not an MTP device > Sep 11 17:45:55 server kernel: [370240.849086] scsi 20:0:0:0: CD-ROM > HSDPACDROM Storage2.31 PQ: 0 ANSI: 2 > Sep 11 17:45:55 server kernel: [370240.854709] scsi 20:0:0:1: > Direct-Access HSDPAMMC Storage 2.31 PQ: 0 ANSI: 2 > Sep 11 17:45:55 server kernel: [370240.887082] sr2: scsi-1 drive > Sep 11 17:45:55 server kernel: [370240.887462] sr 20:0:0:0: Attached > scsi generic sg3 type 5 > Sep 11 17:45:55 server kernel: [370240.887715] sd 20:0:0:1: Attached > scsi generic sg4 type 0 > Sep 11 17:45:55 server kernel: [370240.936791] sd 20:0:0:1: [sdc] > Attached SCSI removable disk > [root@server yossi]# > I don't see the option module load first. Just to make sure do a reboot, then su - modprobe -a option echo "0685 7000" > /sys/bus/usb-serial/drivers/option1/new_id ls -l /dev/ttyUSB* # see if you have tty devices ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: New USB 3G modem
On Sunday 11 September 2011, pera...@portugalmail.pt wrote: > Yes a typo. Here it is again: > > [root@server yossi]# echo "0685 7000" > > /sys/bus/usb-serial/drivers/option1/new_id > [root@server yossi]# ls -l /dev/ttyUSB* > ls: cannot access /dev/ttyUSB*: No such file or directory Not sure why the option driver ignored those interfaces, perhaps dmesg, /var/log/messages or /var/log/syslog have some clues? > [root@server yossi]# > > > Perazim > > ___ > 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: New USB 3G modem
Hi Perazim, See below. On Sunday 11 September 2011, pera...@portugalmail.pt wrote: > Here are the results: > > On Thu, 2011-09-08 at 21:40 +0100, Andrew Bird (Sphere Systems) wrote: > Hi Perazim, > > > There's a few things you can do to get started: > > try doing: > > lsusb -v -d 0685:7000 # paste the log here > > --> > [yossi@server ~]$ lsusb -v -d 0685:7000 > > Bus 005 Device 005: ID 0685:7000 > Device Descriptor: >bLength18 >bDescriptorType 1 >bcdUSB 1.10 >bDeviceClass0 (Defined at Interface level) >bDeviceSubClass 0 >bDeviceProtocol 0 >bMaxPacketSize064 >idVendor 0x0685 >idProduct 0x7000 >bcdDevice0.00 >iManufacturer 1 >iProduct2 >iSerial 3 >bNumConfigurations 1 >Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 131 > bNumInterfaces 5 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xa0 >(Bus Powered) >Remote Wakeup > MaxPower 500mA > Interface Descriptor: >bLength 9 >bDescriptorType 4 >bInterfaceNumber0 >bAlternateSetting 0 >bNumEndpoints 3 >bInterfaceClass 255 Vendor Specific Class >bInterfaceSubClass255 Vendor Specific Subclass >bInterfaceProtocol255 Vendor Specific Protocol >iInterface 3 >Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes3 >Transfer TypeInterrupt >Synch Type None >Usage Type Data > wMaxPacketSize 0x0010 1x 16 bytes > bInterval 128 >Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x82 EP 2 IN > bmAttributes2 >Transfer TypeBulk >Synch Type None >Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 >Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes2 >Transfer TypeBulk >Synch Type None >Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Interface Descriptor: >bLength 9 >bDescriptorType 4 >bInterfaceNumber1 >bAlternateSetting 0 >bNumEndpoints 2 >bInterfaceClass 255 Vendor Specific Class >bInterfaceSubClass255 Vendor Specific Subclass >bInterfaceProtocol255 Vendor Specific Protocol >iInterface 3 >Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x84 EP 4 IN > bmAttributes2 >Transfer TypeBulk >Synch Type None >Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 >Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x04 EP 4 OUT > bmAttributes2 >Transfer TypeBulk >Synch Type None >Usage Type Data > wMaxPacketSize 0x0040 1x 64 bytes > bInterval 0 > Interface Descriptor: >bLength 9 >bDescriptorType 4 >bInterfaceNumber2 >bAlternateSetting 0 >bNumEndpoints 2 >bInterfaceClass 255 Vendor Specific Class >bInterfaceSubClass255 Vendor Specific Subclass >bInterfaceProtocol255 Vendor Specific Protocol >iInterface 3 >Endpoint Descriptor: > bLength 7 > bDescrip
Re: New USB 3G modem
Hi Perazim, There's a few things you can do to get started: try doing: lsusb -v -d 0685:7000 # paste the log here sudo su - # to become root, then modprobe -a option echo "0685 7000" > /sys/bus/usb-serial/drivers/option1/new_id ls -l /dev/ttyUSB* # see if you have tty devices if you have then try using 'screen' to talk to them in turn (you might have to install it) screen /dev/ttyUSB0 ATI3 Ctrl-A k y screen /dev/ttyUSB1 ATI3 Ctrl-A k y and repeat until finished, note which ports respond to ATI3, and which don't Hope that helps, Andrew On Thursday 08 September 2011, pera...@portugalmail.pt wrote: > Dan, I am also working with the openWRT router project to get this > modem working. > > After posting to that forum, someone came forward regarding this modem. > They stated that usb_modeswitch was NOT used for this device and the > modem was to be found on /dev/ttyUSB0. I have noticed that on windows > that the drivers are installed everytime this device is plugged and > this seems to confirm the non-use of usb_modeswitch. Also the is no > evidence of usb_modeswitch in the syslog. > > On openWRT I was able to get this to connect once and pass traffic but > it seems that I messed something up later. > > Shall I make a copy of the fake driver CD for you now? > > Thanks, > > Perazim > > On Fri, 2011-09-02 at 15:53 +0100, pera...@portugalmail.pt wrote: > > I have a "generic" USB modem labeled "HSDPA 3.5G Wireless Modem" bought > > from Deal Extreme in Hong Kong. > > > > It works on Windows XP and installs its own drivers when plugged the > > first time. > > > > When plugged to Fedora 14, I see a CDROM detected and a USB storage > > device if a microSDHC is plugged into the slot on the modem. I do not > > see usb_modeswitch run and NetworkManager does not see this modem. > > usb_modeswitch needs the right logic to flip the device to modem mode, > without that there's no change ModemManager can detect the modem, > because it's not a modem yet. After that, we may need to implement > support for this device's specific quirks. I usually ask users to > zip/gzip up the contents of the "fake" driver CD and email it to me so > that I can inspect the drivers and the connection manager and determine > what AT commands (and thus what firmware variant) the device uses. Then > we can implement more than basic support for the device. > > > Using lsusb I see: ID 0685:7000 with no description whatever. There is > > no file by this name in /etc/usb_modeswitch.d/ > > > > How do I add this modem to the appropriate tables so that it is > > detected? > > If there is no entry for that device in usb_modeswitch's /etc directory, > then you'll need to communicate first with the usb_modeswitch project > and determine the sequence to flip the device to modem mode. That might > include installing a USB sniffer in Windows and sniffing the command > sequences that the driver uses to tell the device to enter modem mode. > The usb_modeswitch project is pretty good about helping people through > that process. Once that's done, we can proceed with inspecting the > actual modem and determining what we need to do to get it connecting to > the network. > > 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 http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Main event loop in networkmanager.
On Wednesday 03 August 2011, Anders Gnistrup wrote:
> Hi
>
> FIrst post to this maillist.
>
> My problem is that I need to receive signal from the networkmanager.
> This is done using connect_to_signal and it seems quite easy.
> But when testing I get the error message -> create a glib event loop.
> And thats My problem. I already have a loop.
>
> The short description of my application is a interface able to configure
> some wireless network interfaces from a remote host using a XMLrpc from
> twisted. (There is no screen on target platform)
>
> the application loop is a XMLrpc interface (reactor), where several rpc is
> available. Some of these graps information from the networkmanager dbus
> interface. This is OK, because it is a synchronous API. But when adding a
> new connection (using addConnection), the succes/fail is a signal
> (networkmanager version 0.84). So I need to create a asynchronous loop. (I
> know this is changed in networkmanager version 0.9)
>
> So I have two solutions:
> 1) Tell the networkmanger signal to use my loop. (seems impossible, if
> please tell me how) 2) Create a second thread and start a loop using:
>from dbus.mainloop.glib import DBusGMainLoop
>DBusGMainLoop(set_as_default=True)
>additional code ..
>loop = gobject.MainLoop()
>loop.run
>
> The second solution creates new problems. I need to make data thread safe,
> and there is no need for two thread. It's only signals!
>
> I have searched the net for a solution for (1), but I can't find any
> (2) is possible but does not seems "right"
>
Hi Anders,
Can't you select the glib loop in twisted? Here's a test program I just
wrote that works for me.
Hope it helps,
Andrew
import dbus
from dbus.mainloop.glib import DBusGMainLoop
from twisted.application.service import Application, Service
from twisted.python import log
NM_SERVICE = 'org.freedesktop.NetworkManager'
NM_OBJPATH = '/org/freedesktop/NetworkManager'
NM_INTFACE = NM_SERVICE
loop = DBusGMainLoop(set_as_default=True)
bus = dbus.SystemBus(mainloop=loop)
obj = bus.get_object(NM_SERVICE, NM_OBJPATH)
class MyService(Service):
def method_cb(self, arg):
print "method returned %s" % str(arg)
def signal_cb(self, arg):
print "signal fired with %s" % str(arg)
def startService(self):
print "startService"
obj.GetDevices(dbus_interface=NM_INTFACE,
reply_handler=self.method_cb,
error_handler=log.err)
obj.connect_to_signal('DeviceAdded', self.signal_cb,
dbus_interface=NM_INTFACE)
service = MyService()
application = Application('Mytest')
service.setServiceParent(application)
# start as follows
# /usr/bin/twistd --nodaemon --python=mytest.py --reactor=glib2
2011-08-03 09:55:03+0100 [-] Log opened.
2011-08-03 09:55:03+0100 [-] twistd 10.2.0 (/usr/bin/python 2.7.1) starting
up.
2011-08-03 09:55:03+0100 [-] reactor class:
twisted.internet.glib2reactor.Glib2Reactor.
2011-08-03 09:55:03+0100 [-] startService
2011-08-03 09:55:04+0100 [-] method returned
dbus.Array([dbus.ObjectPath('/org/freedesktop/NetworkManager/Devices/0')],
signature=dbus.Signature('o'))
2011-08-03 09:55:34+0100 [-] signal fired with
/org/freedesktop/NetworkManager/Devices/1
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: The meaning of Enable in MM/NM world of mobile broadband?
On Monday 01 August 2011, Dan Williams wrote: > On Mon, 2011-08-01 at 09:26 +0100, Andrew Bird (Sphere Systems) wrote: > > Hi all, > > > > I'm trying to understand the meaning of 'Enable Mobile Broadband' from > > > > the NM applet menu. I have a few questions: > > > > Is the NM applet Enable item just a direct control of the WWAN devices's > > radio function? > > Not necessarily. Enable means "power up the modem and initialize it so > that it is able to be connected at some point in the future." Before > the modem is enabled, it may not be powered up, it may not be registered > with a network, it may not send/receive SMS, etc. Basically, before > anything can be done with the modem beyond detecting that the modem > exists and whether the modem needs a PIN, the modem must be enabled. OK thanks, I understand now > > a) if so, what happens at startup, is the modem's radio functionality > > > > checked and the Enable checkitem state set accordingly, or is the modem's > > radio forced into some default/remembered NM/MM derived state? > > ModemManager starts all modems in disabled state, and NetworkManager > should not be automatically enabling modems; that's left to the user > because at the moment, most people won't be using their modems full-time > and probably don't want them to suck down power when they aren't > actually being used. It's up to the connection manager (NM or something > else) to determine whether or not to enable the device, and right now NM > requires the user to explicitly make that decision. If you're using an > embedded platform, whatever tells MM to connect probably wants to enable > the modem when that thing starts. OK thanks, I understand now > > > b) if so, what happens if we have two modems (perhaps one is embedded > > and > > > > the other external) and their radios are in different states, or need to > > be? > > MM allows both modems to have different state. With NetworkManager > however, because there isn't a separate rfkill for each WWAN device, > there's a single composite state just like there is for WiFi. If any > modem is disabled, the checkbox (and NM's "WwanEnabled" state) will be > FALSE. If the user checks the box (or something sets WwanEnabled to > TRUE) NM will attempt to call MM's Enable() method for all devices. > > I'm somewhat unclear on use-cases where multiple modems would be > connected to a system under normal conditions where both wouldn't be > able to be enabled at the same time. Thoughts? Yeah it was a contrived example, and the only reason I can think of is power saving on the unused modem. > > > c) if so, does MM prefer to use +CFUN=0 or +CFUN=4 to Disable the > > modem? > > That's left to the modem plugin. CFUN=0 often has the unfortunate > side-effect of actually powering off the device so it's not used on many > devices. CFUN=4 is unfortunately unimplemented on a wide range of > devices, but if it is available we should be using it. Patches for that > would be accepted; we can check CFUN=? on startup and then store the > returned list of available modes and use that to determine whether to > set CFUN=4 on disable. > > > d) if not, what function does Enable on the applet perform? > > Not sure what you're asking here... You answered it in part (a) > > > e) if not, is there another way to turn off the radio, perhaps an > > Aircraft > > > > Mode? > > That is current calling Enable(FALSE) for the modem on the MM DBus > interface, which is supposed to place the modem into low-power mode. > RFKILL/Aircraft mode isn't what we want to do here, because that is > easily confused with the physical button that many laptops have, which > often just disconnects the device from the USB bus completely. Which > means MM can't see it anymore because it doesn't exist. So I think just > having the device disabled via the equivalent of CFUN=4 is sufficient, > and leave actual airplane mode/rfkill to the BIOS, if any. > > Dan There is one thing I noticed though after doing a few tests with NM on Ubuntu Natty. If after first insertion of a device, the user dismisses the PIN entry dialog without authenticating. Then he subsequently uses the nm-applet to enable mobile broadband but it doesn't prompt again for PIN. Which means that to see registration/sig strength/networks etc, the user must first attempt a connection in order to get prompted for PIN and auth, or he must pull the stick and reinsert. Which may be expected behaviour I guess, but a little awkward. Thanks for taking the trouble to explain it all Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
The meaning of Enable in MM/NM world of mobile broadband?
Hi all, I'm trying to understand the meaning of 'Enable Mobile Broadband' from the NM applet menu. I have a few questions: Is the NM applet Enable item just a direct control of the WWAN devices's radio function? a) if so, what happens at startup, is the modem's radio functionality checked and the Enable checkitem state set accordingly, or is the modem's radio forced into some default/remembered NM/MM derived state? b) if so, what happens if we have two modems (perhaps one is embedded and the other external) and their radios are in different states, or need to be? c) if so, does MM prefer to use +CFUN=0 or +CFUN=4 to Disable the modem? d) if not, what function does Enable on the applet perform? e) if not, is there another way to turn off the radio, perhaps an Aircraft Mode? Thanks, Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
The +COPS? values in TS27007 have been enhanced, new MM ACCESS TECH constant needed?
Hi all, I saw that some mobile broadband modems are starting to support the latest version of TS27.007 with regard to AT+COPS?. So five more values for bearer type are now possible and the MM spec 0.5 covers all but LTE. I know there is work in progress to redesign the MM spec for 0.6, but would it be possible to add another constant to MM 0.5 spec in the interim, please? 3GPP TS 27.007 V10.4.0, +COPS : integer type; access technology selected 0 GSM 1 GSM Compact 2 UTRAN 3 GSM w/EGPRS 4 UTRAN w/HSDPA 5 UTRAN w/HSUPA 6 UTRAN w/HSDPA and HSUPA 7 E-UTRAN I'll send a patch for same. Regards, Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/4] DTD changes for mms, prepaid, wap
Hi Marcel, On Friday 22 July 2011, Marcel Holtmann wrote: > Hi Andrew, > > > > > diff --git a/serviceproviders.2.dtd b/serviceproviders.2.dtd > > > > index d150a99..a0c5a31 100644 > > > > --- a/serviceproviders.2.dtd > > > > +++ b/serviceproviders.2.dtd > > > > @@ -18,6 +18,7 @@ > > > > > > > > password?, > > > > dns*)> > > > > > > > > > > > > > > > > + > > > > > > I would propose "internet", "mms" and "wap" as types. That is really > > > what we care about. What can you do with this context. > > > > > > The only tricky part is that in some cases some providers use the same > > > APN for Internet access and MMS. We could just list the context twice > > > in that case or have a list of types per context. > > > > > > Android seems to use comma separated string for this. Where there also > > > have some custom defined types like special Assisted GPS contexts. That > > > seems to be Nokia specific detail in some countries with a total > > > different billing concept. > > > > > > In addition to the actual type of the APN, I like to see an attribute > > > for the "plan". So we can differentiate between "broadband", "prepaid" > > > and others. > > > > How would you describe the association between MMS and internet APNs? For > > example in the UK Vodafone has the following APN usage: > > > > Contract Plan (MMS retrieval bandwidth is zero rated) > > > > internet access is via 'internet' APN > > MMS retrieval is via 'wap.vodafone.co.uk' APN > > > > Prepay Plan (MMS retrieval bandwidth is charged too) > > === > > internet access is via 'pp.internet' APN > > MMS retrieval is via 'pp.internet' APN > > > > So it's important to select the correct APN for your plan even when > > retrieving MMS as either it won't function with your SIM, or you'll get > > charged for bandwidth when you shouldn't > > that is exactly my point in separating these: > > wap.vodafone.co.uk ==> type="mms" plan="contract" > pp.internet==> type="mms" plan="prepaid" > > So you can define a type with different plan details. > In your example is 'contract' a well known type or a unique identifier of another APN? So would that handle the situation where there are two prepaid plans and each has a respective MMS APN? Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH 1/4] DTD changes for mms, prepaid, wap
Hi Marcel, On Friday 22 July 2011, Marcel Holtmann wrote: > Hi Oleg, > > > diff --git a/serviceproviders.2.dtd b/serviceproviders.2.dtd > > index d150a99..a0c5a31 100644 > > --- a/serviceproviders.2.dtd > > +++ b/serviceproviders.2.dtd > > @@ -18,6 +18,7 @@ > > > > password?, > > dns*)> > > > > > > > > + > > I would propose "internet", "mms" and "wap" as types. That is really > what we care about. What can you do with this context. > > The only tricky part is that in some cases some providers use the same > APN for Internet access and MMS. We could just list the context twice in > that case or have a list of types per context. > > Android seems to use comma separated string for this. Where there also > have some custom defined types like special Assisted GPS contexts. That > seems to be Nokia specific detail in some countries with a total > different billing concept. > > In addition to the actual type of the APN, I like to see an attribute > for the "plan". So we can differentiate between "broadband", "prepaid" > and others. > How would you describe the association between MMS and internet APNs? For example in the UK Vodafone has the following APN usage: Contract Plan (MMS retrieval bandwidth is zero rated) internet access is via 'internet' APN MMS retrieval is via 'wap.vodafone.co.uk' APN Prepay Plan (MMS retrieval bandwidth is charged too) === internet access is via 'pp.internet' APN MMS retrieval is via 'pp.internet' APN So it's important to select the correct APN for your plan even when retrieving MMS as either it won't function with your SIM, or you'll get charged for bandwidth when you shouldn't Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Add GetMsIsdn method to return the phone number
Hi Eric,
On Wednesday 29 June 2011, Eric Shienbrood wrote:
> Using +CNUM is a "best effort" ("good enough effort"?) attempt to retrieve
> the MSISDN. I'd say it should be left to layers above ModemManager to try
> operator-specific methods if necessary, since ModemManager doesn't (and
> shouldn't) have knowledge of operator-specific information.
>
> Eric
>
> On Wed, Jun 29, 2011 at 12:00 PM, Andrew Bird (Sphere Systems) <
>
> a...@spheresystems.co.uk> wrote:
> > On Wednesday 29 June 2011, Eric Shienbrood wrote:
> > > Adds a GetMsIsdn method on the
> >
> > org.freedesktop.ModemManager.Modem.Gsm.Card
> >
> > > interface.
> > >
> > > Eric
> >
> > I like the look of this, but what methods will you use to derive the
> > value? As
> > far as I know the SIM might have the value stored (retrieved via +CNUM or
> > +CRSM?) but otherwise isn't getting the value only possible via operator
> > specific USSD or SMS methods?
> >
> >
> > Andrew
Since this +CNUM or equivalent is reading from a special 'number' address book
location on the SIM, shouldn't you have the corresponding write method too?
That way if an upper layer can derive the MSISDN in some way, it could be
stored on the SIM for easy retrieval later by any application using your read
method.
Andrew
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Add GetMsIsdn method to return the phone number
Hi Marcel, On Wednesday 29 June 2011, Marcel Holtmann wrote: > Hi Andrew, > > > > Adds a GetMsIsdn method on the > > > org.freedesktop.ModemManager.Modem.Gsm.Card interface. > > > > > > Eric > > > > I like the look of this, but what methods will you use to derive the > > value? As far as I know the SIM might have the value stored (retrieved > > via +CNUM or +CRSM?) but otherwise isn't getting the value only possible > > via operator specific USSD or SMS methods? > > the number of operators that provision this properly on the SIM card > they hand out is really limited. I only know of a view and they only do > that for the voice customers. For the data sticks, they do not care. > > In most cases this is not provisioned properly. The best you can hope > for is that the an operator updates these values via SIM Toolkit or some > sort of network initiated USSD. Otherwise you are really out of luck > here until you manually modify the SIM card. > > Regards > > Marcel That aligns with my experience also, I'd wondered if I'd been missing a trick to get it from the network in an operator agnostic way. Thanks, Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Add GetMsIsdn method to return the phone number
On Wednesday 29 June 2011, Eric Shienbrood wrote: > Adds a GetMsIsdn method on the org.freedesktop.ModemManager.Modem.Gsm.Card > interface. > > Eric I like the look of this, but what methods will you use to derive the value? As far as I know the SIM might have the value stored (retrieved via +CNUM or +CRSM?) but otherwise isn't getting the value only possible via operator specific USSD or SMS methods? Andrew ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] Add GSM registration status notification (V3)
Hi Dan,
Yep can do but I have no CDMA network here and know little about it, so
I'll need someone to look over the registration states to check. Is that
reasonable?
Thanks,
Andrew
On Wednesday 15 June 2011, Dan Williams wrote:
> On Fri, 2011-06-10 at 16:13 +0100, Andrew Bird wrote:
> > The current UI requires the user to mouse-over and reveal a tool
> > tip (or click an indicator) to discover the registration state
> > (aka polling). If the user inadvertently re-registers on a
> > roaming network, the operation is silent until the user decides
> > to check the applet for network status, possibly incurring
> > expensive roaming tariffs in the mean time.
> >
> > So to prevent silent registration changes, alert the user with a
> > notification when the GSM registration status changes to home or
> > to roaming.
>
> Pushed to master and 0.8.x. Any takers for the CDMA equivalent?
>
> Dan
>
> > ---
> >
> > v1 -> v2: Fix incorrect mapping of reg_state to mb_state.
> > v2 -> v3: Ensure we preserve the meaning of info->reg_state.
> >
> > Use the gsm_state_to_mb_state mapping function.
> > Also handle the reply of GetRegistrationInfo().
> >
> > Signed-off-by: Andrew Bird
> > ---
> >
> > src/applet-device-gsm.c | 34 +++---
> > 1 files changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/src/applet-device-gsm.c b/src/applet-device-gsm.c
> > index 5d0d584..76fd81e 100644
> > --- a/src/applet-device-gsm.c
> > +++ b/src/applet-device-gsm.c
> > @@ -1083,6 +1083,25 @@ parse_op_name (GsmDeviceInfo *info, const char
> > *orig, const char *op_code)
> >
> > return find_provider_for_mcc_mnc (info->providers, orig);
> >
> > }
> >
> > +static void
> > +notify_user_of_gsm_reg_change(GsmDeviceInfo *info)
> > +{
> > + guint32 mb_state = gsm_state_to_mb_state (info);
> > +
> > + if (mb_state == MB_STATE_HOME)
> > + applet_do_notify_with_pref (info->applet,
> > + _("GSM network."),
> > + _("You are now registered on the
home
> > network."), +
> > "notification-gsm-high",
> > +
PREF_DISABLE_CONNECTED_NOTIFICATIONS);
> > + else if (mb_state == MB_STATE_ROAMING)
> > + applet_do_notify_with_pref (info->applet,
> > + _("GSM network."),
> > + _("You are now registered on a
roaming
> > network."), +
> > "notification-gsm-high",
> > +
PREF_DISABLE_CONNECTED_NOTIFICATIONS);
> > +}
> > +
> >
> > #define REG_INFO_TYPE (dbus_g_type_get_struct ("GValueArray",
> > G_TYPE_UINT, G_TYPE_STRING, G_TYPE_STRING, G_TYPE_INVALID)) #define
> > DBUS_TYPE_G_MAP_OF_VARIANT (dbus_g_type_get_map ("GHashTable",
> > G_TYPE_STRING, G_TYPE_VALUE))
> >
> > @@ -1101,7 +1120,7 @@ reg_info_reply (DBusGProxy *proxy, DBusGProxyCall
> > *call, gpointer user_data)
> >
> > if (array->n_values == 3) {
> >
> > value = g_value_array_get_nth (array, 0);
> > if (G_VALUE_HOLDS_UINT (value))
> >
> > - new_state = g_value_get_uint (value);
> > + new_state = g_value_get_uint (value) + 1;
> >
> > value = g_value_array_get_nth (array, 1);
> > if (G_VALUE_HOLDS_STRING (value)) {
> >
> > @@ -1120,7 +1139,11 @@ reg_info_reply (DBusGProxy *proxy, DBusGProxyCall
> > *call, gpointer user_data)
> >
> > g_value_array_free (array);
> >
> > }
> >
> > - info->reg_state = new_state + 1;
> > + if (info->reg_state != new_state) {
> > + info->reg_state = new_state;
> > + notify_user_of_gsm_reg_change (info);
> > + }
> > +
> >
> > info->op_code = new_op_code;
> > info->op_name = new_op_name;
> >
> > @@ -1281,8 +1304,13 @@ reg_info_changed_cb (DBusGProxy *proxy,
> >
> > gpointer user_data)
> >
> > {
> >
> > GsmDeviceInfo *info = user_data;
> >
> > + guint32 new_state = reg_state + 1;
> > +
> > + if (info->reg_state != new_state) {
> > + info->reg_state = new_state;
> > + notify_user_of_gsm_reg_change (info);
> > + }
> >
> > - info->reg_state = reg_state + 1;
> >
> > g_free (info->op_code);
> > info->op_code = strlen (op_code) ? g_strdup (op_code) : NULL;
> > g_free (info->op_name);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Diskless clients and NetworkManager
Hi Pablo, Speaking as a developer of VMC, I find NM's position of being the well known place for applications to find out if they have network connectivity logical, but also frustrating. Not providing an interface for 3rd party connection managers to publish their status means we have to ship our product in a condition that almost all users will find bewildering. Currently we can successfully make a connection to a mobile network, the user then opens Firefox and he is told that it's offline; now that's not user friendly. Of course there are workarounds for Firefox, but there are other apps that do a similar thing, surely we don't have to go and modify them all. Doing that would throw away all the benefit of NM being the well known interface it is. In the future I'd like a dbus interface fitting to NM that allows 3rd party apps to publish their online status. Nothing too fancy is required, just a possibility to get ourselves out of the hole we find ourselves in. Best regards, Andrew On Thursday 30 April 2009, Pablo Martí Gamboa wrote: > 2009/4/30 Dan Williams > > > On Thu, 2009-04-30 at 14:06 +0100, Marc Herbert wrote: > > > David Sundqvist a écrit : > > > > If I set it to be managed by NM, will NM try to manage it in any way? > > > > Can I set it to be seen, but still unmanaged? Or maybe I could get NM > > > > to always output a connected status instead of a no-connection which > > > > triggers firefox offline mode, etc. (should the connection be lost, > > > > well, then NM won't be able to detect it anyway due to being frozen > > > > on the first page touch). > > > > > > There seems to be something fundamentally wrong in this no-connection/ > > > /offline thing. Since NM can be configured to manage _not all_ > > > interfaces (including none at all) then why are some applications > > > wrongly assuming NM is always managing the entire network > > > configuration? This seems to be where the bug lies and should be > > > fixed. > > > > Its mostly a distro problem; if NM is not managing your default internet > > connection, then you should probably turn NM off when setting up the > > machine. > > Unfortunately, in today's Linux Desktop this will yield some main > application unusable, they all rely on the NetworkManager interface for > connectivity status. For projects that provide connectivity (ConnMan, > Wader, VMC, K-MobileTools, gnome-ppp, etc.) is a frustrating situation. > > Even thou NetworkManager is the de-facto standard tool for managing > connectivity, NetworkManager won't always be the solution for everyone. Say > you have a token ring connection, NetworkManager doesn't have plans to > support it. Say you provide dial up capabilities, like VMC, Wader, etc. It > ain't gonna be nice, users have connectivity but applications are not > aware. There are workarounds for applications like Firefox, but it is not > something that a noob user will understand or do. For other apps like > pidgin, there's no workaround AFAIK. Perhaps Moblin has patched Firefox, > pidgin, etc. to listen for ConnMan's signals, but this is only possible on > the OEM/distro level - i.e. I'm not gonna ship a patched firefox/pidgin/foo > that listens for Wader's signals in my ppa/buildservice, it ain't gonna > scale. > > It is gonna be a though process, but we need to engage all the interested > parties on a discussion about how to make applications aware of > connectivity changes and come up with a DBus interface that several > applications can provide. > > I have already expressed this concerns to Dan Williams, and I think that > @asac thinks something similar. > > What do you guys think? > > > The only way you can make intelligent decisions about the network state > > on the machine is to make those decisions with *all* the necessary > > information, and that means letting NetworkManager control all your > > network connections. > > > > There are situations in which NM is not appropriate at this time, and > > those are mostly situations where the primary network connection cannot > > be controlled by NM for some reason. Thankfully, there are not too many > > of those. Network-mounted-/usr is one of those cases, as are cases > > where the root device is network-mounted, or where the interface cannot > > be touched after exiting the initrd. For now, I'd suggest using the > > static config scripts. > > > > A bullet-point on my feature list is to handle this case specifically > > for wired non-802.1x connections, because all other types require too > > much state to just be taken over post-initrd. > > > > 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 http://mail.gnome.org/mailman/listinfo/networkmanager-list
