Re: Network Manager does not find system wide connections

[Hadmut Danisch]

Hi,


Dan Williams wrote:

> Depends on your point of view; yes, more comments and explanation of
> theory are needed (especially in the public API).  But the processes are
> also quite complex, and a familiarity with GObject and some of the
> technologies used (PolicyKit, GObject, dbus-glib) is assumed.


Well, my point of view is being a Unix/Linux user and admin for about
20 years. And from my point of view it is the wrong way to construct
such important software for basic functions such as network connectivity
in such a complex way that it is impossible to figure out a problem
with a simple strace call.

The problems with the opaque and unpredictable nature of network manager
and the lack of documentation and debugging functions do not qualify
nm as a tool for basic functions of the operating system in my eyes.




> You'll want to start looking in the keyfile's
> system-settings/plugins/keyfile/plugin.c dir_changed() function.  That
> function is called whenever inotify sees new files or changes in the
> config directory.  Does that function get called when the new file
> appears there?  Since the new keyfile appears at all, I assume that
> means the keyfile plugin is loaded (otherwise nothing would get written
> to that directory in the first place).
> 
> Eventually this code will be triggered in dir_chagned():
> 
>   /* New */
>   connection = nm_keyfile_connection_new (name);
>   if (connection) {
>   NMConnection *tmp;
>   NMSettingConnection *s_con;
>   const char *connection_uuid;
>   NMKeyfileConnection *found = NULL;


I'll try that later this week. I'm busy today.



> Any chance you could dig down a bit more to see what's going on?  Even
> just setting a breakpoint on dir_changed() would be useful to ensure
> it's getting triggered when a new keyfile gets created there.

I'll do that, gimme some time.

regards
Hadmut


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

Re: howto ignore rfkill switch

[Cedric Pradalier]

On Mon, Jul 27, 2009 at 8:15 PM, Dan Williams  wrote:

> On Mon, 2009-07-27 at 20:02 +0200, Marcel Holtmann wrote:
> > Hi Dan,
> >
> > > > Well, actually in the case of the OP, the switch has nothing to do
> > > > with the PCMCIA card, and the card is still on, available and
> > > > configurable by hand (iwconfig, ifconfig) when the switch is off. It
> > > > is just NM that decides to disable all wireless possibility even if
> > > > the switch concerns only the internal card.
> > >
> > > You've flipped the rfkill switch, thus you do not want to use wifi.  If
> > > you do actually want to use wifi, there are other, better mechanisms to
> > > just kill the card you don't want to use.  rfkill is *not* the
> mechanism
> > > to disable a specific card completely.
> >
> > it actually is the right way to kill a specific WiFi card. It is not
> > that useful if you have platform switches in your system that interact
> > with hotplug, but RFKILL works on a per device and all devices basis. At
> > least the re-write coming with 2.6.31 does this correctly.
>
> Most of the people trying to use two cards are doing so because they
> never want to use the internal one.  There are better ways of handling
> this (blacklisting, etc) *at this time* than using rfkill.  Yes, 2.6.31
> will work better here.  Half the reason NM elected to use global rfkill
> was because the kernel interfaces sucked up until now.
>
> Dan
>
> > The hardware RFKILL button/switch on your laptop needs to be tied into a
> > userspace policy to decide what to do with external devices. That is out
> > of the scope of the Linux kernel.
> >
> > Regards
> >
> > Marcel
> >
> >
>
>
Just to remind the original post. We don't WANT to use the RFKILL switch. It
is somehow dodgy on this laptop and it switches itself on and off when you
move the screen or put your hands on the palm rest.
The original question was: is it possible to make NM ignore it? because we
KNOW it is not a reliable indication of what the user wants to do.

Anyway, thanks for all the useful answers so far on this thread.

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

Re: [PATCH] nm-applet: Restore PEAP settings

[Dan Williams]

On Mon, 2009-07-27 at 21:03 +0400, Mikhail Efremov wrote:
> Hello!
> 
> Based on code in other eap-method-*.c

Pushed, thanks!

c69ddb598e85094bca59b983ff46f53aa9f8b1d7

Dan

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

Re: [PATCH] nm-applet: wrong index in eap-method-ttls.c

[Dan Williams]

On Mon, 2009-07-27 at 20:56 +0400, Mikhail Efremov wrote:
> Hello!
> 
> CHAP method has index 3, not 4.

Pushed, thanks!

ee7f2dc9ffa47c2e2eefb33c1370b037fbc2ecc8

Dan


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

Re: Network Manager does not find system wide connections

[Dan Williams]

On Sat, 2009-07-25 at 01:13 +0200, Hadmut Danisch wrote:
> Hi,
> 
> maybe someone can give me a hint about where to start debugging:
> 
> I am using Ubuntu 9.04 on several machines. On some machines Network
> Manager works as expected when making connections system wide available
> with the connection editor: It puts a file into
> /etc/NetworkManager/system-connections. When starting
> nm-connection-editor, they appear as connections, and they can be used
> as normal.
> 
> But then on two of my machines this does not work. When setting
> connections to system wide availability, it puts a file into
> /etc/NetworkManager/system-connections as well, but then does not find
> it again, as if the file would not exist. Network connections are not
> configured, and nm-connection-editor does not find it (i.e. does not
> display the connection).
> 
> I wrote a little tool to fetch connections from dbus. It works on those
> machines where nm works, but it returns an emtpy list of connections on
> those machines where it doesn't.
> 
> debugging with strace showed that nm-system-connections does not look at
> all into /etc/NetworkManager/system-connections at all. Reading the
> source code is almost pointless, highly complex without any comments,
> source code of the quality 'virtually unreadable'.

Depends on your point of view; yes, more comments and explanation of
theory are needed (especially in the public API).  But the processes are
also quite complex, and a familiarity with GObject and some of the
technologies used (PolicyKit, GObject, dbus-glib) is assumed.

You'll want to start looking in the keyfile's
system-settings/plugins/keyfile/plugin.c dir_changed() function.  That
function is called whenever inotify sees new files or changes in the
config directory.  Does that function get called when the new file
appears there?  Since the new keyfile appears at all, I assume that
means the keyfile plugin is loaded (otherwise nothing would get written
to that directory in the first place).

Eventually this code will be triggered in dir_chagned():

/* New */
connection = nm_keyfile_connection_new (name);
if (connection) {
NMConnection *tmp;
NMSettingConnection *s_con;
const char *connection_uuid;
NMKeyfileConnection *found = NULL;


which creates a new keyfile connection from the file.  It would be
useful to see if 'connection' is NULL after this, which indicates an
invalid file format, whcih would indicate a bug in the keyfile code.

Any chance you could dig down a bit more to see what's going on?  Even
just setting a breakpoint on dir_changed() would be useful to ensure
it's getting triggered when a new keyfile gets created there.

Dan


> I still could not figure out what makes the difference between those
> machines where it works and those where it doesn't.
> 
> Any idea or hint?
> 
> regards
> Hadmut
> ___
> 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: nm-connection-editor unable to create system connection, returning "The connection could not be added due to an unknown error."

[Dan Williams]

On Thu, 2009-07-23 at 20:52 -0400, Rodney Morris wrote:
> When using nm-connection-editor to add a system connection,
> nm-connection-editor fails create the system connections,  responding
> that "The connection could not be added due to an unknown error."  I
> am using F10 x86_64 and NetworkManager-0.7.1-1.fc10.x86_64.
> 
> When run from a terminal window, nm-connection-editor outputs the
> following to the terminal when adding a system connection:
> 
> (nm-connection-editor:3174): GLib-GObject-WARNING **: instance of
> invalid non-instantiatable type
> `(null)'  

So the best way to figure this out is to
'gdb /usr/bin/nm-connection-editor', then 'r' to run until you are about
to check the "Available to all users" box.  At that point, Ctrl+C in the
gdb window, and type "break g_log", then "c" to continue.  Then do
whatever you need to do to trigger the bug.  When the breakpoint
triggers, type "bt" to get a backtrace (hit enter if it asks to keep
listing the backtrace), then "c" to continue until the next warning, and
repeat this for each warning until you're sure you've passed these two.
Mail the output from gdb so we can figure out what's going on.

Thanks,
Dan

> (nm-connection-editor:3174): GLib-GObject-CRITICAL **:
> g_signal_handlers_unblock_matched: assertion `G_TYPE_CHECK_INSTANCE
> (instance)' failed   
> 
> ** (nm-connection-editor:3174): CRITICAL **:
> nm_connection_editor_get_window: assertion `NM_IS_CONNECTION_EDITOR
> (editor)' failed
> 
> Below is my nm-system-settings.conf:
> 
> [main]
> plugins=ifcfg-rh, keyfile
> 
> The "system-connections" directory exists in /etc/NetworkManager.  The
> log files contain nothing from this error.
> 
> Has anyone encountered this error?  Any thoughts on what I am doing
> wrong?
> 
> Thanks in advance for any help in resolving this mystery,
> 
> Rod
> 
> 
> 
> 
> ___
> 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: vpn pptp reconnect feature

[Dan Williams]

On Fri, 2009-07-24 at 13:41 +0200, Henrik Johansson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> I guess i emailed before reading up in the bugzilla...
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=349151

Yeah, this has been brought up a lot before, and it's also on the list
of stuff that should be done sooner rather than later.  There are a few
complications here.

First, NM's architecture is not built to suppress announcement of "I'm
connected to the internet" until the VPN is up; but often that's the
wrong approach, because many VPNs only secure a *specific* IP route,
they dont' secure the entire machine.  So in reality, applications that
care about security (say you don't want your IRC login details broadcast
over a coffee shop wifi) need to be smart enough to know when the
resource they need (ie, the server) is secure.

As a concrete example, our work VPN at Red Hat does not route all
internet traffic, thus only redhat stuff goes over the VPN.  It's not
possible to route all traffic over the VPN, thus it's up to the
applications to ensure they use secure methods of connecting to their
resources/servers.  In this case, suppressing the "I'm connected to the
internet" message that NM broadcasts until the VPN is also up would be
useless.

Next, we need to implement the config bits to tie the VPN connection and
the "base" connection together, so that the VPN gets activated when the
base connection does.  I'm not entirely sure whether the VPN should
contain the references to the base connection, or whether the base
connections should contain the reference to the VPN.

Next need the UI bits in the connection editor dialogs to let you pick
what gets tied to what.

A completely separate issue is making sure the VPN gets re-tried on
failure.  A complication with this is methods that have
one-time-passwords or require further user input, because the user wont'
necessarily be around to re-enter their password.  We probably have to
take the entire connection down (including the "base" wired/wifi/3g
connection) if the VPN connection is tied to that base connection,
because you're expecting the VPN to be up whenever that base connection
is up, and thus we can't leave things connected when the VPN isn't
working.

Dan

> 
> +1 for the "dial this connection first" as well.
> 
> 
> 
> Rick Jones wrote:
> | --On Thursday, July 23, 2009 15:04:13 -0400 Dan Williams 
>  wrote:
> | ¦
> | ¦ Yeah, reconnect of a failed connection (as opposed to a
> | ¦ user-disconnected one) is definitely on the list.  I was planning on
> | ¦ doing some of the work for that in the 'inhibit' branch in git, so you
> | ¦ can track that there.  It won't be VPN-specific at first, but the
> | ¦ changes there will help out the VPN stuff too.
> |
> | A useful feature for VPN config which is kinda related, would be the 
> ability to define a preferred real connection to carry the VPN. Then you 
> would be able to just request VPN connection in NM and it would first 
> establish the underlying connection.
> |
> | Windows has a feature like this in the form of "dial this connection 
> first" in the VPN setup dialog.
> |
> | I'm just thinking that having such a mechanism might also help with 
> managing the VPN auto-reconnect case.
> |
> | Just a thought...
> |
> | -
> |
> | ___
> | NetworkManager-list mailing list
> | NetworkManager-list@gnome.org
> | http://mail.gnome.org/mailman/listinfo/networkmanager-list
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkppneYACgkQXtSockw5x6yLtwCdHN3g89+0q1wmJvI3L/TvNBV6
> PXgAn1bknUV+KJeBaRz1XKOU/c9RUw0r
> =9IG7
> -END PGP SIGNATURE-
> 

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

Re: howto ignore rfkill switch

[Dan Williams]

On Mon, 2009-07-27 at 20:02 +0200, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > Well, actually in the case of the OP, the switch has nothing to do
> > > with the PCMCIA card, and the card is still on, available and
> > > configurable by hand (iwconfig, ifconfig) when the switch is off. It
> > > is just NM that decides to disable all wireless possibility even if
> > > the switch concerns only the internal card.
> > 
> > You've flipped the rfkill switch, thus you do not want to use wifi.  If
> > you do actually want to use wifi, there are other, better mechanisms to
> > just kill the card you don't want to use.  rfkill is *not* the mechanism
> > to disable a specific card completely.
> 
> it actually is the right way to kill a specific WiFi card. It is not
> that useful if you have platform switches in your system that interact
> with hotplug, but RFKILL works on a per device and all devices basis. At
> least the re-write coming with 2.6.31 does this correctly.

Most of the people trying to use two cards are doing so because they
never want to use the internal one.  There are better ways of handling
this (blacklisting, etc) *at this time* than using rfkill.  Yes, 2.6.31
will work better here.  Half the reason NM elected to use global rfkill
was because the kernel interfaces sucked up until now.

Dan

> The hardware RFKILL button/switch on your laptop needs to be tied into a
> userspace policy to decide what to do with external devices. That is out
> of the scope of the Linux kernel.
> 
> Regards
> 
> Marcel
> 
> 

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

NM ignores Motorola Q phone

[Tony Seward]

I'm trying to connect to the internet via my Motorola Q phone MediaNet
data plan.

I am running Fedora 11

When I plug in my phone with a USB cable, I get the following log
entries

Jul 27 11:46:13 florete kernel: usb 5-1: new full speed USB device using 
uhci_hcd and address 7
Jul 27 11:46:13 florete kernel: usb 5-1: New USB device found, idVendor=22b8, 
idProduct=4221
Jul 27 11:46:13 florete kernel: usb 5-1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=3
Jul 27 11:46:13 florete kernel: usb 5-1: Product: Motorola USB Remote NDIS 
Network Device
Jul 27 11:46:13 florete kernel: usb 5-1: Manufacturer: Motorola Inc
Jul 27 11:46:13 florete kernel: usb 5-1: SerialNumber: 
Jul 27 11:46:13 florete kernel: usb 5-1: configuration #1 chosen from 1 choice
Jul 27 11:46:13 florete kernel: rndis_host 5-1:1.0: RNDIS_MSG_QUERY(0x00010202) 
failed, -47
Jul 27 11:46:13 florete kernel: eth1 (rndis_host): not using net_device_ops yet
Jul 27 11:46:13 florete kernel: eth1: register 'rndis_host' at 
usb-:00:1d.0-1, RNDIS device, 
Jul 27 11:46:14 florete avahi-daemon[7346]: Registering new address record for 
 on eth1.*.
Jul 27 11:46:16 florete ntpd[2106]: Listening on interface #19 eth1, #123 
Enabled
Jul 27 11:46:17 florete dhclient: DHCPREQUEST on eth1 to 255.255.255.255 port 67
Jul 27 11:46:17 florete dhclient: DHCPACK from 169.254.2.18
Jul 27 11:46:17 florete avahi-daemon[7346]: Joining mDNS multicast group on 
interface eth1.IPv4 with address 169.254.2.17.
Jul 27 11:46:17 florete avahi-daemon[7346]: New relevant interface eth1.IPv4 
for mDNS.
Jul 27 11:46:17 florete avahi-daemon[7346]: Registering new address record for 
169.254.2.17 on eth1.IPv4.
Jul 27 11:46:17 florete dhclient: bound to 169.254.2.17 -- renewal in 1247502 
seconds.
Jul 27 11:46:17 florete avahi-daemon[7346]: Withdrawing address record for 
169.254.2.17 on eth1.
Jul 27 11:46:17 florete avahi-daemon[7346]: Leaving mDNS multicast group on 
interface eth1.IPv4 with address 169.254.2.17.
Jul 27 11:46:17 florete avahi-daemon[7346]: Interface eth1.IPv4 no longer 
relevant for mDNS.
Jul 27 11:46:17 florete avahi-daemon[7346]: Joining mDNS multicast group on 
interface eth1.IPv4 with address 169.254.2.2.
Jul 27 11:46:17 florete avahi-daemon[7346]: New relevant interface eth1.IPv4 
for mDNS.
Jul 27 11:46:17 florete avahi-daemon[7346]: Registering new address record for 
169.254.2.2 on eth1.IPv4.
Jul 27 11:46:17 florete avahi-daemon[7346]: Withdrawing address record for 
169.254.2.2 on eth1.
Jul 27 11:46:17 florete avahi-daemon[7346]: Leaving mDNS multicast group on 
interface eth1.IPv4 with address 169.254.2.2.
Jul 27 11:46:17 florete avahi-daemon[7346]: Interface eth1.IPv4 no longer 
relevant for mDNS.
Jul 27 11:46:17 florete avahi-daemon[7346]: Joining mDNS multicast group on 
interface eth1.IPv4 with address 169.254.2.2.
Jul 27 11:46:17 florete avahi-daemon[7346]: New relevant interface eth1.IPv4 
for mDNS.
Jul 27 11:46:17 florete avahi-daemon[7346]: Registering new address record for 
169.254.2.2 on eth1.IPv4.
Jul 27 11:46:18 florete ntpd[2106]: Listening on interface #20 eth1, 
169.254.2.2#123 Enabled

A device eth1 shows up when I run ifconfig, but nm-tool and the
NetworkManager Applet don't see anything.

I don't know how to troubleshoot this further.

Can anyone help?

Tony


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

Re: howto ignore rfkill switch

[Marcel Holtmann]

Hi Dan,

> > Well, actually in the case of the OP, the switch has nothing to do
> > with the PCMCIA card, and the card is still on, available and
> > configurable by hand (iwconfig, ifconfig) when the switch is off. It
> > is just NM that decides to disable all wireless possibility even if
> > the switch concerns only the internal card.
> 
> You've flipped the rfkill switch, thus you do not want to use wifi.  If
> you do actually want to use wifi, there are other, better mechanisms to
> just kill the card you don't want to use.  rfkill is *not* the mechanism
> to disable a specific card completely.

it actually is the right way to kill a specific WiFi card. It is not
that useful if you have platform switches in your system that interact
with hotplug, but RFKILL works on a per device and all devices basis. At
least the re-write coming with 2.6.31 does this correctly.

The hardware RFKILL button/switch on your laptop needs to be tied into a
userspace policy to decide what to do with external devices. That is out
of the scope of the Linux kernel.

Regards

Marcel


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

Re: Saving a nondefault configuration?

[Dan Williams]

On Fri, 2009-07-24 at 10:15 +0900, Jacobs Shannon wrote:
> Basically I'm hoping someone can point me at the correct information
> for this, though I couldn't find it when I was searching for it a
> while ago. More recently, I was again poking around inside of the
> program, and I still couldn't figure it out. Or maybe it just isn't
> possible?
> 
> When I boot, the wireless connection via the USB device does work
> correctly, and that connection is properly established. (It usually
> fails to reestablish when needed later on, but that's a minor
> problem that I'm just living with.) However, after the connection

That reconnection thing is usually a driver bug, but NM could also try
harder, because often it will actually reconnect after about 30 seconds
or a minute.  Repeated failures indicate kernel driver problems.

> has been established, I always have to tweak the settings, and I'd
> prefer to just save them permanently. First have to disable the WiFi
> connection, and then I have to activate the shared connection on the

So you do not want the wifi to automatically start up?  If so, you can
turn off the 'autoconnect' on the wifi connection and only connect that
manually.

Dan

> wired LAN so that my other computers can share the connection. It
> only takes a few seconds, but it's kind of annoying that it has to
> be done every time I boot.
> 
> 
> --
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> ___
> 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: howto ignore rfkill switch

[Dan Williams]

On Fri, 2009-07-24 at 10:30 +0200, Cedric Pradalier wrote:
> 
> 
> On Fri, Jul 24, 2009 at 10:04 AM, Simon Geard 
> wrote:
> On Thu, 2009-07-23 at 10:16 -0500, Carl Karsten wrote:
> > Sounds like it would be good to just disable the switch,
> right?  From
> > what I gather, the switch signals the OS, which then runs
> code to
> > disable the wifi hardware, so overriding that is very
> possible.
> 
> 
> Depends on the machine. On some machines the switch just sends
> a signal
> to software; on others it physically turns off the wireless.
> In the
> latter case (including my laptop), there's nothing you can do,
> since
> it's all in hardware...
> 
> Simon.
> 
> 
> Well, actually in the case of the OP, the switch has nothing to do
> with the PCMCIA card, and the card is still on, available and
> configurable by hand (iwconfig, ifconfig) when the switch is off. It
> is just NM that decides to disable all wireless possibility even if
> the switch concerns only the internal card.

You've flipped the rfkill switch, thus you do not want to use wifi.  If
you do actually want to use wifi, there are other, better mechanisms to
just kill the card you don't want to use.  rfkill is *not* the mechanism
to disable a specific card completely.

Dan


> A partial solution was found by using connman (from intel AFAIK) which
> seems to ignore the switch completely. 
> 
> -- 
> Cedric Pradalier
> ___
> 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

[PATCH] nm-applet: Restore PEAP settings

[Mikhail Efremov]

Hello!

Based on code in other eap-method-*.c

-- 
WBR, Mikhail Efremov
diff --git a/src/wireless-security/eap-method-peap.c b/src/wireless-security/eap-method-peap.c
index d9f4f46..f0cacef 100644
--- a/src/wireless-security/eap-method-peap.c
+++ b/src/wireless-security/eap-method-peap.c
@@ -209,7 +209,8 @@ inner_auth_combo_changed_cb (GtkWidget *combo, gpointer user_data)
 static GtkWidget *
 inner_auth_combo_init (EAPMethodPEAP *method,
const char *glade_file,
-   NMConnection *connection)
+   NMConnection *connection,
+   NMSetting8021x *s_8021x)
 {
 	GladeXML *xml = EAP_METHOD (method)->xml;
 	GtkWidget *combo;
@@ -217,9 +218,18 @@ inner_auth_combo_init (EAPMethodPEAP *method,
 	GtkTreeIter iter;
 	EAPMethodSimple *em_mschap_v2;
 	EAPMethodSimple *em_md5;
+	guint32 active = 0;
+	const char *phase2_auth = NULL;
 
 	auth_model = gtk_list_store_new (2, G_TYPE_STRING, eap_method_get_g_type ());
 
+	if (s_8021x) {
+		if (nm_setting_802_1x_get_phase2_auth (s_8021x))
+			phase2_auth = nm_setting_802_1x_get_phase2_auth (s_8021x);
+		else if (nm_setting_802_1x_get_phase2_autheap (s_8021x))
+			phase2_auth = nm_setting_802_1x_get_phase2_autheap (s_8021x);
+	}
+
 	em_mschap_v2 = eap_method_simple_new (glade_file,
 	  method->sec_parent,
 	  connection,
@@ -231,6 +241,10 @@ inner_auth_combo_init (EAPMethodPEAP *method,
 	-1);
 	eap_method_unref (EAP_METHOD (em_mschap_v2));
 
+	/* Check for defaulting to MSCHAPv2 */
+	if (phase2_auth && !strcasecmp (phase2_auth, "mschapv2"))
+		active = 0;
+
 	em_md5 = eap_method_simple_new (glade_file,
 	 method->sec_parent,
 	 connection,
@@ -242,12 +256,16 @@ inner_auth_combo_init (EAPMethodPEAP *method,
 	-1);
 	eap_method_unref (EAP_METHOD (em_md5));
 
+	/* Check for defaulting to MD5 */
+	if (phase2_auth && !strcasecmp (phase2_auth, "md5"))
+		active = 1;
+
 	combo = glade_xml_get_widget (xml, "eap_peap_inner_auth_combo");
 	g_assert (combo);
 
 	gtk_combo_box_set_model (GTK_COMBO_BOX (combo), GTK_TREE_MODEL (auth_model));
 	g_object_unref (G_OBJECT (auth_model));
-	gtk_combo_box_set_active (GTK_COMBO_BOX (combo), 0);
+	gtk_combo_box_set_active (GTK_COMBO_BOX (combo), active);
 
 	g_signal_connect (G_OBJECT (combo), "changed",
 	  (GCallback) inner_auth_combo_changed_cb,
@@ -320,7 +338,7 @@ eap_method_peap_new (const char *glade_file,
 			gtk_file_chooser_set_filename (GTK_FILE_CHOOSER (widget), filename);
 	}
 
-	widget = inner_auth_combo_init (method, glade_file, connection);
+	widget = inner_auth_combo_init (method, glade_file, connection, s_8021x);
 	inner_auth_combo_changed_cb (widget, (gpointer) method);
 
 	widget = glade_xml_get_widget (xml, "eap_peap_version_combo");
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] nm-applet: wrong index in eap-method-ttls.c

[Mikhail Efremov]

Hello!

CHAP method has index 3, not 4.

-- 
WBR, Mikhail Efremov
diff --git a/src/wireless-security/eap-method-ttls.c b/src/wireless-security/eap-method-ttls.c
index 78d0f80..043a0e8 100644
--- a/src/wireless-security/eap-method-ttls.c
+++ b/src/wireless-security/eap-method-ttls.c
@@ -272,7 +272,7 @@ inner_auth_combo_init (EAPMethodTTLS *method,
 
 	/* Check for defaulting to CHAP */
 	if (phase2_auth && !strcasecmp (phase2_auth, "chap"))
-		active = 4;
+		active = 3;
 
 	combo = glade_xml_get_widget (xml, "eap_ttls_inner_auth_combo");
 	g_assert (combo);
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list