Re: [PATH] Support resolvconf
On Tue, 2008-08-26 at 22:20 -0400, Dan Williams wrote:
> On Wed, 2008-08-27 at 03:49 +0200, Michael Biebl wrote:
> > Roy Marples wrote:
> > > On Sun, 2008-08-24 at 01:01 +0200, Alexander Sack wrote:
> >
> > >> For the domain/search tweakage: I feel unsure about this (though I kept
> > >> this part of your patch untouched for now). This is quite a specific
> > >> feature you want to implicitly entrench here. Maybe we can push
> > >> that back until we know if and how we want to implement such a
> > >> feature?
> > >
> > > There's no real need to push it back.
> > > NM currently folds domain into searches, so there's no need to actually
> > > use domain at all.
> >
> > Hi Roy,
> >
> > I agree with Alex here.
> > Could you please split up the patch into two, so we can address those
> > two issues separately.
> > I think the resolvconf part is fine.
> > Dan, if you are ok with it also, I'd be going to commit this, unless you
> > beat me to it ;-)
>
> It looks OK, except for one change. Not sure where we left the
> conversation last, but I'm not sure if just because resolvconf is
> installed means that it's actually being used. Most of the time you can
> have a package installed, but you don't have to enable it. For the
> moment, I'd suggest either (1) #ifdef-ing the resolvconf specific stuff
> with #ifdef DEBIAN, or (2) adding a configure switch for
> --with-resolv-conf=yes which would #define USE_RESOLVCONF, and then
> protect the resolvconf stuff with #ifdef USE_RESOLVCONF.
New patch attached to enable resolvconf support via configure.
Keeps exiting domain/search logic.
Hunks #10 and #11 are optional, just a condensation of the big comment
and a code optimisation.
> > For the domain/search changes, I'd like to take a separate look.
>
> Agreed, though I think the behavior change here is just to make searches
> > domain, while right now it's the other way around. I'm not exactly
> sure whether that's the right thing to do but we should probably be
> following the current standards and doing backwards-compat as the
> fallback unless there's a major problem.
If I have the time, I may investigate a more intrusive patch so that
resolvconf really gets the right interface information instead of the
"best" information so it can work properly and maybe work with the
domain switch for VPNs. Since I first sent my email about this, I've had
a few replies off list asking about it so I believe there is the demand
for it.
Thanks
Roy
Index: src/named-manager/nm-named-manager.c
===
--- src/named-manager/nm-named-manager.c (revision 4027)
+++ src/named-manager/nm-named-manager.c (working copy)
@@ -23,6 +23,7 @@
#include "config.h"
+#include
#include
#include
#include
@@ -38,6 +39,7 @@
#include "nm-ip4-config.h"
#include "nm-utils.h"
#include "NetworkManagerSystem.h"
+#include "NetworkManagerUtils.h"
#ifdef HAVE_SELINUX
#include
@@ -47,6 +49,8 @@
#define RESOLV_CONF "/etc/resolv.conf"
#endif
+#define ADDR_BUF_LEN 50
+
G_DEFINE_TYPE(NMNamedManager, nm_named_manager, G_TYPE_OBJECT)
#define NM_NAMED_MANAGER_GET_PRIVATE(o) (G_TYPE_INSTANCE_GET_PRIVATE ((o), \
@@ -115,6 +119,7 @@
}
}
+
#if defined(TARGET_SUSE)
/**/
/* SUSE */
@@ -157,10 +162,9 @@
}
static gboolean
-update_resolv_conf (const char *iface,
-const char *domain,
-char **searches,
+dispatch_netconfig (char **searches,
char **nameservers,
+const char *iface,
GError **error)
{
gint fd;
@@ -188,67 +192,53 @@
return TRUE;
}
+#endif
-#else
-/**/
-/* Generic */
static gboolean
-update_resolv_conf (const char *iface,
-const char *domain,
-char **searches,
-char **nameservers,
-GError **error)
+write_resolv_conf (FILE *f, const char *domain,
+ char **searches,
+ char **nameservers,
+ GError **error)
{
- const char *tmp_resolv_conf = RESOLV_CONF ".tmp";
char *domain_str = NULL;
char *searches_str = NULL;
char *nameservers_str = NULL;
- FILE *f;
+ int i;
+ gboolean retval = FALSE;
- if ((f = fopen (tmp_resolv_conf, "w")) == NULL) {
+ if (fprintf (f, "%s","# Generated by NetworkManager\n") < 0) {
g_set_error (error,
NM_NAMED_MANAGER_ERROR,
NM_NAMED_MANAGER_ERROR_SYSTEM,
- "Could not open " RESOLV_CONF ": %s\n",
- g_strerror (errno));
- return FALSE;
- }
-
- if (fprintf (f, "%s","# generated by NetworkManager, do not edit!\n\n") < 0) {
- g_set_error (error,
- NM_NAMED_MANAGER_ERROR,
- NM_NAMED_MANAGER_ERROR_SYSTEM,
"Could not write " RESOLV_CONF ": %s\n",
g_strerror (errno));
- fclose (f);
return FALSE;
}
if (domain)
- domain_str = g_strconcat ("domain ", domain, "\n\n", NULL);
+ domain_str = g_strconcat ("domain ", domain, "\n", NULL);
if (searches) {
char *tmp_str;
tmp_str = g_strjoinv (" ", searches);
- searches_str = g_strconcat ("search ", tmp_
Fwd: Stop this APN madness!
We could be realy clever in the configuration screen and query the current operator, look up the APN for that oprtator. The only problem with this is that the operator names are sometimes come out as MCC/MNC numbers rather than the marketing name, but I can supply a list of all the MCC/MNC numbers to network names. This is all in a GSMA database. -- Stuart Ward M +44 7782325143 > That's where MBCA comes into play, to gently ask the user which APN they > need :) > > ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: docs
On Thu, 2008-08-28 at 14:54 +0100, Robert Piasek wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > > Hi, > > I've created a tarball from trunk using "make dist". I compiled my > tarball without any extra configure options and it works well. > > During my next try I enabled --with-docs to my configure. it dies > complaining about missing files: > > make -j4 > make: *** No rule to make target `introspection/all.xml', needed by > `docs/spec.html'. Stop. > > After further investigation it seems none of all.xml, errors.xml, > generic-types.xml is included in Introspection/Makefile.am under > EXTRA_DIST. Thanks, r4023. Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: connection issue
On Wed, 2008-08-27 at 17:13 -0700, ben 123 wrote: > whenever i try to connect to any wireless network regardless of what > security it has i am unable to connect it attempts to connect to the > network but always goes back and asks for the password again what am i > missing > i have tried this on both fedora 9 and ubuntu right now im working > with ubuntu so i would like the help aimed as such What kernel version and what wireless hardware? Also, the fact that it's not working on both F9 (NM 0.7) and Ubuntu (NM 0.6.x) points to either driver/hardware problems or to wrong passwords/keys. Are you 100% sure the wireless keys you have are correct? Can we get some logs from /var/log/daemon.log to help diagnose the issue? Thanks! Dan ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
docs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I've created a tarball from trunk using "make dist". I compiled my tarball without any extra configure options and it works well. During my next try I enabled --with-docs to my configure. it dies complaining about missing files: make -j4 make: *** No rule to make target `introspection/all.xml', needed by `docs/spec.html'. Stop. After further investigation it seems none of all.xml, errors.xml, generic-types.xml is included in Introspection/Makefile.am under EXTRA_DIST. Attached patch. Regards, Rob -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJItq4RAAoJELvLB8ABrzqYHaUQAL9/KJTrbpJZMvDZZKu7fdZT pqTKFaINrhYrUh/VRn5yDVS82zfoNAN6E6IBFElodqGiKB88FNDj9l8FQEFuCoH/ 5dwiTJ7H37ThdTWl7IEi9dTE7tb2+QEABrXsItVdd4wxCF8318T9AJdHtzn2UbZJ BCL04OrNIVpENEZXOa0Mghhxp7wC/UTfD9OgPrJpJ48syUcOHGjk4BaH2Rn66HcT lmBxlRKguzAZ2M9/xgn+KFVMsGc3yRoBKhUrhOpxWpb6pomuYsVtONjGEljw8/Hz iIuqYWKGfzxBTZTPis9cE4b/rdtkUuFQVehjH3mWxz7MrkMgXJp5SWsdgNb2bWOV Zaf/Y+XbaCgUkV3Hqu9rVkR78NX7tSHRftoP2QKtXIMqjTRkOjXh8jM0gN2qJplW 8SrRFkDWPftkjFtn4CPRjUWfYbbIo+tuy9eGgVy85ANxEoYFyiQ5elHN0SpksQYi 76qGCgw2UmOu5AU38oUdC88UztW9YGwMK6BPv4vGUo+zjji1xTleqFhuF8YRvuTu 6UQx5yMz/lt9PyV/l+nNKfp8vv74onDBXmzsVyv/OHzbUE8Dcg5MsBv4O0sNfRh2 USaJc7v/mW8TySXk9o5BmtexzhxssqRgOWQIKww6nxLIcFO4NzOpAyZ/8RdxpNss 3n2bCcGjqjyLFqZfzuqX =OB8V -END PGP SIGNATURE- --- introspection/Makefile.am 2008-08-28 14:51:15.0 +0100 (rev 4022) +++ introspection/Makefile.am 2008-08-28 14:51:15.0 +0100 @@ -1,4 +1,8 @@ EXTRA_DIST = \ + all.xml \ + generic-types.xml\ + errors.xml \ + vpn-errors.xml \ nm-access-point.xml\ nm-device-wifi.xml \ nm-device-ethernet.xml \ doc.patch.sig Description: Binary data smime.p7s Description: S/MIME Cryptographic Signature ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Thu, Aug 28, 2008 at 12:21 PM, Tambet Ingo <[EMAIL PROTECTED]> wrote: > On Thu, Aug 28, 2008 at 10:48 AM, Pablo Martí <[EMAIL PROTECTED]> wrote: >> It seems that there's already some consensus, why don't you create a >> wiki page for all this and the interested parties finish the spec >> there? > > Yes, good idea. Wiki page is probably not the best format thought, > since I'd like to have the HTML automatically generated from the real > specifications. Not sure how to publish it. For now, it's attached. To > generate HTML, simply run 'make'. Pablo Martí found some small stylistic problems (GetIMEI and GetIMSI vs GetSmsc), which are fixed now (GetImei, GetImsi, GetSmsc). Tambet ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Thu, Aug 28, 2008 at 10:48 AM, Pablo Martí <[EMAIL PROTECTED]> wrote: > It seems that there's already some consensus, why don't you create a > wiki page for all this and the interested parties finish the spec > there? Yes, good idea. Wiki page is probably not the best format thought, since I'd like to have the HTML automatically generated from the real specifications. Not sure how to publish it. For now, it's attached. To generate HTML, simply run 'make'. Tambet modem-manager-spec.tar.gz Description: GNU Zip compressed data ___ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Wed, Aug 27, 2008 at 9:47 PM, Dan Williams <[EMAIL PROTECTED]> wrote:
> On Wed, 2008-08-27 at 19:07 +0300, Tambet Ingo wrote:
>> On Wed, Aug 27, 2008 at 6:17 PM, Pablo Martí <[EMAIL PROTECTED]> wrote:
>> > I can agree in this two. "AT+COPS?" is a pretty useful command that
>> > you've (inadvertently) banned here :), ditto with "At+COPS=?" and
>> > "AT+CPOL?" when you have a buggy firmware/old SIM that does strange
>> > things while roaming...
>>
>> Sorry, forgot to comment part of it: All the buggy firmware and
>> whatever other workarounds need to be hidden behind this API, not
>> exposed and delegated.
>
> _definitely_
It seems that there's already some consensus, why don't you create a
wiki page for all this and the interested parties finish the spec
there?
Regards,
>
> Dan
>
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print '706d6172746940776172702e6573'.decode('hex')"
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list
Re: [ANNOUNCE] ModemManager (for GSM and CDMA)
On Wed, Aug 27, 2008 at 6:02 PM, Dan Williams <[EMAIL PROTECTED]> wrote:
>>
>> I can agree in this two. "AT+COPS?" is a pretty useful command that
>> you've (inadvertently) banned here :), ditto with "At+COPS=?" and
>> "AT+CPOL?" when you have a buggy firmware/old SIM that does strange
>> things while roaming...
>
> COPS? seems like something we could make use of even when disconnected,
> but GetInfo() isn't a very descriptive name. It just returns the
> currently registered network, which is something that the applet might
> like to make use in the UI. However, it's unclear how you'd figure out
> when this changed unless you polled, right? So it might be something
> that the service should keep track of internally and then send out dbus
> signals when the associated operator changes. That way every app that
> might want to know about operator changes wouldn't need to poll the card
> itself.
Alright, the value could be cached every 60s and we could fire a
signal whenever it changes.
>
> CPOL sounds interesting; could you explain more? It might be useful to
> get a list of operators that are "preferred" to roam on when setting up
> the card, but I'm not sure.
at+cpol?
+CPOL: 1,2,"23415"
+CPOL: 2,2,"22210"
+CPOL: 3,2,"50503"
+CPOL: 4,2,"20810"
+CPOL: 5,2,"23003"
...
Yeah At+CPOL returns the list of MNCs your provider has agreements
with, most of the cards should use this info internally and you dont
need to mess with this list. Other cards cannot handle it and you
basically issue an "+COPS=?" and check that one of the operators
around are available in the +CPOL? list. Anyway this can be hidden
behind the Register(s netid) command that Tambet proposed.
>
> When in doubt, if there's a not a clear need for the command _right
> now_, it's best to leave it out. You can always add API; but changing
> and removing it is really hard once people start using your stuff.
True that
Regards,
>
> Dan
>
>> >
>> >> org.freedesktop.ModemManager.Modem.Gsm.PIN:
>> >> - Change(s oldpin, s newpin) ->
>> >> - Check() -> u (Returns the SIM auth state, to check it against an enum)
>> >> - Enable(s pin) ->
>> >> - Disable(s pin) ->
>> >> - Send(s pin) ->
>> >> - SendPUK(s puk, s pin) ->
>> >
>> > Not sure about these. Currently, Check() is part of
>> > Gsm.Card.Enable(True). Enable(pin)/Disable(pin) could be one method
>> > with a boolean argument. What's the difference (code wise) between
>> > Send() and SendPUK()? So that would leave us with 3 methods:
>> > Enable(bool), Send(string), Change(string, string). If so, maybe they
>> > can be part of the Gsm.Card interface?
>>
>> Enable(b) sounds good to me. The difference between Send and SendPUK
>> is that the former receives just one parameter (the pin), while the
>> later receives two, the puk and the new PIN to set in the card. One of
>> the advantages of having a separate interface is that CDMA devices
>> cant just skip the .PIN interface. Otherwise they'll support half of
>> .Card.
>> >
>> >
>> > For the following methods I don't have strong preferences because I've
>> > never used any of these features and thus don't have any hands on
>> > experience. I'd really appreciate if other interested parties
>> > (Telefonica?) could comment these.
>>
>> Yeah! Roberto?
>>
>> Best regards,
>>
>> >
>> >> org.freedesktop.ModemManager.Modem.Gsm.Contacts: Contact related
>> >> operations:
>> >> - Add(s name, s number) -> u
>> >> - Delete(u index) ->
>> >> - Find(s pattern) -> a(uss)
>> >> - Get(u index) -> (uss)
>> >> - GetPhonebookSize() -> u(Could be renamed to GetSize() ?)
>> >> - List() -> a(uss)
>> >
>> > Looks good to me.
>> >
>> >> org.freedesktop.ModemManager.Modem.Gsm.SMS: SMS related operations:
>> >> - Delete(u index) ->
>> >> - Get(u index) -> (ussd)(The last double is the time when it
>> >> was received)
>> >> - GetFormat() -> u (AT+CPBF?)
>> >> - GetSMSC() -> s
>> >> - List() -> a(ussd)
>> >> - Save(s text, s number) -> u
>> >> - Send -> u
>> >> - SendFromStorage(u index)
>> >> - SetFormat(u format) ->
>> >> - SetIndication(u mode, u mt, u bm, u ds, u bfr) ->
>> >> (AT+CNMI=mode,mt,..)
>> >> - SetSMSC(s smsc) ->
>> >>
>> >> - SMSReceived(u index, s where)(signal)
>> >>
>> >> This is just food for thought, what think about such an API the
>> >> different parties involved?
>> >> I've tried to clarify in parentheses all the methods that might be
>> >> misleading or might be controversial, with either its purpose or the
>> >> correspondent AT command. I think that standard interfaces such as
>> >> {SMS, Contacts}.{Delete, List, Get} should definitely go in. Other
>> >> methods (specially its naming) are somewhat more controversial and
>> >> I'll be happy to discuss 'em.
>> >>
>> >> I've attached this interfaces to the Gsm (WCDMA) part, we still need
>> >> to decide what to do with CDMA... Dan? :)
>> >
>> > Tambet
>> >
>>
>>
>>
>
>
--
Pablo Martí
http://www.linkedin.com/in/pmarti || http://www.warp.es
python -c "print
