Re: Issue with Indian Datacard
Hello Dan, Thank you for taking issue on table. I am not so advance in that. if you give me set of commands to execute then It will do the steps for you. I have tried to use abrt but..it downloading heavily debug+debuginfo so thats costing bandwidth. any other option ? With Regards, Manish S Runwal Runwalsoft.com From: Dan Williams To: Manish S Runwal Cc: "networkmanager-list@gnome.org" Sent: Friday, 3 June 2011 4:18 AM Subject: Re: Issue with Indian Datacard On Sun, 2011-05-22 at 04:32 -0700, Manish S Runwal wrote: > Hello, > > > I have BNSL Datacard (Indian mobile broadband). It run along with > Join_Air software. > As it was working till Fedora 14. As soon as i have installed Fedora > 15. It stopped connecting. every time its tried to connect nm-applet > gets crashed. Is there any crash helper tool that offers to collect and send the crash log for you? If so, can you grab that crash log adn reply with it? Otherwise we can persue other options. Dan___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Idea - Detecting IP conflicts in NM
On Thu, 2011-04-28 at 22:44 +0300, Ozan Çağlayan wrote: > On 27.04.2011 22:29, Dan Williams wrote: > > >> follow-up for gratuitous arp replies: > >> http://forum.nginx.org/read.php?31,75057 > > > > This would be cool; we could do it after getting the IP address if we > > wanted to in nm-device.c or elsewhere before we've even assigned the IP > > address to the card. Alternatively, if we wanted to keep lower latency > > we could do it after we've assigned the address and said we're connected > > like other OSs do and warn the user or something. Is this a patch you'd > > be willing to work on? If so that would be great! > > Not yet. I've played with the duplicate address detection (DAD) mode of > the arping tool but it seems that on systems that I've tried, the > endpoints don't reply to gratuitous ARPs. There's probably a /proc/* > tunable that's disabled by default which ignores those requests. > > Applets can even offer getting an IP from the DHCP server in case of > conflicting IP situations or alternatively, NM can assign the IP but > applets can warn the user about the situation (or even a limited or > problematic connection icon can be overlayed on the applet's icon in the > tray) > > Seen that it's acceptable from upstream, I'll try to implement this > step-by-step. Yeah, we can at the very least implement the DAD stuff and check for a duplicate IP; NM 0.9 makes this easier because there's the IP_CHECK activation stage in which this stuff should happen. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: bluetooth DUN silently discarding "invalid" APNs
On Fri, 2011-05-06 at 11:02 +0100, Marc Herbert wrote: > >> By the way it is not possible to enter a blank APN either (asking the > >> network use the default APN). This again works perfectly with wvdial. > >> And this is valid. > > > Yes, it's valid, but note that the "default" APN is stored in the > > *device*, not the SIM card, and has no relation to the SIM card at all. > > So if you ever swap SIM cards, or use a different provider, then the APN > > is surely going to be wrong and the dialing will fail. However, I've > > been thinking of ways to enable using the "default" APN since that works > > for some phones that don't allow setting the APN at all via AT commands, > > but where dialing works fine. > > > > No, I was not referring to any default APN stored from the phone, but > to the case where the phone does not provide any APN to the network *at > all*. > > Section 3.1 "Definitions" at the very beginning of 3GPP 23.401: > > Default APN: A Default APN is defined as the APN which is marked as > default in the subscription data [...] when no APN is provided by > the UE". > > UE = User Equipment. The "subscription data" comes from the HSS in the > network. > > In the same spec see also paragraph 12 in section 5.3.2.1. This > paragraph has about 5-6 sentences starting with: "If the UE does [not] > provide an APN,..." > > The operator I can connect to using a blank APN did not even exist yet > when I bought the phone, so for sure the phone is not sneakily > providing any "good default APN" to get me online. It is a old > 2.5G EDGE phone by the way. And T-Mobile appears to allow this as well according to my testing; I looked around and couldn't find much information on it at all, but you're right, and we should allow passing no APN to MM, which would trigger MM to create a blank "default" PDP context with no APN, which MM would then activate. Then we hope it works. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Icera CID handling without an APN
On Thu, 2011-05-19 at 18:28 -0400, Nathan Williams wrote: > On Thu, May 19, 2011 at 4:54 PM, Dan Williams wrote: > > On Thu, 2011-05-12 at 19:02 -0400, Nathan Williams wrote: > >> In mm-generic-gsm.c, if an APN is not provided as a property to > >> simple_connect(), priv->cid is never set and remains at -1. > >> The Icera modem plugin has a _get_cid() wrapper call which checks for > >> this and returns 0 if the stored CID is -1. There are two problems > >> with this: > >> * 0 is not a valid CID; according to 3GPP 27.007, CIDs have a > >> minimum value of 1. Thus, if an APN was not provided, the plugin > >> issues commands like %IPDPCFG and %IPDPACT with CID=0, which the modem > >> rejects. > >> * connection_enabled() uses the priv->cid value rather than the > >> _get_cid() wrapped value, and bails out if it's -1, so a connection is > >> never acknowledged and the modem remains in "connecting" state. > > > > So we should never be using an invalid CID here, it should always be 1 > > or higher. I think the -1 was used as an error value that we should > > never hit, and there used to be assertions for that in the code. I > > think the whole dance here was just to be paranoid since we never ever > > want to send -1 to the modem, which happened before in some corner cases > > which have since been fixed. > > > > So we basically have to deal with the corner case of what happens if the > > code somehow screws up and we for whatever reason can't figure out the > > CID of the PDP context that we're trying to disconnect. I think > > returning "1" here should only happen for the disconnect case, since in > > all other cases, there would be a logic error to have an invalid CID and > > we should fail out, because that's a bug we need to fix. > > I'm a little puzzled. The issue I see is at connect time, if an APN > hasn't been specified. Is it a logic bug that we're not selecting > (perhaps arbitrarily) a CID in this case (in simple_state_machine)? > I'm not sure where the responsibility lies here. I think the assumption is that an APN *has* been supplied, at least that's been the assumption all along. Marc Herbert and I had a discussion a while back about the "default" APN, where you simply pass nothing for the AP and create a PDP context with a blank APN and hope it works, which is what you might be expecting to happen here. At the moment everything expects an APN and if it half-works that's by coincidence. I did some testing last month with default APNs without ModemManager, just trying to see if they worked with the providers I have, and found that they did; I'm not sure if that's happened (at least for T-Mobile) in the past few years or what, but I could swear it didn't used to, and I'm sure some providers simply don't set up the default APN in their HLR. But Marc is right and we should allow a blank APN (or really, just don't add the APN to the Simple.Connect properties hash at all) during the connect attempt. If no APN is supplied, then MM would check for an existing PDP context with a blank APN, and if none was present, create one, and then dial using that CID. And then we just hope it works, and if not, hope the modem gives us a usable error code. Dan > - Nathan > > So I don't > > think the patch as sent is the right approach; perhaps we should > > g_assert(cid > 1) in the other cases, and be more relaxed for > > disconnect? Or in disconnect if we dont' get a valid CID, we just send > > "ATH" as a desperate attempt to kill everything since something went > > wrong... > > > > Dan > > > >> > >> I've attached a patch that (I think) fixes this, by having _get_cid() > >> return 1 and having connection_enabled() use it instead of > >> mm_generic_gsm_get_cid(); however, I have a feeling that the way it > >> works now is deliberate and I'm missing something about how the no-APN > >> case is supposed to work. > >> Thoughts? Or, if this analysis seems correct, the patch should be > >> ready to go. > >> > >> > >> - 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
Re: [PATCH] adding RSA-MD4 for HMAC encryption in nm-openvpn
On Fri, 2011-05-20 at 12:22 +0200, Olivier Lambert wrote:
> Hi everyone,
>
> (sorry, repost, but I forgot previously the syntax [PATCH] in subject)
Thanks, applied to 0.8 and git master.
Dan
> I need to connect to a corporate OpenVPN server. This VPN use RSA-MD4
> on HMAC.. But this option doesn't exist in the nm GUI !
>
> So, here is a fix (it was tested by me, and it works like a charm).
>
> diff --git a/properties/auth-helpers.c b/properties/auth-helpers.c
> index 357a5dd..322688e 100644
> --- a/properties/auth-helpers.c
> +++ b/properties/auth-helpers.c
> @@ -1077,6 +1077,7 @@ populate_hmacauth_combo (GtkComboBox *box, const char
> *hm
>const char **item;
>static const char *items[] = {
>NM_OPENVPN_AUTH_NONE,
> + NM_OPENVPN_AUTH_MD4,
>NM_OPENVPN_AUTH_MD5,
>NM_OPENVPN_AUTH_SHA1,
>NM_OPENVPN_AUTH_SHA224,
> @@ -1102,6 +1103,8 @@ populate_hmacauth_combo (GtkComboBox *box, const char
> *hm
>
>if (!strcmp (*item, NM_OPENVPN_AUTH_NONE))
>name = _("None");
> + else if (!strcmp (*item, NM_OPENVPN_AUTH_MD4))
> + name = _("RSA-MD4");
>else if (!strcmp (*item, NM_OPENVPN_AUTH_MD5))
>name = _("MD-5");
>else if (!strcmp (*item, NM_OPENVPN_AUTH_SHA1))
> diff --git a/src/nm-openvpn-service.c b/src/nm-openvpn-service.c
> index f3c25ce..0762e89 100644
> --- a/src/nm-openvpn-service.c
> +++ b/src/nm-openvpn-service.c
> @@ -605,6 +605,7 @@ validate_auth (const char *auth)
> {
>if (auth) {
>if ( !strcmp (auth, NM_OPENVPN_AUTH_NONE)
> + || !strcmp (auth, NM_OPENVPN_AUTH_MD4)
>|| !strcmp (auth, NM_OPENVPN_AUTH_MD5)
>|| !strcmp (auth, NM_OPENVPN_AUTH_SHA1)
>|| !strcmp (auth, NM_OPENVPN_AUTH_SHA224)
> diff --git a/src/nm-openvpn-service.h b/src/nm-openvpn-service.h
> index d503f4e..bc245b0 100644
> --- a/src/nm-openvpn-service.h
> +++ b/src/nm-openvpn-service.h
> @@ -77,6 +77,7 @@
> #define NM_OPENVPN_KEY_RENEG_SECONDS "reneg-seconds"
>
> #define NM_OPENVPN_AUTH_NONE "none"
> +#define NM_OPENVPN_AUTH_MD4 "RSA-MD4"
> #define NM_OPENVPN_AUTH_MD5 "MD5"
> #define NM_OPENVPN_AUTH_SHA1 "SHA1"
> #define NM_OPENVPN_AUTH_SHA224 "SHA224"
> ___
> 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] ModemManager: Free an allocated string
On Fri, 2011-05-20 at 14:43 -0400, Nathan Williams wrote: > Just like it says. Applied, thanks. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Alcatel X200 troubleshooting
On Sat, 2011-05-21 at 21:05 +0200, Javier Almasoft wrote: > Sorry for the delay, I was not able to access the device until > recently. Attached is the content of the storage part of the device > (the installer maybe speaks spanish, or worse, basque ). It's a bit > too large, hope it arrives.. > > The command AT+CLAC returns error. So I noticed; I received my X200 last week and found the same things. I'll poke around with it and see what I can come up with, but it doesn't appear to use the same commands as the X220, I think. Dan > > AT&V gives: > > > &C: 2; &D: 2; &E: 1; &F: 0; &S: 0; &W: 0; E: 1; L: 0; M: 0; Q: 0; V: > 1; > X: 1; Z: 0; \Q: 3; \S: 0; \V: 0; S0: 0; S2: 43; S3: 13; S4: 10; S5: 8; > S6: 2; S7: 50; S8: 2; S9: 6; S10: 14; S11: 95; S30: 0; S103: 1; S104: > 1; > +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","internet.euskaltel.mobi","0.0.0.0",0,0) > ; +CGDSCONT: ; +CGTFT: ; +CGEQREQ: ; +CGEQMIN: ; +CGQREQ: ; +CGQMIN: ; > +CGEREP: 0,0; +CGDATA: "PPP"; +CGCLASS: "A"; +CGSMS: 1; +CSMS: 0; > +CMGF: 0; +CSAS: 0; +CRES: 0; +CSCA: "+34607000994",145; +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; +SYSSEL: 13,0,0,0; +CPIN: ,; > +CMEC: 0,0,0; +CKPD: 1,1; +CIND: 0,2,1,1,1,0,1,0; +CMER: 0,0,0,0,0; > +CGATT: 1; +CGACT: 0; +CPBS: "SM"; +CPMS: "ME","ME","ME"; > +CNMI: 0,0,0,0,0; +CMMS: 0; +FTS: 0; +FRS: 0; +FTH: 3; +FRH: 3; +FTM: > 96; > +FRM: 96; +CCUG: 0,0,0; +COPS: 0,0,""; +CUSD: 0; +CAOC: 1; +CCWA: 0; > +CCLK: ""; +CLVL: 5; +CMUT: 1; +CPOL: 0,2,"",0,0,0; +CPLS: 0; +CTZR: > 0; > +CTZU: 0; +CLIP: 0; +COLP: 0; +CDIP: 0; +CLIR: 0 > > > OK > > > Also, ATI gives: > > > Manufacturer: TCT Mobile International Limited > Model: HSPA Data Card > Revision: S21B3000XX > IMEI: 353575040102349 > +GCAP: +CGSM,+DS,+ES > > > OK > > > 2011/5/3 Dan Williams > > > > Is there any way you could tar up and send me the Windows > installer bits > so I can investigate what kind of modem this device really > is? Also, if > you can, the output of the following two commands would be > helpful here: > > AT+CLAC > AT&V > > Dan > > > > > > -- > Regards, > Javier Martínez > ALMASOFT, S.L. > > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Issue with Indian Datacard
On Sun, 2011-05-22 at 04:32 -0700, Manish S Runwal wrote: > Hello, > > > I have BNSL Datacard (Indian mobile broadband). It run along with > Join_Air software. > As it was working till Fedora 14. As soon as i have installed Fedora > 15. It stopped connecting. every time its tried to connect nm-applet > gets crashed. Is there any crash helper tool that offers to collect and send the crash log for you? If so, can you grab that crash log adn reply with it? Otherwise we can persue other options. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Add and implement an interface to get a GSM SPN
On Thu, 2011-05-26 at 12:32 -0400, Nathan Williams wrote: > This adds a feature in parallel with GetOperatorId, which gets the GSM > Service Provider Name value from the SIM card; this is useful for > displaying the name of the home operator when said operator is a MVNO > or otherwise branded differently than the carrier's usual name. > > There's clearly some code to be factored out of the various routines > that parse the response of AT+CRSM commands, but that cleanup will > come in a separate patch. Applied. Yeah, we definitely want to factor stuff out here. Feel free to send it along whenever you get the chance, thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Reconnect silently
On Fri, 2011-05-27 at 10:56 -0700, Marcel Holtmann wrote: > Hi Misha, > > > (Not to be taken seriously) Since it takes less than one minute to crack a > > WEP passphrase we could do just that to determine whether it has changed. > > I have seen a Bluetooth protocol analyzer that cracks Bluetooth PIN > codes up to 8 characters for you in the background. It does not even > bother asking the user for providing the PIN code. > > So I actually like the idea of just treating WEP encrypted networks as > open and cracking the WEP passphrase and then just start using it. Maybe > that way we finally get rid of this stupid WEP thingy ;) Making WEP just go away like this would make life worth living again :) Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [PATCH] ModemManager: Format SMS sender addresses with a "+" for international telephone numbers
On Tue, 2011-05-31 at 14:01 -0400, Nathan Williams wrote: > This formats addresses in SMS messages (sender address and SMSC) in > accordance with ITU E.164/E.123 by including a "+" before the number > when it's an international phone number (according to the other > address-type fields). Applied, thanks! Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: F15 NetworkManager and Lenovo T61/Intel 4965AGN Wireless
On Thu, 2011-06-02 at 15:04 -0400, Chuck Anderson wrote: > On Thu, Jun 02, 2011 at 02:05:36PM -0500, Dan Williams wrote: > > On Mon, 2011-05-30 at 18:57 -0400, Tim Evans wrote: > > > Just upgraded my Lenovo ThinkPad T61 from Fedora 14 to Fedora 15 (via > > > preupgrade) and lost my Intel AGN wireless in the process. Wireless was > > > working well with F-14. > > > > > > Actually, NetworkManager itself barfs (see debug output of a manual > > > start, attached). /var/log/dmesg is also attached for reference. > > > > This was a bug in the NM that hit Fedora 15 updates (due to too little > > time spent in updates-testing before being karma-promoted to stable > > updates) that has since been fixed by a new update. > > Can the push-to-stable step be made manual so we don't get into this > situation again? Possibly, or we can bump the +Karma to a larger number so that more people have to test it before it goes out, which is what I usually do since NM is a fairly critical part of the system. I may have forgotten to do it that time. Would be nice if Bodhi could have different default +Karmas for each package. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Automatic Connection not Working
On Mon, 2011-05-30 at 13:44 +0200, Jirka Klimes wrote: > On Thursday 26 of May 2011 12:15:35 Chris wrote: > > On Thu, 2011-05-19 at 23:15 +0100, Chris wrote: > > > On Thu, 2011-05-19 at 15:26 -0500, Dan Williams wrote: > > > > On Thu, 2011-05-19 at 12:55 +0100, Chris Baines wrote: > > > > > Hello, > > > > > > > > > > When I start my netbook, my home network does not connect > > > > > automatically, I think this is because it is set to not broadcast. Is > > > > > there anyway to get around this problem, and if automatic connections > > > > > do not work for hidden networks why is the option still enabled? > > > > > > > > NM should be storing the BSSID of the hidden network if you've ever > > > > successfully connected to it. Then, NM uses that to match up the > > > > hidden scan result (the AP still shows up, just with a blank SSID) > > > > with the real SSID. Can you run: > > > > > > > > iwlist wlan0 scan > > > > > > > > when this happens to you and report the scan result for your AP? Also, > > > > does this connection have the "Available to all users" box checked in > > > > nm-connection-editor? > > > > > > > > Dan > > > > > > I can confirm that the connection has the available to all users box > > > ticked and I have attached the output of the command you included both > > > before I told it to connect and afterwards. I was however unsure what > > > you meant by AP? > > > > > > Chris > > > > Any progress on this issue, I was searching round the Internet and found > > this bug https://bugzilla.redhat.com/show_bug.cgi?id=448437 that seams > > to be the bug I have hit. I will try the workaround in the last comment > > and get back to you though. > > > > Thanks, > > > > Chris > > The problem is that BSSIDs of networks, we connected to, was stored by user > settings service (which is not part of NM 0.9 anymore). I've posted a patch > implementing BSSIDs storing inside NM. See > https://bugzilla.redhat.com/show_bug.cgi?id=707406 Added some comments to the bug. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: F15 NetworkManager and Lenovo T61/Intel 4965AGN Wireless
On Thu, Jun 02, 2011 at 02:05:36PM -0500, Dan Williams wrote: > On Mon, 2011-05-30 at 18:57 -0400, Tim Evans wrote: > > Just upgraded my Lenovo ThinkPad T61 from Fedora 14 to Fedora 15 (via > > preupgrade) and lost my Intel AGN wireless in the process. Wireless was > > working well with F-14. > > > > Actually, NetworkManager itself barfs (see debug output of a manual > > start, attached). /var/log/dmesg is also attached for reference. > > This was a bug in the NM that hit Fedora 15 updates (due to too little > time spent in updates-testing before being karma-promoted to stable > updates) that has since been fixed by a new update. Can the push-to-stable step be made manual so we don't get into this situation again? Thanks ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: F15 NetworkManager and Lenovo T61/Intel 4965AGN Wireless
On Mon, 2011-05-30 at 18:57 -0400, Tim Evans wrote: > Just upgraded my Lenovo ThinkPad T61 from Fedora 14 to Fedora 15 (via > preupgrade) and lost my Intel AGN wireless in the process. Wireless was > working well with F-14. > > Actually, NetworkManager itself barfs (see debug output of a manual > start, attached). /var/log/dmesg is also attached for reference. This was a bug in the NM that hit Fedora 15 updates (due to too little time spent in updates-testing before being karma-promoted to stable updates) that has since been fixed by a new update. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: NetworkManager and Bluetooth
On Wed, 2011-06-01 at 00:10 +0100, Timothy Murphy wrote: > I thought I read some time ago that NM had incorporated Bluetooth > in some way, but I couldn't find any reference to Bluetooth > in the NM files in Fedora. > > To be concrete, can I use NM to establish Bluetooth connection > with a mobile phone? If you're using the GNOME desktop, it's done when you pair the phone, like so: http://blogs.gnome.org/dcbw/2009/07/10/unwire-with-networkmanager/ Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
System wide openvpn connection with password-tls
Hi to all I'm using Network Manager 0.8.4 (Fedora 14) and I'm trying to setup an openvpn system-wide connection. The connection needs to be TLS with password because our OpenVPN server is configured that way. The problem is that I need that username and password pair will be asked to the user via a gui dialog at the moment of connection. Is that possible with Network Manager 0.8.4 ??? (Please cc me as I'm not subscribed to the list) My keyfile: [connection] id=VPN uuid=21d0f17c-5bd0-4e5a-8f52-5244240e83bf type=vpn autoconnect=false timestamp=1306710584 [ipv4] method=auto dns=***.***.***.**;***.***.***.***.*; ignore-auto-dns=true never-default=true [vpn] service-type=org.freedesktop.NetworkManager.openvpn connection-type=password-tls ca=/etc/pki/tls/certs/ca.crt ta=/etc/pki/tls/private/ta.key remote=** username=** ta-dir=1 cert=/etc/pki/tls/certs/***.crt comp-lzo=yes key=/etc/pki/tls/private/*.key [vpn-secrets] cert-pass=** password=* Many thanks in advance...! -- .^.Lic. Gabriel Gomiz - Red Hat Certified Engineer (RHCE) /V\Jefe de Sistemas - Administrador Red y Servidores // \\ Gerencia de Sistemas - Cooperativa Obrera Ltda. /( )\ Tel (0291) 456-0084 ^^-^^ s/Window[$s]/LINUX!!/g or die; ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: ModemManager: issues with port probing and cached capabilities
> > Most (all?) implementations of grab_port() in the plugins rely on the > fact that the port probing task they get as input argument is exactly > the one which did the port probing: there are calls to > mm_plugin_base_supports_task_get_probed_capabilities() usually in > grab_port() in order to know if a GSM or CDMA modem object is to be > created. This is even the case for the generic plugin, which means that > if some other plugin did the real port probing, once the Generic plugin > wants to grab the port (cases 2 and 3 above), the call to > mm_plugin_base_supports_task_get_probed_capabilities() will return 0 and > the port won't be grabbed, spitting something like: >do_grab_port(): plugin 'Generic' claimed to support tty/ttyUSB0 but > couldn't: (-1) (unknown) > > I guess this behaviour is undesired, we shouldn't make grab_port() > assume that the supports task that gets as input is really the supports > task that did the real probing. Or, otherwise, we could try to simulate > that a port probing was done by that supports task by copying the cached > capabilities within the supports task results. Any other suggestion on > how to avoid this issue? > I already implemented a fix for this in the 'plugin-cinterion' branch in my gitorious.org repo: https://gitorious.org/lanedo/modemmanager/commit/1eae72f6c7c89341c16e95f4a7f0fb82fc8ccfc0 The fix involves changing all plugins so that, in supports_port(), they don't call mm_plugin_base_get_cached_port_capabilities (). Instead, they call a new mm_plugin_base_supports_task_propagate_cached(). This new method will check if already cached probed results are available, and if so, it will propagate the cached results to the supports task itself, so that if supports_task_get_probed_capabilities() is called afterwards, a copy of the cached ones is returned. With this fix, a plugin trying to grab a given port does not depend on having done the probe itself, as the supports task will always contain either a copy of the previously cached results, or the results of a newly launched probe. Note that the commit above alone is not merge-able in master, as it's based on the not-yet-merged cinterion-plugin branch. Cheers! -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
