Re: [PATCH] Enable dhcpcd instead of dhclient

[Michael Biebl]

Michael Biebl wrote:

Roy Marples wrote:

On Tue, 15 Jul 2008 15:29:43 +0100, Roy Marples <[EMAIL PROTECTED]> wrote:

Please apply this to NetworkManager :)


I don't quite like the configure bits yet. It forces you to have either 
dhclient or dhcpd installed for a successful build.


This effectively makes the dhcp client a build depenency.
This doesn't really matter for a (source-based) distro like gentoo, but 
on other distros, where the packages are built in a separate build 
environment this means, that you now have to install a dhcp client.


I'd say, if an absolute path is given (i.e. 
--with-dhcp-client=/sbin/dhclient), simply take this path and do no 
further checks. Imo it's safe to assume, if someone is using the 
configure flag this way, he knows what he's doing.


Also, if --with-dhcp-client is not set and the autodetection fails 
(because no dhcp client is installed), please fallback to

DHCP_CLIENT=dhclient and DHCP_CLIENT_PATH=/sbin/dhclient
to retain the old behaviour.

Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] Enable dhcpcd instead of dhclient

[Michael Biebl]

Roy Marples wrote:

On Tue, 15 Jul 2008 15:29:43 +0100, Roy Marples <[EMAIL PROTECTED]> wrote:

Please apply this to NetworkManager :)




I don't quite like the configure bits yet. It forces you to have either 
dhclient or dhcpd installed for a successful build.


This effectively makes the dhcp client a build depenency.
This doesn't really matter for a (source-based) distro like gentoo, but 
on other distros, where the packages are built in a separate build 
environment this means, that you now have to install a dhcp client.


I'd say, if an absolute path is given (i.e. 
--with-dhcp-client=/sbin/dhclient), simply take this path and do no 
further checks. Imo it's safe to assume, if someone is using the 
configure flag this way, he knows what he's doing.


Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] moving vpn helpers to libexecdir / vpn libs to $(libdir)/NetworkManager

[Michael Biebl]

Michael Biebl wrote:

Some of the vpn plugin binaries are in $(bindir), some in $(libexecdir).

The attached patch moves them all to $(libexecdir).

In addition it moves the libnm-*-properties.so modules to 
$(libdir)/NetworkManager. They are private modules imo and no system 
libraries.


And last, I cleaned up a few oddities, whenever I stumbled upon then 
(like target specific -g and -Wall flags).


Please review and apply.


I missed to update the pptp plugin. Although it currently isn't ported 
to the new API and doesn't build, I thought it would make sense to apply 
those changes to this plugin, too.


Updated patch attached.

Cheers,
Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Index: vpn-daemons/pptp/src/Makefile.am
===
--- vpn-daemons/pptp/src/Makefile.am	(Revision 3824)
+++ vpn-daemons/pptp/src/Makefile.am	(Arbeitskopie)
@@ -8,7 +8,6 @@
 	$(NETWORK_MANAGER_CFLAGS)\
 	$(PPPD_CFLAGS)		\
 	$(NM_VPN_CFLAGS)	\
-	-Wall			\
 	-DDBUS_API_SUBJECT_TO_CHANGE\
 	-DG_DISABLE_DEPRECATED	\
 	-DBINDIR=\"$(bindir)\"	\
@@ -18,10 +17,9 @@
 	-DLIBDIR=\""$(libdir)"\"\
 	-DLIBEXECDIR=\""$(libexecdir)"\"			\
 	-DLOCALSTATEDIR=\""$(localstatedir)"\"		 	\
-	-DDATADIR=\"$(datadir)\"\
-	-fPIC
+	-DDATADIR=\"$(datadir)\"
 
-bin_PROGRAMS = nm-ppp-starter
+libexec_PROGRAMS = nm-ppp-starter
 
 pppdplugindir = $(libexecdir)/pppd/$(PPPD_VERSION)
 pppdplugin_LTLIBRARIES = nm-pppd-plugin.la
Index: vpn-daemons/pptp/properties/Makefile.am
===
--- vpn-daemons/pptp/properties/Makefile.am	(Revision 3824)
+++ vpn-daemons/pptp/properties/Makefile.am	(Arbeitskopie)
@@ -1,9 +1,9 @@
+plugindir = $(libdir)/NetworkManager
 
+plugin_LTLIBRARIES = libnm-ppp-properties.la
 
-lib_LTLIBRARIES = libnm-ppp-properties.la
-
 libnm_ppp_properties_la_SOURCES = 			\
-nm-ppp-properties.c \
+nm-ppp-properties.c \
 vpnui_impl.c \
 vpnui_expand.c \
 vpnui_opt.c \
Index: vpn-daemons/pptp/Makefile.am
===
--- vpn-daemons/pptp/Makefile.am	(Revision 3824)
+++ vpn-daemons/pptp/Makefile.am	(Arbeitskopie)
@@ -11,10 +11,8 @@
 nmvpnservicedir = $(sysconfdir)/NetworkManager/VPN
 nmvpnservice_DATA = $(nmvpnservice_in_files:.name.in=.name)
 
-%.name: %.name.in Makefile
-	@sed -e "s|%bindir%|$(bindir)|g" \
-	 -e "s|%libdir%|$(libdir)|g" \
-	 -e "s|%libexecdir%|$(libexecdir)|g" $< > $@
+%.name: %.name.in
+	@sed -e 's|[EMAIL PROTECTED]@]|$(libexecdir)|g' $< > $@
 
 if WITH_GNOME
 desktopdir = $(datadir)/applications
Index: vpn-daemons/pptp/nm-ppp-starter.name.in
===
--- vpn-daemons/pptp/nm-ppp-starter.name.in	(Revision 3824)
+++ vpn-daemons/pptp/nm-ppp-starter.name.in	(Arbeitskopie)
@@ -1,8 +1,8 @@
 [VPN Connection]
 name=ppp
 service=org.freedesktop.NetworkManager.ppp_starter
[EMAIL PROTECTED]@/nm-ppp-starter
[EMAIL PROTECTED]@/nm-ppp-starter
 
 [GNOME]
[EMAIL PROTECTED]@/nm-ppp-auth-dialog
[EMAIL PROTECTED]@/${LIB}/libnm-ppp-properties
+auth-dialog=nm-ppp-auth-dialog
+properties=libnm-ppp-properties
Index: vpn-daemons/openvpn/nm-openvpn-service.name.in
===
--- vpn-daemons/openvpn/nm-openvpn-service.name.in	(Revision 3824)
+++ vpn-daemons/openvpn/nm-openvpn-service.name.in	(Arbeitskopie)
@@ -1,7 +1,7 @@
 [VPN Connection]
 name=openvpn
 service=org.freedesktop.NetworkManager.openvpn
[EMAIL PROTECTED]@/nm-openvpn-service
[EMAIL PROTECTED]@/nm-openvpn-service
 
 [GNOME]
 auth-dialog=nm-openvpn-auth-dialog
Index: vpn-daemons/openvpn/src/Makefile.am
===
--- vpn-daemons/openvpn/src/Makefile.am	(Revision 3824)
+++ vpn-daemons/openvpn/src/Makefile.am	(Arbeitskopie)
@@ -1,7 +1,6 @@
 AM_CPPFLAGS =			\
 	$(DBUS_CFLAGS)		\
 	$(NETWORK_MANAGER_CFLAGS)\
-	-Wall			\
 	-DDBUS_API_SUBJECT_TO_CHANGE\
 	-DG_DISABLE_DEPRECATED	\
 	-DBINDIR=\"$(bindir)\"	\
@@ -13,7 +12,7 @@
 	-DLOCALSTATEDIR=\""$(localstatedir)"\"		 	\
 	-DDATADIR=\"$(datadir)\"
 
-bin_PROGRAMS = nm-openvpn-service nm-openvpn-service-openvpn-helper
+libexec_PROGRAMS = nm-openvpn-service nm-openvpn-service-openvpn-helper
 
 nm_openvpn_service_SOURCES =\
 nm-openvpn-service.c	\
Index: vpn-daemons/openvpn/src/nm-openvpn-service.c
===
--- vpn-daemons/openvpn/src/nm-openvpn-service.c	(Revision 3824)
+++ vpn-daemons/openvpn/src/nm-openvpn-service.c	(Arbeitskopie)
@@ -53,7 +53,7 @@
 #include "nm-openvpn-service.h"
 #include "nm-utils.h"
 
-#define NM_OPENVPN_HELPER_PATH		BINDIR"/nm-openvpn-service-openvpn-helper"
+#define NM_OPENVPN_HELPER_PATH		LIBEXECDIR"/nm-openvpn-servic

[PATCH] moving vpn helpers to libexedir / vpn libs to $(libdir)/NetworkManager

[Michael Biebl]

Some of the vpn plugin binaries are in $(bindir), some in $(libexecdir).

The attached patch moves them all to $(libexecdir).

In addition it moves the libnm-*-properties.so modules to 
$(libdir)/NetworkManager. They are private modules imo and no system 
libraries.


And last, I cleaned up a few oddities, whenever I stumbled upon then 
(like target specific -g and -Wall flags).


Please review and apply.

Cheers,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Index: vpn-daemons/pptp/src/Makefile.am
===
--- vpn-daemons/pptp/src/Makefile.am	(Revision 3824)
+++ vpn-daemons/pptp/src/Makefile.am	(Arbeitskopie)
@@ -8,7 +8,6 @@
 	$(NETWORK_MANAGER_CFLAGS)\
 	$(PPPD_CFLAGS)		\
 	$(NM_VPN_CFLAGS)	\
-	-Wall			\
 	-DDBUS_API_SUBJECT_TO_CHANGE\
 	-DG_DISABLE_DEPRECATED	\
 	-DBINDIR=\"$(bindir)\"	\
@@ -19,9 +18,8 @@
 	-DLIBEXECDIR=\""$(libexecdir)"\"			\
 	-DLOCALSTATEDIR=\""$(localstatedir)"\"		 	\
 	-DDATADIR=\"$(datadir)\"\
-	-fPIC
 
-bin_PROGRAMS = nm-ppp-starter
+libexec_PROGRAMS = nm-ppp-starter
 
 pppdplugindir = $(libexecdir)/pppd/$(PPPD_VERSION)
 pppdplugin_LTLIBRARIES = nm-pppd-plugin.la
Index: vpn-daemons/pptp/properties/Makefile.am
===
--- vpn-daemons/pptp/properties/Makefile.am	(Revision 3824)
+++ vpn-daemons/pptp/properties/Makefile.am	(Arbeitskopie)
@@ -1,9 +1,9 @@
+plugindir = $(libdir)/NetworkManager
 
+plugin_LTLIBRARIES = libnm-ppp-properties.la
 
-lib_LTLIBRARIES = libnm-ppp-properties.la
-
 libnm_ppp_properties_la_SOURCES = 			\
-nm-ppp-properties.c \
+nm-ppp-properties.c \
 vpnui_impl.c \
 vpnui_expand.c \
 vpnui_opt.c \
Index: vpn-daemons/openvpn/nm-openvpn-service.name.in
===
--- vpn-daemons/openvpn/nm-openvpn-service.name.in	(Revision 3824)
+++ vpn-daemons/openvpn/nm-openvpn-service.name.in	(Arbeitskopie)
@@ -1,7 +1,7 @@
 [VPN Connection]
 name=openvpn
 service=org.freedesktop.NetworkManager.openvpn
[EMAIL PROTECTED]@/nm-openvpn-service
[EMAIL PROTECTED]@/nm-openvpn-service
 
 [GNOME]
 auth-dialog=nm-openvpn-auth-dialog
Index: vpn-daemons/openvpn/src/Makefile.am
===
--- vpn-daemons/openvpn/src/Makefile.am	(Revision 3824)
+++ vpn-daemons/openvpn/src/Makefile.am	(Arbeitskopie)
@@ -1,7 +1,6 @@
 AM_CPPFLAGS =			\
 	$(DBUS_CFLAGS)		\
 	$(NETWORK_MANAGER_CFLAGS)\
-	-Wall			\
 	-DDBUS_API_SUBJECT_TO_CHANGE\
 	-DG_DISABLE_DEPRECATED	\
 	-DBINDIR=\"$(bindir)\"	\
@@ -13,7 +12,7 @@
 	-DLOCALSTATEDIR=\""$(localstatedir)"\"		 	\
 	-DDATADIR=\"$(datadir)\"
 
-bin_PROGRAMS = nm-openvpn-service nm-openvpn-service-openvpn-helper
+libexec_PROGRAMS = nm-openvpn-service nm-openvpn-service-openvpn-helper
 
 nm_openvpn_service_SOURCES =\
 nm-openvpn-service.c	\
Index: vpn-daemons/openvpn/src/nm-openvpn-service.c
===
--- vpn-daemons/openvpn/src/nm-openvpn-service.c	(Revision 3824)
+++ vpn-daemons/openvpn/src/nm-openvpn-service.c	(Arbeitskopie)
@@ -53,7 +53,7 @@
 #include "nm-openvpn-service.h"
 #include "nm-utils.h"
 
-#define NM_OPENVPN_HELPER_PATH		BINDIR"/nm-openvpn-service-openvpn-helper"
+#define NM_OPENVPN_HELPER_PATH		LIBEXECDIR"/nm-openvpn-service-openvpn-helper"
 
 G_DEFINE_TYPE (NMOpenvpnPlugin, nm_openvpn_plugin, NM_TYPE_VPN_PLUGIN)
 
Index: vpn-daemons/openvpn/properties/Makefile.am
===
--- vpn-daemons/openvpn/properties/Makefile.am	(Revision 3824)
+++ vpn-daemons/openvpn/properties/Makefile.am	(Arbeitskopie)
@@ -1,7 +1,7 @@
+plugindir = $(libdir)/NetworkManager
 
+plugin_LTLIBRARIES = libnm-openvpn-properties.la
 
-lib_LTLIBRARIES = libnm-openvpn-properties.la
-
 libnm_openvpn_properties_la_SOURCES = \
 	nm-openvpn.c \
 	nm-openvpn.h \
Index: vpn-daemons/openvpn/Makefile.am
===
--- vpn-daemons/openvpn/Makefile.am	(Revision 3824)
+++ vpn-daemons/openvpn/Makefile.am	(Arbeitskopie)
@@ -22,10 +22,8 @@
 icon_DATA = gnome-mime-application-x-openvpn-settings.png
 endif
 
-nm-openvpn-service.name: $(srcdir)/nm-openvpn-service.name.in Makefile
-	sed	-e 's|[EMAIL PROTECTED]@]|$(bindir)|g' \
-		< $(srcdir)/nm-openvpn-service.name.in \
-		> nm-openvpn-service.name
+nm-openvpn-service.name: $(srcdir)/nm-openvpn-service.name.in
+	sed -e 's|[EMAIL PROTECTED]@]|$(libexecdir)|g' $< >$@
 
 EXTRA_DIST = nm-openvpn-service.name.in \
  $(dbusservice_DATA)  \
Index: vpn-daemons/vpnc/src/Makefile.am
===
--- vpn-daemons/vpnc/src/Makefile.am	(Revision 3824)
+++ vpn-daemons/vpnc/src/Makefile.am	(Arbeitskopie)

Re: 3G; wireless auth; policies; docs

[Dan Williams]

On Wed, 2008-07-16 at 17:53 -0300, [EMAIL PROTECTED] wrote:
> 
> Thanks for the quick answer. 
> 
> The --with-docs tag worked but spec.html is generated only when I run
> 'make' for 
> the second time. In the first time it gives me this error and stops
> the compilation: 
> 
> """ 
> xsltproc --xinclude --nonet tools/doc-generator.xsl
> introspection/all.xml > docs/spec.html 
> ERR: Unable to find type 'NM_DEVICE_STATE_REASON' 
> make: *** [docs/spec.html] Error 10 
> """ 

Good catch, I need to update the docs for state reasons.

> 
> Also, the spec file generated has few methods/signals ... only for
> interfaces org.freedesktop.NetworkManager, 
> org.freedesktop.NetworkManager.AccessPoint and
> org.freedesktop.NetworkManager.Device. Is this right ? 

No, sounds wrong.  I'll look into it.

> I know that documentation is not the major priority now, but I'm
> looking for a way to make Network Manager 
> connects to a given wireless (SSID). Any ideas ? 

A pointer would be cnetworkmanager, or the applet itself.  Will this
functionality be run concurrently with nm-applet, or are you looking to
replace nm-applet?  Are you by chance implementing the "Connect" button
in the connection editor for Grant or John W.? :)

Dan

> Thanks 
> 
> Rodrigo Trujillo 
> 
> 
> 
> From: 
> Dan Williams <[EMAIL PROTECTED]> 
> To: 
> [EMAIL PROTECTED] 
> Cc: 
> networkmanager-list@gnome.org 
> Date: 
> 07/16/2008 04:58 PM 
> Subject: 
> Re: 3G; wireless auth; policies;
> docs
> 
> 
> __
> 
> 
> 
> On Wed, 2008-07-16 at 16:26 -0300, [EMAIL PROTECTED] wrote:
> > 
> > Where is the spec.html file ??
> > I could not find or generate it. 
> 
> If you run configure or autogen.sh with --with-docs you should get a
> generated spec.html after the build is done.
> 
> 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: 3G; wireless auth; policies; docs

[rotru]

Thanks for the quick answer.

The --with-docs tag worked but spec.html is generated only when I run 
'make' for
the second time. In the first time it gives me this error and stops the 
compilation:

"""
xsltproc --xinclude --nonet tools/doc-generator.xsl introspection/all.xml 
> docs/spec.html
ERR: Unable to find type 'NM_DEVICE_STATE_REASON'
make: *** [docs/spec.html] Error 10
"""


Also, the spec file generated has few methods/signals ... only for 
interfaces org.freedesktop.NetworkManager,
org.freedesktop.NetworkManager.AccessPoint and 
org.freedesktop.NetworkManager.Device. Is this right ?

I know that documentation is not the major priority now, but I'm looking 
for a way to make Network Manager
connects to a given wireless (SSID). Any ideas ?

Thanks

Rodrigo Trujillo




From:
Dan Williams <[EMAIL PROTECTED]>
To:
[EMAIL PROTECTED]
Cc:
networkmanager-list@gnome.org
Date:
07/16/2008 04:58 PM
Subject:
Re: 3G; wireless auth; policies; docs



On Wed, 2008-07-16 at 16:26 -0300, [EMAIL PROTECTED] wrote:
> 
> Where is the spec.html file ??
> I could not find or generate it. 

If you run configure or autogen.sh with --with-docs you should get a
generated spec.html after the build is done.

Dan



___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: 3G; wireless auth; policies; docs

[Dan Williams]

On Wed, 2008-07-16 at 16:26 -0300, [EMAIL PROTECTED] wrote:
> 
> Where is the spec.html file ??
> I could not find or generate it. 

If you run configure or autogen.sh with --with-docs you should get a
generated spec.html after the build is done.

Dan

> 
> Thanks 
> 
> Rodrigo Trujillo 
> 
> 
> From: 
> Dan Williams <[EMAIL PROTECTED]> 
> To: 
> Jens-Michael Hoffmann
> <[EMAIL PROTECTED]> 
> Cc: 
> Alexey Dumov <[EMAIL PROTECTED]>,
> networkmanager mailing list
> ,
> Ferenc Sos <[EMAIL PROTECTED]> 
> Date: 
> 07/03/2008 06:19 PM 
> Subject: 
> Re: 3G; wireless auth; policies;
> docs
> 
> 
> __
> 
> 
> 
> On Thu, 2008-07-03 at 13:14 +0200, Jens-Michael Hoffmann wrote:
> > Hi,
> > 
> > first of all let me thank you for your great work and
> NetworkManager.
> 
> Great to see your interest.  I'd like to ensure that Option cards work
> as well as possible with NetworkManager.
> 
> > We are currently evaluating NetworkManager and would like to ask
> some
> > questions:
> > 
> > What is the status of support for 3G devices?
> 
> We have fairly basic support for connecting, disconnecting, setting
> APN,
> PIN/PUK handling, username, password, etc.  Planned support includes
> band preference, roaming preference, etc.  I'd like to implement
> rfkill
> as well but we really do need a standard kernel interface for that
> which
> would live in the 'option' driver in the kernel and hook into the WWAN
> rfkill functionality in 2.6.26 and later.
> 
> > How and where are policies (like choose wired over wireless)
> implemented?
> 
> It's fairly basic right now.  But I'm certainly willing to discuss
> more
> flexible priority handling
> 
> > Is it possible to do connect on demand with NetwokManager?
> 
> Not at this time, I need to figure out how that's supposed to work.
> ISTR it involves creating a 'fake' network device and having userspace
> hooks called whenever something starts sending out traffic or bringing
> the device up, but I actually have no idea.  Definitely something I
> want
> to support though.
> 
> > How is the wireless authentication stuff (WEP/WPA/WPA2) handled?
> > Are there callbacks to get the keys or any other mechanism?
> 
> Yes.  When NM (or the user) wishes to connect to a wireless network
> and
> does not have the required authentication secrets for that network, it
> will ask the daemon that provides that connection.  This is either the
> system settings daemon (nm-system-settings) or the applet running in
> the
> user's session (nm-applet or knetworkmanager).  If the settings deamon
> does not have the secrets required, it will ask the user for them.
> 
> > Is there any kind of documentation apart from the generated
> spec.html?
> > We are especially looking for developer documentation.
> 
> At this time the documentation consists of the generated spec.html,
> which is really only useful if you are intending to write your own
> front-end to NetworkManager (talking over D-Bus of course).  You could
> also use libnm-glib which provides an object-oriented wrapper around
> the
> dbus interface.
> 
> I will be adding doxygen/gtkdoc a bit later this summer to libnm-util
> and libnm-glib, but in the mean time, both Tambet and I would be quite
> happy to answer any questions you might have.
> 
> The D-Bus and libnm-glib APIs are not _quite_ final yet, but they are
> pretty darn close and I don't expect them to change much.  The one
> change I will be making quite soon is using IPv4 prefixes instead of
> IPv4 netmasks through out the API and the UI.
> 
> Dan
> 
> > 
> > Best regards
> > 
> > Jens-Michael Hoffmann
> > ___
> > 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
> 
> 
> ___
> 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: 3G; wireless auth; policies; docs

[rotru]

Where is the spec.html file ??
I could not find or generate it.


Thanks

Rodrigo Trujillo



From:
Dan Williams <[EMAIL PROTECTED]>
To:
Jens-Michael Hoffmann <[EMAIL PROTECTED]>
Cc:
Alexey Dumov <[EMAIL PROTECTED]>, networkmanager mailing list 
, Ferenc Sos <[EMAIL PROTECTED]>
Date:
07/03/2008 06:19 PM
Subject:
Re: 3G; wireless auth; policies; docs



On Thu, 2008-07-03 at 13:14 +0200, Jens-Michael Hoffmann wrote:
> Hi,
> 
> first of all let me thank you for your great work and NetworkManager.

Great to see your interest.  I'd like to ensure that Option cards work
as well as possible with NetworkManager.

> We are currently evaluating NetworkManager and would like to ask some
> questions:
> 
> What is the status of support for 3G devices?

We have fairly basic support for connecting, disconnecting, setting APN,
PIN/PUK handling, username, password, etc.  Planned support includes
band preference, roaming preference, etc.  I'd like to implement rfkill
as well but we really do need a standard kernel interface for that which
would live in the 'option' driver in the kernel and hook into the WWAN
rfkill functionality in 2.6.26 and later.

> How and where are policies (like choose wired over wireless) 
implemented?

It's fairly basic right now.  But I'm certainly willing to discuss more
flexible priority handling

> Is it possible to do connect on demand with NetwokManager?

Not at this time, I need to figure out how that's supposed to work.
ISTR it involves creating a 'fake' network device and having userspace
hooks called whenever something starts sending out traffic or bringing
the device up, but I actually have no idea.  Definitely something I want
to support though.

> How is the wireless authentication stuff (WEP/WPA/WPA2) handled?
> Are there callbacks to get the keys or any other mechanism?

Yes.  When NM (or the user) wishes to connect to a wireless network and
does not have the required authentication secrets for that network, it
will ask the daemon that provides that connection.  This is either the
system settings daemon (nm-system-settings) or the applet running in the
user's session (nm-applet or knetworkmanager).  If the settings deamon
does not have the secrets required, it will ask the user for them.

> Is there any kind of documentation apart from the generated spec.html?
> We are especially looking for developer documentation.

At this time the documentation consists of the generated spec.html,
which is really only useful if you are intending to write your own
front-end to NetworkManager (talking over D-Bus of course).  You could
also use libnm-glib which provides an object-oriented wrapper around the
dbus interface.

I will be adding doxygen/gtkdoc a bit later this summer to libnm-util
and libnm-glib, but in the mean time, both Tambet and I would be quite
happy to answer any questions you might have.

The D-Bus and libnm-glib APIs are not _quite_ final yet, but they are
pretty darn close and I don't expect them to change much.  The one
change I will be making quite soon is using IPv4 prefixes instead of
IPv4 netmasks through out the API and the UI.

Dan

> 
> Best regards
> 
> Jens-Michael Hoffmann
> ___
> 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


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Simple connect feature for xl2tpd

[Dan Williams]

On Wed, 2008-07-16 at 12:11 +0300, Tambet Ingo wrote:
> On Tue, Jul 15, 2008 at 7:27 PM, David Smith <[EMAIL PROTECTED]> wrote:
> > Dan, how set are you on using NSS? I believe this job is better fit for
> > just supporting PKCS#11 in NM and making nm-applet use gnome-keyring's
> > PKCS#11 interface by default. Using just PKCS#11 is a much lighter
> > dependency and far simpler design. Also, using NSS in NM would require
> > it to be integrated in the supplicant, but wpasupplicant already
> > supports PKCS#11.
> 
> I'm very excited about these patches and I definitely would like to
> see it finished (the applet part). Much better to have it now rather
> than ideas how to do it differently later. Plus, NSS backend for
> gnome-keyring is in their todo list.

The NSS bits were mainly a hand-wavy future thing.  The only thing we
use NSS for right now is parsing and decoding the certificates and
private keys, and passing that information to wpa_supplicant which then
feeds the binary data down to openssl, which actually does the work.
I'd have to write an NSS backend for wpa_supplicant (just like there's
an openssl backend) to fully support NSS, and then in this case the
applet would just pass down the tokens/pointers to the certificates in
the NSS cert database.

Basically, it's a _very_ good thing to store all the certificates and
keys in one place, to have the supplicant/openswan read all necessary
certificates from the same place, and not to have to have certs
scattered all over your drive.  Just tell the applet what the pointer to
the certificate in whatever database (NSS or otherwise) is, and hand
that off to the thing that actually needs it.  Then I wouldn't have to
care about parsing certs and keys manually and shoving big blobs of
binary data through D-Bus.

At the moment, any of that is going to be a ways off, and thus I'm fine
with a sane PKCS#11 implementation in NM and the applet.  I just haven't
had the time quite yet to go review those patches.

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: System Setting - Wireless - WPA - and Fedora 9

[Dan Williams]

On Wed, 2008-07-16 at 10:26 +0300, Tambet Ingo wrote:
> On Tue, Jul 15, 2008 at 8:43 PM, Dan Williams <[EMAIL PROTECTED]> wrote:
> > Hmm, could be that the encryption key didnt work the first time.  We
> > really should implement get_secrets() for keyfile though.  That's the
> > problem here.
> 
> Why? Why would it succeed later if it failed initially? When the
> keyfile configuration changes, it's re-read automatically, including
> all the secrets. If reading WPA-EAP secrets does not work, that needs
> to be fixed, just providing another function that will fail the same
> way won't fix anything.

Yeah, based on the analysis here (thanks!) my original interpretation
was wrong.  Since this is a _system_ connection, there's no way we can
bring up a dialog, because the secrets are required to exist already.
We do have a bit of fixup in the connection editor to ensure that things
are properly disabled/enabled based on whether the connection is valid
or not.

Dan

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] Enable dhcpcd instead of dhclient

[Dan Williams]

On Tue, 2008-07-15 at 15:34 +0100, Roy Marples wrote:
> On Tue, 15 Jul 2008 15:29:43 +0100, Roy Marples <[EMAIL PROTECTED]> wrote:
> > Please apply this to NetworkManager :)
> 
> LOL - here is the patch :)

The addition of the IPv4LL state is just for completeness, right?  All
IPv4LL addressing is handled by avahi-autoipd now, and DHCP won't even
be run when the user wants an IPv4LL address for the interface.  I
didn't see any code actually using the IPv4LL state so it should be OK
though.  Other than that, looks good to me.

Dan


___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Usability issues with 0.7 / Ideas for next release.

[Daniel Espinosa]

2008/7/8 Dan Williams <[EMAIL PROTECTED]>:

> On Tue, 2008-07-08 at 14:45 +0200, Patrick wrote:
> > While the improved 3G and vpn capabilities are nice there are a few
> > small issues that could be addressed to improve the next version
> > (0.7.?)...
> >
> > 1. Would be nice if NM with the right packages installed could handle
> > pand connections to simplify connecting to the internet via bluetooth
> > devices.
>
> Right, BT support will come post-0.7.  First for DUN, then for PAN.
>
> > 2. If one has a wired connection then its really hard to switch to a
> > wireless one without unplugging the cat5 or usb connection. It'd be
> > better if it was as easy as point n click.
>
> You can certainly bring up the wired interface, but the default route
> will stay on the wired device because it's plugged in.  I'm not sure I
> see a good use-case here... you'd be connected to wireless after picking
> it from the menu, so you'd be able to access anything on that network
> already.
>

In some cases you can have a wired office connection to corporate network
and a wireless connection to a public network may you want to use (may you
have a movil internet connection), then is useful to switch between
interfaces.

>
> > 3. Having the user choose what type on encryption the network uses when
> > entering the password isn't of much use,  most users don't know the
> > first thing about encryption, it could be automatic. (works in win:()
>
> This is also a common request.  As another data point, Mac OS X requires
> you to choose WEP key types just like NM does.  Most vendor tools from
> D-Link, Linksys, etc that don't use WZC also make you choose.
>
> The right solution is to try successive key permutations quickly, but we
> can't do that easily.  First, drivers suck.  Second, the kernel API for
> wireless isn't conducive to this and doesn't give enough feeback to make
> it work.  Third, with WEP you simply don't know whether the key is right
> or not until a DHCP attempt has timed out, which can take 45 seconds.
> So taking up to 2 minutes to connect to a network just sucks.
>
> The fundamental problem is that both WEP ASCII and Hex key types overlap
> with the WEP passphrase type.  Most places use passphrases.  But I've
> personally seen places that use a what _looks_ like a hex key as a WEP
> passphrase.
>


Why don't select the most common one; may be this could be a setting may for
different contries and distribution selection.

Taking 45 seconds to connect automatically to the most common encription is
great; and if it fails then ask for encription type.


-- 
Trabajar, la mejor arma para tu superación
"de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates:
LIBRE)
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] Enable dhcpcd instead of dhclient

[Roy Marples]

On Wed, 16 Jul 2008 12:33:43 +0300, "Tambet Ingo" <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 15, 2008 at 5:34 PM, Roy Marples <[EMAIL PROTECTED]> wrote:
>> On Tue, 15 Jul 2008 15:29:43 +0100, Roy Marples <[EMAIL PROTECTED]>
> wrote:
>>> Please apply this to NetworkManager :)
>>
>> LOL - here is the patch :)
> 
> The patch looks good to me, just a small nitpick, the configure script
> should work without needing to always provide --with-dhcp-client flag
> and default to dhclient. Also, please forgive my ignorance, are the
> environment variables in the dhcpcd script identical to the ones in
> dhclient?

The configure script does not need --with-dhcp-client.
If not given, it will attempt to find a suitable dhcp client, defaulting
to dhcpcd if both are found. If neither or found, or the client specified
is not suitable then an error is emitted.
The environment variables are 100% identical.
If not, the it's a bug with dhcpcd which will be fixed.

Thanks

Roy

___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] Enable dhcpcd instead of dhclient

[Tambet Ingo]

On Tue, Jul 15, 2008 at 5:34 PM, Roy Marples <[EMAIL PROTECTED]> wrote:
> On Tue, 15 Jul 2008 15:29:43 +0100, Roy Marples <[EMAIL PROTECTED]> wrote:
>> Please apply this to NetworkManager :)
>
> LOL - here is the patch :)

The patch looks good to me, just a small nitpick, the configure script
should work without needing to always provide --with-dhcp-client flag
and default to dhclient. Also, please forgive my ignorance, are the
environment variables in the dhcpcd script identical to the ones in
dhclient?

Tambet
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Simple connect feature for xl2tpd

[Tambet Ingo]

On Tue, Jul 15, 2008 at 7:27 PM, David Smith <[EMAIL PROTECTED]> wrote:
> Dan, how set are you on using NSS? I believe this job is better fit for
> just supporting PKCS#11 in NM and making nm-applet use gnome-keyring's
> PKCS#11 interface by default. Using just PKCS#11 is a much lighter
> dependency and far simpler design. Also, using NSS in NM would require
> it to be integrated in the supplicant, but wpasupplicant already
> supports PKCS#11.

I'm very excited about these patches and I definitely would like to
see it finished (the applet part). Much better to have it now rather
than ideas how to do it differently later. Plus, NSS backend for
gnome-keyring is in their todo list.

Tambet
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: System Setting - Wireless - WPA - and Fedora 9

[Tambet Ingo]

On Tue, Jul 15, 2008 at 8:43 PM, Dan Williams <[EMAIL PROTECTED]> wrote:
> Hmm, could be that the encryption key didnt work the first time.  We
> really should implement get_secrets() for keyfile though.  That's the
> problem here.

Why? Why would it succeed later if it failed initially? When the
keyfile configuration changes, it's re-read automatically, including
all the secrets. If reading WPA-EAP secrets does not work, that needs
to be fixed, just providing another function that will fail the same
way won't fix anything.

Tambet
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list