help please!!!
Please, I need some help. I made a mistake and deleted the network manager from mi control panel on the top of mi Ubuntu 8...and I can't find anywhere it to replace it in the control panel. ...I'm not very smart in using my pc, but I am an Ubuntu fan !!! Can somebody help me? Thanks ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: Generating more macros in ModemManager-names.h from the introspection XML
On Sun, May 6, 2012 at 7:02 AM, Aleksander Morgado wrote: > On 05/04/2012 07:14 PM, Jason Glasgow wrote: > > In the XML comments we have descriptions of the keys returned in > > GetStatus, Scan, and the arguments to Simple.Connect and others. These > > key names are not part of the generated ModemManager-names.h header file. > > > > Attached is a patch that allows us to generate the macros for the key > > name by moving the key names into XML mapping and member elements and > > updating the xsl. I have not yet done it for all the methods because > > I'm interested in soliciting feedback. Is this the right approach? > > > > Comments? > > > > Hum... mixed feelings here. From one side, I see it useful to generate > symbols for the names of the entries in the dictionaries; from the other > side, I don't want to duplicate where they are defined (gtk-doc comments > and the new mapping). > > Another possibility to ensure we only have 1 place to define the > possible dictionary entries would be to manually maintain a list of > symbols in a new public header, as done with the enums in > 'ModemManager-enums.h'. The list could be defined as: > > /** > * MM_CONNECT_PROPERTIES_PIN: > * SIM-PIN unlock code, given as a string value. > */ > #define MM_CONNECT_PROPERTIES_PIN "pin" > > ... and so on > > And all entries of the same dictionary could be included then in the > same section in the gtk-doc page generated from that code. > > Once that page with dictionary-specific entries is available, the > introspection gtk-doc documentation could directly include a link to the > relevant section, instead of re-listing all the entries again. > > -- > Aleksander > I will prepare a new PATCH using the approach you suggest. -Jason ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 2/5] novatel: Use the ALLOWED_SINGLE_AT property. Saves 5 seconds on probing.
Dan Williams writes: > On Sat, 2012-05-05 at 10:41 +0200, Bjørn Mork wrote: >> Dan Williams writes: >> >> > Port layout of the Novatel 551L (LTE Band 13 device similar to the E362 >> > this Nathan's plugin targets, but USB instead of PCI-E minicard) is as >> > follows: >> > >> > 0: AT commands >> > 1: DM >> > 2: another DM >> > 3: unknown (probably QMI; doesn't respond to $GPS_START) >> > 4/5: CDC Ether >> > >> > Odd that we have two DM ports. If Intf3 is really QMI then we should >> > make sure it's blacklisted in 'option' so we don't have to do >> > serial-related junk with it. >> >> what sort of endpoins does interface 3 have? Is the 4/5 configured as a > > FF/FF/FF, bulk in+out, no interrupt Then it certainly isn't the "QMI embedded in CDC" that we have been seeing so far. It could of course still be QMI in some other wrapping, but is that likely? >> standard CDC Ether class interface set with the appropriate CDC >> functional descriptors and class codes? I assume it's configured using >> either AT commands or DM? > > Yeah, standard CDC Ether, recognized fine by the kernel (but needs a > quirk for FLAG_WWAN). AT commands set up the connection and then DHCP > is used to obtain IP addresses. > >> I wonder... QMI could also be embedded in the CDC Ether control >> interface. But then you should see "CDC: unexpected notification 01!" >> messages from time to time from cdc_ether, assuming that the device >> sends unsolicited indications. Most (all?) QMI devices seem to do that. >> They send a QMI_CTL SYNC indication during startup at the very least. > > I'll take a look, thanks for the suggestion. The #5 CDC Data interface > does have an additional: > > ** UNRECOGNIZED: 2c ff 42 49 53 54 00 01 07 06 40 00 00 00 00 > 00 01 07 f4 01 02 08 f4 01 03 09 88 13 04 0a 10 27 05 0b 10 27 06 0c f4 > 01 07 0d f4 01 Weird. I've never actually made it through all of the CDC class specs, but I believe there shouldn't ever be any extra descriptors on the data interface, should there? And I didn't think FF was a valid descriptor type either. Vendor-specific? But how to you interpret that when you don't even know whether it describes endpoint, interface or device? Bjørn ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 4/5] novatel: Poll for whether the connection still exists.
On Mon, May 7, 2012 at 10:37 AM, Aleksander Morgado wrote: > > Given that the $NWQMISTATUS reply is not bearer-specific (reports >>overall status of the modem), I was thinking in moving the periodic >>connectivity check to MMIfaceModem instead, and plug it in using the >>same logic as e.g. the signal quality check. In that way, other >>implementations (e.g. Samsung) could benefit from the same generic >>timeout handling logic. What do you think? >> >> >> Is it useful to other implementations? I consider the periodic >> connectivity check a hack to work around Novatel's fairly broken >> firmware and complete lack of unsolicited notifications. If other modems >> are also bad at this, that seems fine, but I'd like to resist >> generalizing features when there's really only one instance of the >> problem. >> >> > Oh, I thought your Samsung plugin also needed this; may have overlooked it. My Samsung plugin also notifies the core about disconnection events, which may be what you are remembering. In that case it's in response to an unsolicited message, though; it doesn't have to poll. - Nathan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 4/5] novatel: Poll for whether the connection still exists.
Given that the $NWQMISTATUS reply is not bearer-specific (reports overall status of the modem), I was thinking in moving the periodic connectivity check to MMIfaceModem instead, and plug it in using the same logic as e.g. the signal quality check. In that way, other implementations (e.g. Samsung) could benefit from the same generic timeout handling logic. What do you think? Is it useful to other implementations? I consider the periodic connectivity check a hack to work around Novatel's fairly broken firmware and complete lack of unsolicited notifications. If other modems are also bad at this, that seems fine, but I'd like to resist generalizing features when there's really only one instance of the problem. Oh, I thought your Samsung plugin also needed this; may have overlooked it. -- Aleksander ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 4/5] novatel: Poll for whether the connection still exists.
On Sun, May 6, 2012 at 11:42 AM, Aleksander Morgado wrote: > Given that the $NWQMISTATUS reply is not bearer-specific (reports > overall status of the modem), I was thinking in moving the periodic > connectivity check to MMIfaceModem instead, and plug it in using the > same logic as e.g. the signal quality check. In that way, other > implementations (e.g. Samsung) could benefit from the same generic > timeout handling logic. What do you think? Is it useful to other implementations? I consider the periodic connectivity check a hack to work around Novatel's fairly broken firmware and complete lack of unsolicited notifications. If other modems are also bad at this, that seems fine, but I'd like to resist generalizing features when there's really only one instance of the problem. - Nathan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 3/5] novatel: Implement load_access_technologies.
On Sat, 2012-05-05 at 10:32 +0200, Aleksander Morgado wrote: > > > > Also, do we plan to support the older non-LTE/non-QMI devices with the > > 'novatel' plugin? Or should we rename this plugin to 'novatel-qmi' and > > have a 'novatel-gsm' and 'novatel-cdma' for the legacy (MDM < 9xxx) > > devices? > > > > The current novatel plugin in git master should really be "novatel-4g" > or "novatel-lte"; the old one still needs to be ported. Ok, yeah we should rename it so we can port over the old ones too. Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ModemManager] Two SMS bugs in the new code
On Sun, 2012-05-06 at 18:59 +0200, Aleksander Morgado wrote: > Hey Nathan, > > On 04/26/2012 01:58 AM, Nathan Williams wrote: > > 1. When a new single-part message arrives, an "Added" signal is sent but > > the "Completed" signal is not sent. > > > > We emit "Added" if we got a singlepart message or whenever we get the > first part of a multipart message. In the latter case, the state of the > SMS will be RECEIVING, until the last part is received and the message > assembled, which is when the state of the SMS goes to RECEIVED. I would > vote for completely removing the "Completed" emitted in the Messaging > interface; and instead just rely on each SMS state changes... At least > that was my original idea when I skipped emitting the "Completed" signal > all together. Since we have individual message state, Completed doesn't seem that useful. They would be exactly the same thing except the state conveys more information, which is more useful than Completed. Dan > > > 2. Multipart messages don't seem to work - the multipart bit isn't > > getting set correctly somewhere?. > > Yes, it wasn't being set properly; fixed here: > http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=df1f21d17f6923145926fba5be38cff947254cae > > Could you test it with that fix in? > ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [MM] [PATCH 2/5] novatel: Use the ALLOWED_SINGLE_AT property. Saves 5 seconds on probing.
On Sat, 2012-05-05 at 10:41 +0200, Bjørn Mork wrote: > Dan Williams writes: > > > Port layout of the Novatel 551L (LTE Band 13 device similar to the E362 > > this Nathan's plugin targets, but USB instead of PCI-E minicard) is as > > follows: > > > > 0: AT commands > > 1: DM > > 2: another DM > > 3: unknown (probably QMI; doesn't respond to $GPS_START) > > 4/5: CDC Ether > > > > Odd that we have two DM ports. If Intf3 is really QMI then we should > > make sure it's blacklisted in 'option' so we don't have to do > > serial-related junk with it. > > what sort of endpoins does interface 3 have? Is the 4/5 configured as a FF/FF/FF, bulk in+out, no interrupt > standard CDC Ether class interface set with the appropriate CDC > functional descriptors and class codes? I assume it's configured using > either AT commands or DM? Yeah, standard CDC Ether, recognized fine by the kernel (but needs a quirk for FLAG_WWAN). AT commands set up the connection and then DHCP is used to obtain IP addresses. > I wonder... QMI could also be embedded in the CDC Ether control > interface. But then you should see "CDC: unexpected notification 01!" > messages from time to time from cdc_ether, assuming that the device > sends unsolicited indications. Most (all?) QMI devices seem to do that. > They send a QMI_CTL SYNC indication during startup at the very least. I'll take a look, thanks for the suggestion. The #5 CDC Data interface does have an additional: ** UNRECOGNIZED: 2c ff 42 49 53 54 00 01 07 06 40 00 00 00 00 00 01 07 f4 01 02 08 f4 01 03 09 88 13 04 0a 10 27 05 0b 10 27 06 0c f4 01 07 0d f4 01 Dan ___ networkmanager-list mailing list networkmanager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
