Re: Collect agreement/disagreement to Relicense NetworkManager under LGPL-2.1+

[Dan Winship via networkmanager-list]

Thomas asked me to send email agreeing to the relicensing. I am not the
copyright holder of any code in NetworkManager and do not believe that I
have any say in this decision, but if it turns out that I do, then,
sure, I agree.

-- Dan

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

Re: is anyone actually still using WiMAX

[Dan Winship]

On 02/12/2015 12:47 PM, Stuart Gathman wrote:
>> Am 10.02.2015 um 15:53 schrieb Dan Winship:
>>> Of course this would not affect people using WiMAX via external hotspots
>>> (assuming such people and hotspots still exist).

> WiMax by its nature encourages locked, proprietary end points, so it is
> primarily used with an external hotspot.  This is not a bad thing - buy
> the proprietary hotspot, and you have WiMax internet anywhere in Jordan,
> for instance.  But it would be an uphill slog to support directly
> connecting to proprietary networks, and I have yet to see an open WiMax
> network.
> 
> So my 2 cents would be to shelve support until there is WiMax network
> that can use it.  (Does anyone know of one operating today?)

The networks themselves are proprietary, but the protocol for
communicating with them is open, just like with GSM/CDMA-based mobile
broadband. If you have certain Intel Wi-Fi chipsets in your laptop (like
the 6250) then, you can connect to WiMAX networks directly, without an
external hotspot. Except, as noted, the driver support is sketchy (last
time I tested it, using WiMAX at all caused Wi-Fi to break completely
until you rebooted), and at least Fedora, Debian, and Ubuntu aren't
building support for it.

(So it's looking like the answer to the original question is: no, no one
will care if we rip out support for it completely.)

-- Dan

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

is anyone actually still using WiMAX

[Dan Winship]

While taking cheap potshots at WiMAX during devconf.cz, we started
wonder whether anyone would care (or even notice) if we dropped support
for it in NM 1.2, given that:

  - WiMAX seems to be a dying technology

  - the Intel WiMAX driver for Linux has never worked very well, and
the SDK appears to no longer be supported

  - NM's WiMAX support requires a hacked up version of the Intel
WiMAX SDK that supports libnl3, which exists only in a git
repository whose location has never been terribly well
advertised, suggesting most distros probably don't build it
anyway.

  - Fedora dropped it a few releases back and there was no uproar

Of course this would not affect people using WiMAX via external hotspots
(assuming such people and hotspots still exist).

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: libnm-glib

[Dan Winship]

On 01/23/2015 06:04 AM, Cezary Manista wrote:
> I worked around that by creating the NMClient using g_object_new
> directly, and passing bus object via construction parameters. This way
> my component may be missing some initialization done by
> _nm_object_ensure_inited (that's called in nm_client_new), but I noticed
> that _nm_object_ensure_inited is also called by other methods like
> nm_client_get_state, so I assume that whenever I call one of these, the
> object gets fully initialized. It seems to work fine, by the way.

Actually, you should just call g_initable_init() on it. Then if
something does go wrong with initialization, you'll get back a GError or
exception or something. (I'm not sure what language binding you're using
with NodeJS... it's possible that it does that for you automatically
with objects that implement GInitable, as NMClient does.)

>  - Is it OK to create NMClient object this way? (at least with the
> version 0.9.8.0 of NM)

Yes, the libnm-glib test programs do this as well.

>  - I noticed that in the latest revision, nm_client_new hasn't changed.
> Is there a reason why DBusGConnection parameter is not there? Is there a
> chance that it will be added in future releases?

The API is stable, so it can't change between versions.


Note that in the new "libnm" library in NM 1.0 there is no longer a
"dbus-connection" property, but you can set the environment variable
"LIBNM_USE_SESSION_BUS" to make NMClient use the session bus rather than
the system bus.

-- Dan

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

Re: [PATCH] dist: include manual page sources

[Dan Winship]

On 01/22/2015 12:24 PM, Lubomir Rintel wrote:
> On Thu, 2015-01-22 at 09:50 -0500, Dan Winship wrote:
>> On 01/22/2015 04:54 AM, Lubomir Rintel wrote:
>>> -   $(docbook_generated_man_pages:.%=.xml)  \
>>
>>> +   $(addsuffix .xml,$(basename $(docbook_generated_man_pages)))\
>>
>> That seems like it should be the same thing... what does the first one do?
> 
> The ".%" pattern is applied to the complete string (think ^\..*$). It
> thus does not match and nothing is substituted (which is why the
> generate manual pages got included and not the source).

ah... patch looks good then
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] dist: include manual page sources

[Dan Winship]

On 01/22/2015 04:54 AM, Lubomir Rintel wrote:
> - $(docbook_generated_man_pages:.%=.xml)  \

> + $(addsuffix .xml,$(basename $(docbook_generated_man_pages)))\

That seems like it should be the same thing... what does the first one do?

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

Re: [PATCH] libnm: drop libdbus-glib from pkg-config file

[Dan Winship]

Yes, this is correct

On 01/22/2015 05:00 AM, Lubomir Rintel wrote:
> libnm uses GIO DBus library instead.
> 
> https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00065.html
> ---
>  libnm/libnm.pc.in | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> On Thu, 2015-01-22 at 03:40 +0100, Michael Biebl wrote:
> Hi,
>>
>> the libnm.pc file for the new libnm library has
>>
>> Requires: gio-2.0 dbus-glib-1
>>
>> This looks incorrect, especially the dependency on dbus-glib-1.
>> Is this a C&P error? Especially since the Description is the same as for
>> libnm-util.pc.
> 
> Yes, that looks like a mistake. Unless anyone objects I'll remove it.
> 
> Thank you
> Lubo
> 
> diff --git a/libnm/libnm.pc.in b/libnm/libnm.pc.in
> index 6392799..5fe26b6 100644
> --- a/libnm/libnm.pc.in
> +++ b/libnm/libnm.pc.in
> @@ -6,7 +6,7 @@ includedir=@includedir@
>  Name: libnm
>  Description: Convenience library for clients of NetworkManager
>  Version: @VERSION@
> -Requires: gio-2.0 dbus-glib-1
> +Requires: gio-2.0
>  Cflags: -I${includedir}/libnm
>  Libs: -L${libdir} -lnm
>  
> 
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: How Embedded is NetworkManager

[Dan Winship]

On 01/09/2015 12:45 PM, Richard Willis wrote:
> This project uses multiple networking interfaces (Eth, WiFi, GSM-Radio,
> Bluetooth) but runs as a “headless” black box, gathering telemetry
> information and providing some gateway support. NetworkManager would be
> a very good fit for this device, but I am concerned that NetworkManager
> may have link dependencies for GUI support, something the product does
> not have.
> 
> I’m interesting in hearing if anyone has tried running NetworkManager
> without any GUI.. is it possible?

NetworkManager itself has no gui dependency, and as of 0.9.10, there's a
curses-based connection editor (nmtui) so you don't even have to write
out the config files by hand if you don't want to. (In addition to
"nmcli", which is a more powerful command-line-based tool that can be
used to perform just about any operation that NetworkManager exposes
over D-Bus.)

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: veth won't be configured in libvirt managed LXC container

[Dan Winship]

There's a bunch of discussion about this in
https://bugzilla.gnome.org/show_bug.cgi?id=731014. The short answer is
"it's complicated", because veths get used for a bunch of different
things in different situations...

-- Dan

On 10/16/2014 07:08 AM, Lubomir Rintel wrote:
> Hi,
> 
> currently it is impossible to get useful network configuration for LXC 
> containers on boot. (At least if they're managed via libvirt; I have no
> idea if anything is different with native LXC tooling). They're supposed
> to obtain their configuration via DHCP, but instead connection is assumed.
> Firstly because there's an IPv6 local link address that (I think) gets
> assigned when libvirt ups the interface and secondly because it's a 
> software link.
> 
> Why do we assume connection on all software links? Virtual ethernet devices
> are supposed to behave much like ordinary ethernet devices; they have 
> carrier detection, etc.
> 
> I'm following up with the patches that resolve the problem for me, but 
> I'm not quite sure about the special case for veth. 
> 
> Thoughts?
> 
> Thank you,
> Lubo
> 
> ___
> networkmanager-list mailing list
> networkmanager-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list
> 
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH 1/1] vpnc: add support to change interface name

[Dan Winship]

On 09/23/2014 04:58 AM, Christian Hesse wrote:
> Dan Williams  on Mon, 2014/09/22 10:09:
>> So this is great, and ties in with some other stuff we're doing.
>> However, one change I'd like to request.  Instead of putting the
>> interface name into the VPN data (like the other vpnc-specific options),
>> lets put it into the NMSettingConnection setting's 'interface-name'
>> property.
> 
> Sounds reasonable.
> 
> But (NMConnection *connection) is specific to a VPN connection and does not
> have an interface-name property, no? If I got it right I can not pass it to
> nm_connection_get_setting_connection() and therefore (NMSettingConnection
> *s_con) is missing. So do we have to create (NMConnection *connection) and
> (NMConnection *vpn) and pass around both?

No, the NMConnection contains multiple NMSettings (basically, one for
each page of the connection editor). So you can call both
get_setting_connection() and get_setting_vpn() on it.

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nmtui links [Re: ANN: NetworkManager 0.9.9.98 (0.9.10-rc1) released]

[Dan Winship]

On 06/22/2014 06:23 PM, Michael Biebl wrote:
> Looking at nmtui, I think I'd prefer if we made /usr/bin/nmtui-*
> symbolic links to /usr/bin/nmtui.
> 
> This makes it much more obvious then a hard link.

Looking through /usr/bin/ on my machine, it seems like some packages use
symlinks and some use hard links...

For now we'll stick with hard links because I don't want to switch it
right before the .0 release and then belatedly discover that I broke
something. If other people complain maybe we'll switch to symlinks in
the next release.

-- Dan

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

Re: Trouble building NetworkManager

[Dan Winship]

OK, I pushed a branch danw/setting-docs-fix that should fix all these
issues. Try it out / review it?

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released

[Dan Winship]

On 06/17/2014 10:50 AM, Michael Biebl wrote:
> Looking through the changes in configure.ac, I notice that libteam is a
> new (optional) dependency.
> Which of the new functionality depends on libteam?

"team" devices. (The new half-kernel/half-userland replacement for the
"bond" driver.)

-- Dan

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

Re: ANN: NetworkManager 0.9.9.95 (0.9.10-beta1) released

[Dan Winship]

On 06/13/2014 10:35 AM, Yegor Yefremov wrote:
> What's the schedule for the final release?

end-of-the-month-ish, assuming no unexpectedly-large bugs

-- Dan

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

Re: RFC: standardized network provisioning

[Dan Winship]

On 06/11/2014 12:12 PM, Chuck Anderson wrote:
> Has any thought been given to implementing standardized network
> provisioning similar to how Apple's .mobileconfig works?

There's been some discussion about provisioning in the past, but as far
as I know no one is currently working on it.

> XpressConnect's Linux support uses a native Linux
> binary and relies on communication with the NetworkManager DBUS API.
> The rapid changes in this API and other system components on Linux
> cause this to break frequently.  For example, XpressConnect works on a
> freshly installed Fedora 20, but not one updated with the latest
> package updates.

The NetworkManager D-Bus API is stable. While we do add new
properties/methods to it as needed, existing released API should never
change. If it does, please file a bug.

-- Dan

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

Re: NetworkManager 0.9.8.10

[Dan Winship]

On 04/25/2014 06:34 AM, John Frankish wrote:
>> (FYI, these also contain a few new bugfixes since the 0.9.8.9 release
>> candidates.)
>>
>> http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.9/
>> http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/
>>
> The news files are missing?

Yeah... I think it's because rather than adding a new section for the
differences between 0.9.8.9 and 0.9.8.10, I just rewrote the existing
0.9.8.9 section, and the ftpadmin scripts didn't like that.

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/NEWS?h=nm-0-9-8&id=9c690755

https://git.gnome.org/browse/network-manager-applet/tree/NEWS?h=nma-0-9-8&id=514d6114

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

ANN: NetworkManager 0.9.8.10

[Dan Winship]

Continuing in our tradition of delivering important GNOME bug fixes too
late for the release, we present NetworkManager 0.9.8.10 and
network-manager-applet 0.9.8.10.

Besides fixing two bugs that affect the GNOME shell network icon (and I
think maybe also the current version of the KDE NetworkManager applet?),
0.9.8.10 contains a number of other miscellaneous bug fixes cherry-
picked from git master; see NEWS for more details.

(FYI, these also contain a few new bugfixes since the 0.9.8.9
release candidates.)

http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.9/
http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/

The NetworkManager Team
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] core: log when removing devices

[Dan Winship]

On 04/04/2014 04:09 PM, Dan Williams wrote:
>  static void
>  device_removed_cb (NMDevice *device, gpointer user_data)
>  {
> - remove_device (NM_MANAGER (user_data), device, FALSE);
> + remove_device (NM_MANAGER (user_data), device, FALSE, "device request");
>  }

It might be better to add a reason string to the "removed" signal so
they can provide something more specific.

> + remove_device (self, NM_DEVICE (iter->data), FALSE, "parent 
> request");

That could also be clearer, maybe involving the parent ifname too.

-- Dan

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

Re: [PATCH 1/1] platform: extract common fields of IPv4/IPv6 addresses and routes to base struct

[Dan Winship]

On 04/04/2014 05:46 PM, Thomas Haller wrote:
> On Fri, 2014-04-04 at 16:24 -0500, Dan Williams wrote:
>> On Fri, 2014-04-04 at 23:02 +0200, Thomas Haller wrote:
>>> On Fri, 2014-04-04 at 15:13 -0500, Dan Williams wrote:
 Is the only reason for the #define of the common fields so that you
 don't have to do another level of indirection?  It looks somewhat ugly
 and my personal preference would be to just declare the base struct in
 the functions you want to use it in and up-cast if you need the v4 or v6
 version...  kinda like we do with objects.  So I certainly agree with
 the principle, but lets see what other people say about the
 implementation...

> I see, but the disadvantage is, that I would have to fixup *many*
> occurrences in existing code. Also, it is more typing.

But many of those existing occurrences involve separate IPv4 and IPv6
functions / codepaths where the actual behavior is exactly the same and
ought to be merged into a single NMPlatformIPAddress codepath anyway...

-- Dan

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

Re: NetworkManager-0.8.1 and computerauthentication

[Dan Winship]

On 04/04/2014 10:23 AM, Omer Faruk SEN wrote:
> Hello Dan,
> 
> AFAIK this EAP identity package was sent by 802.1x supplicant so as far
> as I know it is Network Manager to do this so i think it is NM that
> sends user/pass or machine name as "host/machine.name <http://machine.name>"

Ah. I don't know all the details of all the various Windows-specific
protocols. At any rate, no, NetworkManager does not support this.

-- Dan

> On Fri, Apr 4, 2014 at 3:26 PM, Dan Winship  <mailto:d...@gnome.org>> wrote:
> 
> On 04/03/2014 10:00 AM, Omer Faruk SEN wrote:
> > Hello,
> >
> > I want to ask how can i use "Computer Authentication" on
> > NetworkManager-0.8.1. Is this a supported mode? If so where can i
> > configure it on the NM GUI?
> 
> I think that's something you'd do with samba (probably specifically the
> samba-winbind package), not NetworkManager.
> 
> -- Dan
> 
> 
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager-0.8.1 and computerauthentication

[Dan Winship]

On 04/03/2014 10:00 AM, Omer Faruk SEN wrote:
> Hello,
> 
> I want to ask how can i use "Computer Authentication" on
> NetworkManager-0.8.1. Is this a supported mode? If so where can i
> configure it on the NM GUI?

I think that's something you'd do with samba (probably specifically the
samba-winbind package), not NetworkManager.

-- Dan

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

ANN: NetworkManager 0.9.8.9 (0.9.8.10 release candidate)

[Dan Winship]

Continuing in our tradition of delivering important GNOME bug fixes only
a little bit too late for the release, we present NetworkManager 0.9.8.9
and network-manager-applet 0.9.8.9, which are release candidates for the
imminent 0.9.8.10 stable releases.

Besides fixing two bugs that affect the GNOME shell network icon (and I
think maybe also the current version of the KDE NetworkManager applet?),
0.9.8.9 contains a number of other miscellaneous bug fixes cherry-picked
from git master; see NEWS for more details.

http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.9/
http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/

The NetworkManager Team
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: nm_device_disconnect

[Dan Winship]

On 04/01/2014 07:08 PM, Manuel Yguel wrote:
> Thanks for the answer,
> Is there an other way ? Because I want the adhoc network to stop as soon
> as possible.

It *will* stop as soon as possible

> Plus I do not do anything in the disconnect callback, so I
> fear that it is just my callback that is called when the adhoc network
> is disconnected (by somebody else or by the fact that the network is not
> available anymore) and then that this not the function for my purpose.

No, the callback is only called for the action that you initiated.

> Well, well, what I am looking for is the function that is called when in
> a GUI the user hit the disconnect button...

Which is nm_device_disconnect().

> I took a look at the sources of NetworkManager and I noted that there
> are several files called nm-device.h that offer different interfaces.

One of them is the object inside the NetworkManager daemon itself, the
other is the client-side representation of that object.

-- Dan

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

Re: "server.conf" ignore-carrier=* Bonding/Bridge DHCP

[Dan Winship]

On 04/02/2014 05:18 AM, Thomas Haller wrote:
> ignore-carrier and DHCP does not go well together because NM will start
> doing DHCP on an interface that has no carrier (which will fail). 

No, that's how it originally worked, but in the current version of the
code, ignore-carrier means:

  - You can activate a connection with purely static IP configuration
even when the device doesn't have carrier.

  - If you lose carrier when a connection (static or dynamic) is active,
that connection won't be dropped.

But you can't activate a DHCP connection on an ignore-carrier device if
it doesn't have carrier.

-- Dan

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

Re: nm_device_disconnect

[Dan Winship]

On 04/01/2014 01:18 PM, Manuel Yguel wrote:
> however in the include directory of libnm-glib the file nm-device.h
> contains only the following function:
>void nm_device_disconnect (NMDevice *device,
> NMDeviceDeactivateFn callback, gpointer user_data);
> 
> I tried to use the last one with a dummy callback function and with a
> pointer to a NMClient object but it did not disconnect the network.
> 
> Thanks for any hint or pointer.

A libnm-glib method that takes a callback is most likely asynchronous.
So you need to call nm_device_disconnect() and then run the main loop
until the callback gets called.

-- Dan

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

Re: RFC: Simplifying Keyfiles

[Dan Winship]

On 03/27/2014 02:55 PM, Justin Brown wrote:
> After quite a bit of work to get bridging setup correctly on VLAN
> interfaces, I'm wondering if we can remove some keys that seem
> unnecessary.

So, one thing to understand is that (a) the keyfile plugin is mostly a
one-to-one mapping from NMSetting subclass properties, and (b) the
NMSetting subclass properties have to maintain API stability. So some of
what you're seeing is just accumulated cruft.

In some cases, we could fix the keyfile plugin to allow some
simplifications.

> The [connection] section in keyfiles is confusing. It's clearly about
> identification and general information (id, uuid, permissions,
> autoconnect, zone, etc.).

It's called "connection" because it corresponds to NMSettingConnection.
But that mostly corresponds to the "General" page in
nm-connection-editor, and perhaps should be called that.

> The problem with type is that it's inferred by the rest of the
> configuration. For example, if I have a VLAN interface, I am required
> to have a [vlan] section.

Right, but if you have an ethernet interface, you *aren't* required to
have an [ethernet] section, because none of the properties on
NMSettingWired are mandatory-to-set. The value of type could, perhaps,
be inferred when a type-specific section was present.

> Master is the most confusing of these keys because it is used so
> erratically.

It's actually used 100% consistently, and maps to a specific property of
the kernel network interface.

A device that has a master has no IP configuration of its own, because
it is used only as part of the operation of its master device. This is a
completely different situation from VLAN parent, where the VLAN
interface and its parent are entirely independent of each other at the
IP level.

Also, "master" points to a device that requires this one, while
"parent" points to a device that this one requires. And in particular,
a VLAN device can have both a parent and a master. Eg, if you have
bond0 containing eth0.1 and eth1.1, then eth0.1 would have parent=eth0
and master=bond0. Whereas a device can't have two masters.

> The inconsistency is the problem. To me, it seems like every use of
> [connection] master would be better served by using the "parent" key
> in that interface's inferred type section (like bridge-port in the
> example above).

We could in theory have separate "master" properties for each slave
type, and maybe we would have done it that way if we had added bridge
support first. (Note that there's no slave-specific keyfile section /
NMSetting subclass for bonds, because bond slaves have no slave-specific
properties.)

> slave-type
> --
> 
> There's not much to say here. This key is basically an amalgamation of
> master and type. The type and slave relationship can be inferred in
> another section.

As mentioned above, for bond slaves, there is no [bond-slave] section,
so this could only be inferred by looking up the connection pointed to
by "master", which is not always convenient.

(However, see also https://bugzilla.gnome.org/show_bug.cgi?id=682052)

> interface-name
> -
> 
> I don't understand why many of the sections have an interface-name key
> in addition to connection.

The connection interface-name property is new in 0.9.10. The
bond/bridge/vlan/team-specific interface-name properties are now deprecated.

If they're still required in keyfiles in git master, then file a bug
please. They shouldn't be.

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

device plugins renamed; rm the old ones

[Dan Winship]

Those of you who built from git in the last week or so will want to rm
$prefix/lib64/NetworkManager/libnm-device-* before your next "make
install", because we renamed some of the device plugins.

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [0.9.8 PATCH] build: convert from INCLUDES to AM_CPPFLAGS

[Dan Winship]

I didn't look too hard, but if it still distchecks, then yay.
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] libnm-glib: suppress warnings unless LIBNM_GLIB_DEBUG is set

[Dan Winship]

sure. The "unknown object type" one always annoys me...


On 02/06/2014 05:51 AM, Dan Williams wrote:
> Most of these warnings are things libnm-glib can't do anything
> about, and they are pretty annoying when running nmcli or nmtui,
> and libraries usually shouldn't print random warnings anyway.
> Downgrade them to debug messages that can be enabled if we need
> to see them.
> ---
>  libnm-glib/nm-object.c | 77 
> +++---
>  1 file changed, 36 insertions(+), 41 deletions(-)
> 
> diff --git a/libnm-glib/nm-object.c b/libnm-glib/nm-object.c
> index 497f6c3..2fbc4f1 100644
> --- a/libnm-glib/nm-object.c
> +++ b/libnm-glib/nm-object.c
> @@ -150,15 +150,15 @@ constructor (GType type,
>   object = G_OBJECT_CLASS (nm_object_parent_class)->constructor (type,
>  
> n_construct_params,
>  
> construct_params);
>  
>   priv = NM_OBJECT_GET_PRIVATE (object);
>  
>   if (priv->connection == NULL || priv->path == NULL) {
> - g_warning ("%s: bus connection and path required.", __func__);
> + g_warn_if_reached ();
>   g_object_unref (object);
>   return NULL;
>   }
>  
>   _nm_object_cache_add (NM_OBJECT (object));
>  
>   return object;
> @@ -566,27 +566,26 @@ _nm_object_create (GType type, DBusGConnection 
> *connection, const char *path)
>   GError *error = NULL;
>  
>   type_func = g_hash_table_lookup (type_funcs, GSIZE_TO_POINTER (type));
>   if (type_func)
>   type = type_func (connection, path);
>  
>   if (type == G_TYPE_INVALID) {
> - g_warning ("Could not create object for %s: unknown object 
> type", path);
> + dbgmsg ("Could not create object for %s: unknown object type", 
> path);
>   return NULL;
>   }
>  
>   object = g_object_new (type,
>  NM_OBJECT_DBUS_CONNECTION, connection,
>  NM_OBJECT_DBUS_PATH, path,
>  NULL);
>   if (!g_initable_init (G_INITABLE (object), NULL, &error)) {
> - g_object_unref (object);
> - object = NULL;
> - g_warning ("Could not create object for %s: %s", path, 
> error->message);
> + dbgmsg ("Could not create object for %s: %s", path, 
> error->message);
>   g_error_free (error);
> + g_clear_object (&object);
>   }
>  
>   return object;
>  }
>  
>  typedef void (*NMObjectCreateCallbackFunc) (GObject *, const char *, 
> gpointer);
>  typedef struct {
> @@ -620,21 +619,19 @@ static void
>  async_inited (GObject *source, GAsyncResult *result, gpointer user_data)
>  {
>   NMObjectTypeAsyncData *async_data = user_data;
>   GObject *object = G_OBJECT (source);
>   GError *error = NULL;
>  
>   if (!g_async_initable_init_finish (G_ASYNC_INITABLE (object), result, 
> &error)) {
> - if (!g_error_matches (error, DBUS_GERROR, 
> DBUS_GERROR_UNKNOWN_METHOD)) {
> - g_warning ("Could not create object for %s: %s",
> -nm_object_or_connection_get_path (object), 
> error->message);
> - }
> + dbgmsg ("Could not create object for %s: %s",
> + nm_object_or_connection_get_path (object),
> + error->message);
>   g_error_free (error);
> - g_object_unref (object);
> - object = NULL;
> + g_clear_object (&object);
>   }
>  
>   create_async_complete (object, async_data);
>  }
>  
>  static void
>  async_got_type (GType type, gpointer user_data)
> @@ -1024,18 +1021,18 @@ handle_property_changed (NMObject *self, const char 
> *dbus_name, GValue *value, g
>   if (!found) {
>   dbgmsg ("Property '%s' unhandled.", prop_name);
>   goto out;
>   }
>  
>   pspec = g_object_class_find_property (G_OBJECT_GET_CLASS (G_OBJECT 
> (self)), prop_name);
>   if (!pspec) {
> - g_warning ("%s: property '%s' changed but wasn't defined by 
> object type %s.",
> -__func__,
> -prop_name,
> -G_OBJECT_TYPE_NAME (self));
> + dbgmsg ("%s: property '%s' changed but wasn't defined by object 
> type %s.",
> + __func__,
> + prop_name,
> + G_OBJECT_TYPE_NAME (self));
>   goto out;
>   }
>  
>   if (G_UNLIKELY (debug)) {
>   char *s;
>   s = g_strdup_value_contents (value);
>   dbgmsg ("PC: (%p) %s::%s => '%s' (%s%s%s)",
> @@ -1057,18 +1054,18 @@ handle_property_changed (NMObject *self, const char 
> *dbus_name, GValue *value, g
>   g_warn_if_reached ();
>   goto out;
>

Re: Release management problems

[Dan Winship]

On 02/07/2014 09:24 AM, Bastien Nocera wrote:
> Heya,
> 
> We're running into trouble with the recent "Team" support in GNOME, as
> there's no backing NetworkManager release with the necessary team
> support:
> https://bugzilla.gnome.org/show_bug.cgi?id=723769

The bug also mentions geoclue requiring libnm-glib 0.9.9.0, but I don't
see any obvious reason why it should from the sources...

> It wouldn't be that much of a problem if Fedora didn't ship git
> snapshots of the "next" NetworkManager version. Why ship git snapshots
> in Fedora that are apparently not good enough for full releases?

Because all of the NM maintainers are also Fedora developers, and so if
bugs show up, we can fix them quickly.

I guess we should start hiding unstable APIs behind #defines so that
Fedora users don't accidentally depend on them.

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Disabling ip4 and IPV6 on F20RC1

[Dan Winship]

On 12/17/2013 06:01 AM, Pavel Simerda wrote:
> 2) But setting disable_ipv6 doesn't really work as expected. See [1] and 
> especially the note about disable_ipv6 below the table. The truth is that 
> this also wouldn't affect the original poster's use case where the specific 
> interface is (hopefully) expected to be always without IP addresses.

Oh, you missed the update I guess. It wasn't a kernel bug, it was
NetworkManager itself interfering with my testing. disable_ipv6 works
just as expected.

-- Dan

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

Re: [PATCH] wifi: do not disconnect on suspend if WoWLAN is enabled

[Dan Winship]

On 11/19/2013 07:59 AM, Stanislaw Gruszka wrote:

If user configure device to enable WoWLAN (Wake over Wireless LAN) we
should not disconnect before suspend as device will not be able to
receive wake up magic-packet (or other triggers of WoWLAN event).


Yeah, we break regular ethernet wake-on-lan too 
(https://bugzilla.redhat.com/show_bug.cgi?id=826652). So we need a more 
device-type-agnostic fix. I've filed a bug about this: 
https://bugzilla.gnome.org/show_bug.cgi?id=712745.


-- Dan

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

Re: bonding options rework experiment (dcbw/bondopts)

[Dan Winship]

On 11/14/2013 08:57 PM, Dan Williams wrote:
> Hi,
> 
> I've pushed my experiments here to dcbw/bondopts, enough that it
> compiles and passes 'make check' in libnm-util, although we certainly
> don't have enough testcase coverage of bonding to make sure it works.
> 
> My main attempts were to use the normal GObject property ParamSpecs for
> min/max validation and all defaults, and to reduce some of the legacy
> property complexity by just exposing all the properties in the old
> 'options' property.

Looks great

  - NM_SETTING_BOND_PRIMARY_RESELECT is defined with a "_" rather than
a "-" in its value. (I have no idea how I happened to notice this.)

  - what's the point of __NM_SETTING_BOND_MODE_IS_balance_rr(), etc?
(they don't get used anywhere)

  - I'd rename "validate_list" to "validate_string", since that matches
the TYPE_ enum better, and doesn't sound like it's validating a
list of things.

  - I assume that if you remove the miimon/arp_interval magic, then
you'll need to update nmcli to know to clear one when setting the
other. (I'm assuming this because jklimes is the one who added that
magic, not because I've actually looked at the nmcli code in
question.)

  - ifcfg-rh/writer.c clearly doesn't compile as-is, so I guess you
haven't tried to build src/ yet?
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

ANN: NetworkManager 0.9.8.8

[Dan Winship]

Because we know you just can't get enough of NetworkManager 0.9.8.*, we
are pleased to announce the release of NetworkManager 0.9.8.8 and
network-manager-applet 0.9.8.8.

(NM 0.9.8.8 was actually released several weeks ago, it was just never
announced. nma 0.9.8.8 just came out today.)

NetworkManager 0.9.8.8 contains an important fix for BlueZ 5 support, as
well as some other small bug fixes.

network-manager-applet 0.9.8.8 contains a fix for missing Wi-Fi/VPN
password dialogs on the various non-GNOME-Shell GNOME-3-based desktops,
plus translations updates and some other small bug fixes.

Everyone is encouraged to upgrade to this new stable release.

http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.9/
http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/

The NetworkManager Team
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: cannot add profiles for wired connections or connect to wireless after upgrading to 0.9.8.6

[Dan Winship]

One thing I notice comparing the 0.9.8.4 and 0.9.8.6 output is that in
0.9.8.4 it's loading the ifnet plugin, but in 0.9.8.6 it isn't. This
suggests some sort of packaging problem; you need to have an
/etc/NetworkManager/NetworkManager.conf containing

  [main]
  plugin=ifnet

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

ANN: NetworkManager 0.9.8.6

[Dan Winship]

Hot on the heels of 0.9.8.4, we are pleased to announce the release of
NetworkManager 0.9.8.6.

This release is mostly the same as 0.9.8.4, but now includes support
for BlueZ 5. (It also includes one bug fix and a translation update.)

Everyone is encouraged to upgrade to this new stable release.

http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.9/

Dan and the NetworkManager Team
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [patch network-manager-applet v2] add support for team devices

[Dan Winship]

On 09/16/2013 03:28 AM, Jiri Pirko wrote:
> Hi, any comments please? I discussed this with jklimes and he seems
> happy with it.

Sorry for the delay. Mostly good, and I see jklimes already fixed some
things on the jklimes/team branch in git. I added another patch there to
fix some layout problems.

Two remaining questions:

  1. Should we add a filepicker to the Team Port page like jklimes did
 on the team page?

  2. Does the team driver let you team InfiniBand devices with other
 devices? I know you can't do that with bonding because of the
 different hardware address size, and so there's code in page-bond.c
 to keep track of what kind of children the bond has, and after
 you've added one, you can't add the other kind any more. The team
 page, as it is now, will let you add both an ethernet and an
 infiniband device to the team.

-- Dan

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

Re: ANN: NetworkManager 0.9.8.4

[Dan Winship]

On 09/20/2013 12:29 PM, Pavel Simerda wrote:
>> This version of NetworkManager is being released now to support the
>> GNOME 3.10 release, but it does not include support for BlueZ 5. There
>> will be a 0.9.8.6 release "soon" (but probably after GNOME 3.10.0) that
>> will support being compiled against BlueZ, but will only support PAN and
>> not DUN. (That is, it will support the mode where the bluetooth device
>> shares its own network connection with NM, but not the mode where the
>> bluetooth device acts as a mobile broadband modem, and NM has to be told
>> the details of its GSM/CDMA connection.) DUN support will hopefully
>> return in the next stable release.
> 
> Does that mean that with Bluez 4 both PAN and DUN will be still supported 
> with the upcoming releases?

Yes.

-- Dan

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

ANN: NetworkManager 0.9.8.4

[Dan Winship]

On behalf of the other Dan, I'm pleased to announce the release of
NetworkManager 0.9.8.4, network-manager-applet 0.9.8.4, and the
associated VPN plugins (including network-manager-vpnc 0.9.8.*6*,
because 0.9.8.4 was discovered to have a major bug).

This release includes all the standard sorts of minor fixes,
enhancements, and translation updates (which you can read more about in
the NEWS files), but in particular also contains a new API which is used
by gnome-shell 3.10 and which should result in more accurate network
status icons.

Everyone is encouraged to upgrade to this new stable release.

Except for people who are using BlueZ 5.

This version of NetworkManager is being released now to support the
GNOME 3.10 release, but it does not include support for BlueZ 5. There
will be a 0.9.8.6 release "soon" (but probably after GNOME 3.10.0) that
will support being compiled against BlueZ, but will only support PAN and
not DUN. (That is, it will support the mode where the bluetooth device
shares its own network connection with NM, but not the mode where the
bluetooth device acts as a mobile broadband modem, and NM has to be told
the details of its GSM/CDMA connection.) DUN support will hopefully
return in the next stable release.

http://ftp.gnome.org/pub/gnome/sources/NetworkManager/0.9/
http://ftp.gnome.org/pub/gnome/sources/network-manager-applet/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-vpnc/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openconnect/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openvpn/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-pptp/0.9/
http://ftp.gnome.org/pub/gnome/sources/NetworkManager-openswan/0.9/

Dan (no, the other one) and the NetworkManager Team
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: 802.1x wired authentication

[Dan Winship]

On 08/30/2013 12:43 PM, Alec Warner wrote:
> If not, I could use the 2 different connections (which work fairly well
> for the majority of my use cases.) However there are some minor issues
> with that set up that I need to address. One is how to switch between
> the connections. If I presume I have 2 connections (A for Auth and U for
> UnAuth) how do I get NM to always try A first? My understanding is that
> NM will try the 'last successful' connection first. Is there any sort of
> API to specify priorities, such that when the interface is toggled, A
> will always be tried before U?

I think the best you can do right now is to set "automatically connect
to this network" on A, but not on U. Then it will try A automatically,
and if it fails, you can activate U manually.

-- Dan

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

Re: [patch NetworkManager 00/11] team driver related updates and fixes

[Dan Winship]

I committed the non-nmcli parts (with three small fixes: added spaces
before "(" in function calls [eg, "teamdctl_alloc ()"], fixed a build
error when building without libteamdctl ["error: unused variable
'priv'"], and made a minor grammatical tweak to a log message).

I'll leave the nmcli bits for jklimes to review since he knows that code
a lot better.

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [patch NetworkManager v2 0/2] ifcfg-rh: reader: allow device to not have ipv4 setting.

[Dan Winship]

On 08/22/2013 08:17 AM, Jiri Pirko wrote:
> v1->v2:
> - Processed DanW's comments
> - added test case

Thanks. Committed.

(And you should request NM git access.
https://bugs.freedesktop.org/enter_bug.cgi?product=freedesktop.org,
component "New Accounts" or "Account Modification Requests" depending on
whether you already have an account or not, ask to be put on the
NetworkManager ACL, and cc: dcbw.)

-- Dan

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

Re: [patch NetworkManager] ifcfg-rh: reader: allow device to do not have ipv4 setting.

[Dan Winship]

On 08/22/2013 03:44 AM, Jiri Pirko wrote:
>> Should be split onto two lines. Also, we don't generally use "gchar"
>> (just use "char"), and there's no particular reason to use gint32 rather
>> than int here. (I see that there are some existing gint32s in that
>> file... I have no idea why.)
> 
> With this I always try to be conform with the rest of the code.
> Since tag_name is put as a parameter to g_strdup, which has gchar * in
> its prototype, I'm using gchar.

FYI, it's 100% guaranteed that "gchar" is just a typedef for "char", on
all platforms, always. "gchar" mostly only exists for
parallelism/completeness/aesthetics, to complement "guchar" (which is
actually useful because it's much less typing than "unsigned char").

glib and gtk still use "gchar", but almost everyone else gave up on them
long ago and just use "char" everywhere.

>> Hm... so this function does the same thing as the code it replaced, but
>> I'm not sure why the old code did it that way... if there's just a
>> PREFIX, but no IPADDR, then that shouldn't count as "an IP4 address is
>> defined". Maybe dcbw will have some insight on this when he gets back.
> 
> I'm just following the original code. If you want to change the
> behaviour, I suggest to do it in separate patch.

Sure, I was just noticing it and wanted to point it out as something we
should look at later.

-- Dan

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

Re: IPv6 in network-manager-openvpn

[Dan Winship]

On 08/19/2013 12:47 PM, Nicolas Iooss wrote:
> The patches are working well in my testing environment with
> NetworkManager 0.9.8 but with the development revision I've got few
> issues such as https://bugzilla.gnome.org/show_bug.cgi?id=706286. Now NM
> crashes on a segmentation fault
> at 
> http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/src/nm-policy.c#n788
>  as
> nm_vpn_connection_get_ip6_internal_gateway returns NULL for my VPN

Right. Does the attached patch fix it?

(Pavel: I briefly considered changing NMPlatform to take pointers to
struct in6_addr rather than struct in6_addr itself everywhere. it's
generally considered poor form to pass "large" structs on the stack
anyway...)

-- Dan

>From 135d790d1ad1ea240a8ccb04383aa8551cf7f2f7 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Wed, 21 Aug 2013 13:36:54 -0400
Subject: [PATCH] core: fix crash when connecting to ipv6-aware VPN

NMVpnConnection represents "no IPv6 internal gateway" as NULL, so you
can't just dereference the result. We have to pass in6addr_any to
NMPlatform in that case.
---
 src/nm-policy.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/src/nm-policy.c b/src/nm-policy.c
index cf94033..2707bfe 100644
--- a/src/nm-policy.c
+++ b/src/nm-policy.c
@@ -785,12 +785,14 @@ update_ip6_routing (NMPolicy *policy, gboolean force_update)
 		int parent_ifindex = nm_device_get_ip_ifindex (parent);
 		NMIP6Config *parent_ip6 = nm_device_get_ip6_config (parent);
 		guint32 parent_mss = parent_ip6 ? nm_ip6_config_get_mss (parent_ip6) : 0;
-		struct in6_addr int_gw = *nm_vpn_connection_get_ip6_internal_gateway (vpn);
+		const struct in6_addr *int_gw = nm_vpn_connection_get_ip6_internal_gateway (vpn);
 		int mss = nm_ip6_config_get_mss (ip6_config);
 
-		if (!nm_platform_ip6_route_add (ip_ifindex, in6addr_any, 0, int_gw, 0, mss)) {
+		if (!int_gw)
+			int_gw = &in6addr_any;
+		if (!nm_platform_ip6_route_add (ip_ifindex, in6addr_any, 0, *int_gw, 0, mss)) {
 			nm_platform_ip6_route_add (parent_ifindex, *gw_addr, 128, in6addr_any, 0, parent_mss);
-			if (!nm_platform_ip6_route_add (ip_ifindex, in6addr_any, 0, int_gw, 0, mss)) {
+			if (!nm_platform_ip6_route_add (ip_ifindex, in6addr_any, 0, *int_gw, 0, mss)) {
 nm_log_err (LOGD_IP6 | LOGD_VPN, "Failed to set default route.");
 			}
 		}
-- 
1.8.3.1

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

Re: [patch NetworkManager] ifcfg-rh: reader: allow device to do not have ipv4 setting.

[Dan Winship]

You should add a test case to test-ifcfg-rh for this, to make sure we
don't break it later.


Other than that, just nitpicks:

Drop the word "do" in the commit summary line.

> +static gchar *get_numbered_tag (gchar *tag_name, gint32 which)

Should be split onto two lines. Also, we don't generally use "gchar"
(just use "char"), and there's no particular reason to use gint32 rather
than int here. (I see that there are some existing gint32s in that
file... I have no idea why.)

> +static gboolean is_any_ip4_address_defined (shvarFile *ifcfg)

likewise, split onto two lines.

Hm... so this function does the same thing as the code it replaced, but
I'm not sure why the old code did it that way... if there's just a
PREFIX, but no IPADDR, then that shouldn't count as "an IP4 address is
defined". Maybe dcbw will have some insight on this when he gets back.

> + if (!value || bootproto_none) {
>   /* If there is no BOOTPROTO, no IPADDR, no PREFIX, no NETMASK, 
> but

The comment there should be updated to mention BOOTPROTO=none

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [patch NetworkManager 0/6] add support for network team devices

[Dan Winship]

On 07/14/2013 11:29 AM, Jiri Pirko wrote:
> teamd config is non-trivial tree structure (JSON). At this point, there is
> really no point to have NM to be aware of the teamd config structure.
> Once NM will need that, this can be changed.

NM will need to be aware of it once we want to add support for team
connections to nm-connection-editor. We'll probably have to have some
sort of dual-mode interface, where if we recognize all the options, you
get a nice UI with translated strings and proper widgets and such, but
if you need to edit something NM doesn't know about, you can still edit
the JSON directly...

> No function for that. Teamd will scream when you pass non-valid JSON to
> it. Also will scream in case some configuration is not done correctly.
> At this point, I would make NM non-aware at all of the config structure.
> Just leave it as string and NM to blindly pass it through...

Same case as above; when the user creates a new team connection, we want
to be able to detect if the configuration is invalid before the user
saves the connection, rather than just accepting it at that point and
then telling them later that they messed up.


On 07/15/2013 01:05 PM, Pavel Simerda wrote:
> How do you store the port config then?

There's a separate NMSettingTeamPort setting for the ports, like with
bridges.

-- Dan

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

Re: [patch NetworkManager 0/6] add support for network team devices

[Dan Winship]

On 07/11/2013 11:31 AM, Jiri Pirko wrote:
> I heavily reused existing code, mainly bonding parts.

Makes sense (and makes it easy to review...)

> The only thing not
> implemented yet is dbus communication with teamd (used particulary for
> port config setup).

Will that allow you to shut down teamd via d-bus too? The current
teamd-handling is kind of a weird mix of direct spawn/kill vs dbus... (I
guess it's not possible to use dbus activation to start teamd, because
you need a separate teamd process for each interface? Although the
initscripts seem to do this via some systemd magic... I wonder if that
magic is available to us programmatically somehow?)


I don't really like having a single string-valued "config" property on
NMSettingTeam... we did basically that with "options" in NMSettingBond,
and later decided it was a bad idea (which is why we didn't do the same
thing with bridges).

But I guess if it's possible to add new runners and/or link_watches then
there's no way NMSettingTeam could define properties for all possible
options, and so we have no choice but to use the json, right?

In that case we will probably eventually want to have NMSettingTeam
parse the config, and ensure that it's valid json, and contains the
mandatory properties. Maybe libteam has a function for that?

Is it expected/allowed for the NMSettingTeam's config to contain "port"
elements, and if so, what happens if they don't match up with the
available NMConnections for the port devices? I think we want to say
"no" here and pass "-n" to teamd. (Or if we're parsing the json in
NMSettingTeam we could strip out the ports, or reject the config if it
contains ports.) (Any of these would be inconsistent with the current
behavior of the Fedora initscripts, but maybe they should change too? I
don't think there's any other situation where one device's ifcfg file
can cause another device to be configured.)


Other than the possible config issues, the code looks good. Two minor
bugs I noticed:

You added an '#include "nm-setting-team.h"' to src/nm-device-ethernet.c,
but it's not actually used. (Nor is the nm-setting-bond.h include above
it... probably leftover from old code.)

write_team_port_setting() mistakenly writes out "TEAM_CONFIG=..."
instead of "TEAM_PORT_CONFIG=..."



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

Re: discuss: NM server defaults

[Dan Winship]

On 07/01/2013 04:14 PM, Dan Winship wrote:
>> danw, any rationale behind the argument for ignore-carrier?
> 
> Servers, by definition, tend to have fixed IP addresses. Therefore, if
> you are using DHCP on a server, it's probably for ease of deployment,
> not because you want dynamism.

Any response to this theory?


So currently I am thinking for 0.9.10:

  - flip the default value of monitor-connection-files from true
to false for all users, not just server (with a release note)

  - ship a server.conf with:
  no-auto-default=*
  ignore-carrier=*

  - tweak the ignore-carrier behavior so that if an ignore-carrier
device comes up, and it has no active connection, and a DHCP
connection could be activated on it, then we activate that
connection.

And for "future":

  - further improve the ignore-carrier/DHCP behavior, so that if
an ignore-carrier device comes up, and it *does* have an active
DHCP connection, we renew the lease without taking the device
down.

-- Dan

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

Re: discuss: NM server defaults

[Dan Winship]

On 07/01/2013 03:44 PM, Colin Walters wrote:
> On Mon, 2013-07-01 at 15:32 -0400, Pavel Simerda wrote:
> 
>> In my opinion, the default is to treat DHCP connections as fully
>> dynamic on servers as well as on laptops. 
> 
> In other words, a vote against ignore-carrier=* being the
> default.  I think I agree with you - if you're using DHCP,
> I'd expect things to be more dynamic.
> 
> danw, any rationale behind the argument for ignore-carrier?

Servers, by definition, tend to have fixed IP addresses. Therefore, if
you are using DHCP on a server, it's probably for ease of deployment,
not because you want dynamism.

>> I don't really see a renew/rebind upon replugging as a problem.

The code doesn't currently support doing it without taking the interface
down. But fixing that may be the best approach.

-- Dan

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

Re: discuss: NM server defaults

[Dan Winship]

So the relevant tweakable options are:


- no-auto-default=[interfaces]

Disables automatically-created DHCP ethernet connections. Everyone
agrees we want "no-auto-default=*" for servers.


- ignore-carrier=[interfaces]

Disables carrier-detect on the indicated interfaces. There's been some
internal RH networking services team discussion about these options, and
the consensus seemed to be that we definitely want this behavior for
interfaces with static IP addresses, but we can't enable it by default
everywhere because its current behavior with DHCP interfaces is sort of
broken. But we can fix that by changing it so that if DHCP times out due
to lack of carrier, and then carrier comes on, we retry dhcp at that
point (but we still ignore carrier in all other cases, and in
particular, we still always ignore carrier-off).

Given that change, then we would want "ignore-carrier=*" set on servers.


- monitor-connection-files=false

I think we also want this by default on servers; it is more consistent
with pre-NM ways of doing things, and makes it less easy to accidentally
shoot yourself in the foot.

In fact, I think we want to change things around so that "false" is the
default value of the option everywhere, and you need to override it if
you want the old behavior.


- dns=none

This disables NM's management of resolv.conf, which some people want for
various reasons, but I don't think we want this in the server defaults.

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

Re: [PATCH] build: Remove libndp for now

[Dan Winship]

On 06/13/2013 11:30 AM, Colin Walters wrote:
> We still do the AC_CONFIG_SUBDIRS even if we find the system libndp,
> which is harmless but ugly.

It's necessary, because we have to dist libndp even if we aren't using
it. (Maybe it would be better to make it so that disting required
--without-system-libndp in addition to --enable-gtk-docs instead?)

-- Dan

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

Re: [PATCH] build: Remove libndp for now

[Dan Winship]

OK, these patches (danw/ndpfix branch) make it not install libndp when
building it from source, and make it possible to use a system libndp
instead.
>From c89acbdc8f80455023a924ab6fae1acf12434a13 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Thu, 13 Jun 2013 09:34:09 -0300
Subject: [PATCH 1/2] build: don't install libndp

---
 Makefile.am | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 3fcc135..be6c49a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6,7 +6,6 @@ SUBDIRS = \
 	libnm-util \
 	libnm-glib \
 	introspection \
-	libndp \
 	src \
 	callouts \
 	cli \
@@ -20,6 +19,8 @@ SUBDIRS = \
 	examples \
 	vapi
 
+DIST_SUBDIRS = $(SUBDIRS) libndp
+
 @GNOME_CODE_COVERAGE_RULES@
 
 EXTRA_DIST = \
@@ -52,7 +53,6 @@ ACLOCAL_AMFLAGS = -I m4 ${ACLOCAL_FLAGS}
 
 CLEANFILES = cscope.in.out cscope.out cscope.po.out
 
-.PHONY: cscope
 cscope:
 	cscope -b -q -R -Iinclude -ssrc -slibnm-glib -slibnm-util -scli/src;
 
@@ -61,3 +61,12 @@ libgsystem_cflags := $(GLIB_CFLAGS) -I$(srcdir)/libgsystem
 libgsystem_libs = $(GLIB_LIBS)
 include libgsystem/Makefile-libgsystem.am
 noinst_LTLIBRARIES = libgsystem.la
+
+noinst_DATA = libndp
+libndp:
+	(cd libndp && $(MAKE))
+
+clean-local:
+	(cd libndp && $(MAKE) clean)
+
+.PHONY: cscope libndp
-- 
1.8.1.4

>From c347ac21234b61cd797427de3d18fe047d3db06c Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Thu, 13 Jun 2013 10:05:40 -0300
Subject: [PATCH 2/2] build: allow building against system libndp

---
 Makefile.am  |  2 ++
 configure.ac | 25 +
 2 files changed, 27 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index be6c49a..ced0b4f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -62,11 +62,13 @@ libgsystem_libs = $(GLIB_LIBS)
 include libgsystem/Makefile-libgsystem.am
 noinst_LTLIBRARIES = libgsystem.la
 
+if BUILD_LIBNDP
 noinst_DATA = libndp
 libndp:
 	(cd libndp && $(MAKE))
 
 clean-local:
 	(cd libndp && $(MAKE) clean)
+endif
 
 .PHONY: cscope libndp
diff --git a/configure.ac b/configure.ac
index 51f4aec..ed37286 100644
--- a/configure.ac
+++ b/configure.ac
@@ -596,6 +596,30 @@ else
 fi
 AM_CONDITIONAL(WITH_CONCHECK, test "${enable_concheck}" = "yes")
 
+dnl libndp
+AC_ARG_WITH(system-libndp, AS_HELP_STRING([--with-system-libndp=yes|no|auto], [use system libndp rather than bundled one (default: auto)]),
+[with_system_libndp=${withval}], [with_system_libndp=auto])
+if test "$with_system_libndp" = yes; then
+PKG_CHECK_MODULES(LIBNDP, [libndp])
+elif test "$with_system_libndp" = auto; then
+PKG_CHECK_MODULES(LIBNDP, [libndp], [build_libndp=no],[build_libndp=yes])
+else
+build_libndp=yes
+fi
+AM_CONDITIONAL(BUILD_LIBNDP, test "${build_libndp}" = yes)
+if test "$build_libndp" = yes; then
+LIBNDP_CFLAGS='-I$(top_srcdir)/libndp/include'
+LIBNDP_LIBS='$(top_builddir)/libndp/libndp/libndp.la'
+AC_SUBST(LIBNDP_CFLAGS)
+AC_SUBST(LIBNDP_LIBS)
+libndp_location=bundled
+else
+# temporary bug workaround
+LIBNDP_CFLAGS=`echo $LIBNDP_CFLAGS | sed -e 's:/ndp.h::'`
+libndp_location=system
+fi
+
+
 NM_COMPILER_WARNINGS
 
 dnl -
@@ -751,6 +775,7 @@ echo "  wimax: $enable_wimax"
 echo "  ppp: $enable_ppp"
 echo "  modemmanager-1: $with_modem_manager_1"
 echo "  concheck: $enable_concheck"
+echo "  libndp: $libndp_location"
 echo
 
 echo "Configuration plugins"
-- 
1.8.1.4

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

Re: [PATCH] build: Remove libndp for now

[Dan Winship]

On 06/12/2013 11:56 AM, Colin Walters wrote:
> It's installing itself into $(prefix), whereas we need a private
> library in $(pkglibdir).

Yes, there's discussion of this in the ndp/rdisc bug.

Removing the submodule at this point will just cause more git pain, but
we could remove it from SUBDIRS until it gets fixed.

-- Dan

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

Re: Does Network Manager use wpa_supplicant for wired connections?

[Dan Winship]

On 06/12/2013 01:28 PM, Pengcheng Chen wrote:
> Hi all,
> 
> Does Network Manager use wpa_supplicant, or X Supplicant? or does it
> implement 802.1x Supplicant in itself?

it uses wpa_supplicant

-- Dan

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

NetworkManager --no-daemon vs --debug

[Dan Winship]

In git master, --no-daemon no longer has the behavior of redirecting
NM's log output to stderr. Use --debug (aka -d) now to get that behavior.

Rationale:

When run with --no-daemon, NM used to duplicate all syslog output to
stderr, for ease of debugging. But this meant it had to tell systemd
to ignore stderr, so you wouldn't get duplicated log entries. But
that meant we lost error messages that didn't go through nm_log.
(eg, g_warning()s and g_return_if_fail()s).

Fix this by making --no-daemon no longer duplicate syslog output to
stderr, and removing the "StandardError=null" from the systemd
service file. To get the old behavior, you can use --debug instead
of --no-daemon.

https://bugzilla.gnome.org/show_bug.cgi?id=700550

Oh, this also means that if you build NM from source into /usr, then
next time systemd tells you that you should run "systemctl --system
daemon-reload", you actually should.

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Select wired connection by router mac address?

[Dan Winship]

On 05/19/2013 10:42 AM, Pavel Simerda wrote:
> I don't think anyone is working on this, even though it would
> be interesting and very practical.

dcbw wrote his thoughts on it in NetworkManager's TODO though:

http://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/TODO?h=nm-0-9-8#n51

-- Dan

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

Re: [PATCH] Add libgsystem as a git submodule

[Dan Winship]

>> autogen.sh properly gets libgsystem. However it seems libgsystem simply uses
>> latest GLib bits. I guess it should not if it can be avoided, because it
>> spoils its usability.
>> And that is the case for NetworkManager (that is just happy with glib 2.32).
>>
>> libgsystem now uses these symbols that require glib>=2.34:
>> * g_mapped_file_get_bytes (GMappedFile *file)
>> * g_spawn_check_exit_status()
>> * and G_SPAWN_EXIT_ERROR, G_SPAWN_SEARCH_PATH_FROM_ENVP
>>
>> Making a compatibility definition for them will allow compilation.
> 
> Would it be a problem to bump the requirement to 2.34?

Yes, we picked the current versions to work well with various distros.

Are we planning to use anything in libgsystem besides the auto-free
stuff? If not, why don't we remove the submodule and just copy in the
header with the relevant macros for now?

-- Dan

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

i probably broke your build tree

[Dan Winship]

Just landed a big build-system change; src/ is now built mostly
non-recursively, all the nm-device*.[ch] files are in a subdirectory,
and generated/ no longer exists (with nm-enum-types.[ch] now being
generated directly under src/).

Anyway, if you can't get it to build after this, a "git clean -dfx"
would probably help (note that that will delete every non-git backed
file in your checkout, so don't do that if you have random files with
notes or build scripts or whatever in your tree).

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: [PATCH] Use g_cclosure_marshal_generic

[Dan Winship]

Oh, I just did this too as part of the danw/movedevs branch...

>-  dbus_g_object_register_marshaller (_nm_marshal_VOID__STRING_BOXED,
>+  dbus_g_object_register_marshaller (NULL,

Does that work? From what I can see in the dbus-glib source code, it
seems like you would need to pass g_cclosure_marshal_generic explicitly,
not NULL.

-- Dan

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

Re: Does Network Manager Support Machine Authentication?

[Dan Winship]

On 04/30/2013 06:12 AM, Deepak Das wrote:
> Hi,
> 
> I have windows client environment and machine authentication with AD has
> been enabled and it is working fine. 
> 
> I am now planning to use linux clients and want to implement machine
> authentication. Is there a way to implement it using network manager? If
> yes then please share doc/link for the same?

That's not really part of what NetworkManager does. I think you want to
look at the Samba "winbind" stuff.

-- Dan

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

Re: Understanding the relevant parts of the NM code base

[Dan Winship]

On 04/13/2013 11:39 PM, Malintha Adikari wrote:
> Hi,
> 
> I am involving the proxy integration with the Network Connections
> project for GSOC. I have done a research about the code base of the NM.
> I am facing difficulties understanding the relevant parts of the code.
> Could you please help me to understand the code. First I want to find
> the source code of the Network Connections ( Its GUI and  etc.). Can
> you mentioned the source files related to this.

That is actually part of the GNOME Control Center. (gnome-control-center
module on git.gnome.org)

-- Dan

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

Re: [PATCH] man: Rewrite NetworkManager.8 and NetworkManager.conf.5 in DocBook

[Dan Winship]

On 04/10/2013 06:37 AM, Colin Walters wrote:
> DocBook is not my favorite thing in the world, but it's
> far saner than troff.  Some style
> parts cribbed from systemd.
> 
> This is preparatory work for actually improving the content of the
> man pages.

Yay. Makes sense to me. There are a few trailing-whitespace issues in
the XML files ("blank" lines that contain whitespace), and a few minor
glitches in the layout:

   dnsmasqNetworkManager will run dnsmasq as a local caching

but yeah, troff sucks, and we never even bothered to figure out how to
do some of the layout that we really needed to be doing there. (Like,
the section under "dns" really ought to be another ...)

I wouldn't bother converting nmcli.1 right now, since jklimes is
changing the syntax around a lot.

-- Dan

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

Re: using dns=dnsmasq in fedora19

[Dan Winship]

check if NM logged anything in /var/log/messages?

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

Re: NetworkManager on routers

[Dan Winship]

On 03/01/2013 05:15 AM, Philip Boulain wrote:
> How suitable do you feel that it is to use NetworkManager in a
> *router* role, where it is being asked to apply and respond to queries
> about an arbitrary number of more complicated devices and connections?

> ... and to a
> large extent its "desktop-y" behaviour can be disabled by setting
> devices to manual or unmanaged (and we may want to do so for
> complicated VPN/bridge/bonding configurations if NM can't or shouldn't
> be expanded to fit our needs here)

As Pavel mentioned, we are working on making some of the automatic
handling behavior configurable, to make NM work better on systems where
you want more predictable / less desktop-specific behavior. Check out
https://bugzilla.gnome.org/show_bug.cgi?id=688857 and comment there if
you have any other thoughts on functionality you would or wouldn't want
to be able to disable.

-- Dan

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

Re: NetworkManager C99 compiler requirement for 0.9.10 (and therefore 0.9.9)

[Dan Winship]

On 02/28/2013 10:57 AM, Pavel Simerda wrote:
> Hi all,
> 
> I would like to do *occasional* C99-style declarations in the code to avoid 
> ugly hacks when using conditionally built code. That means bumping up the 
> compiler requirements to the C99 standard. As we currently only target to GCC 
> and possibly LLVM, I don't think it would be a problem.
> 
> I will modify the configure.ac to require and use C99, if there are no 
> objections on the list.

Given that NM is Linux-only, this seems fine to me; at this point, the
only real reason for sticking with C90 in the GNOME platform is to
support win32 (where MSVC does not and will not ever support C99); it
seems unlikely that in 2013 there is any other platform where NM could
even theoretically be built where there is a defensible reason to use a
non-C99 compiler.

You may need to specify --std=gnu99 rather than c99 to avoid warnings
about gcc extensions though.

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Create an Access Point with NetworkManager-0.9.8.0

[Dan Winship]

On 02/26/2013 08:38 PM, Jauhien Piatlicki wrote:
> But when I try to 'Create New Wi-Fi Network' it tries to create an
> Ad-Hoc connection. Where can be the problem?

nm-applet has not been updated to support AP mode. (gnome-control-center
has been.) Can you file a bug?

-- Dan

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

Re: putting the NM client event loop in a separate thread

[Dan Winship]

On 02/23/2013 01:29 AM, david feeney wrote:
> Hi,
> 
> My application is getting libdbus segfaults when accessing a few
> specific nm functions and I am wondering if it is because I have the nm
> client event loop running is a separate thread.

Yes. libdbus is not thread-safe, and by default it integrates with the
default GMainContext.

I *think* you can fix this by creating your own DBusGConnection, with
dbus_g_bus_get_private(), calling dbus_g_connection_get_connection() to
get its DBusConnection, and then calling
dbus_connection_setup_with_g_main() on that to attach it to the
GMainContext you're using in your NM thread. Then create your NMClient with

   client = g_object_new (NM_TYPE_CLIENT,
  NM_OBJECT_DBUS_CONNECTION, connection,
  NM_OBJECT_DBUS_PATH, NM_DBUS_PATH,
  NULL);

(and likewise, pass that bus you nm_remote_settings_new() if you're
using NMRemoteSettings)

-- Dan

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

NM 0.9.10 requirements: glib 2.32, gtk 3.4? (and no gtk2)

[Dan Winship]

For 0.9.10 (expected sometime May-ish), we'd like to bump up the
required versions of some NM dependencies to start taking advantage of
assorted new awesomeness (eg, GDBus).

We're currently eyeing glib 2.32, and the corresponding gtk release
would be 3.4. Anyone got a problem with those?

This would also involve dropping gtk2 support from the applet,
connection editor, and VPN plugins. AFAIK, this should not affect your
ability to embed the applet in a gtk2-based panel, since it's all out of
process anyway.

-- Dan

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

emacs mode for NetworkManager-style indentation

[Dan Winship]

Since Pavel just complained about this in a bug...

Attached is an emacs mode for getting indentation to work the way the
NetworkManager tree (mostly) does it, with tabs for indentation and
spaces for alignment. Put it somewhere in your emacs load path, then
from .emacs do:

  (require 'smart-tabs-mode)
  (smart-tabs-advice c-indent-line c-basic-offset)
  (smart-tabs-advice c-indent-region c-basic-offset)

and then you can use M-x smart-tabs-mode to turn it on/off. Or, for
extra cleverness, add a file called .dir-locals.el to the top level of
your NetworkManager (and network-manager-applet, etc) tree,  containing:

  ((c-mode . ((smart-tabs-mode . t

(and then add ".dir-locals.el" to .git/info/exclude). And then you don't
have to think about it again. (Unless you do "git clean -dfx". In
theory, you're supposed to be able to put the .dir-locals.el file in the
directory *above* your checkout, and specify that it's only supposed to
apply to the NetworkManager subdirectory, but that never worked for
me... I think the documentation gets the syntax wrong or something...)

(I originally found this mode on EmacsWiki, but had to hack it up a
bit... IIRC the original only let you enable it per-mode, not
per-buffer? I forget... anyway, there's a link to the upstream in the
source.)

-- Dan
;; Emacs smart tabs mode
;;   Intelligently indent with tabs, align with spaces!
;;
;; To use, save smart-tabs-mode.el to a a directory on your load-path
;; (e.g., ~/.emacs.d/elisp), then add the following to your .emacs file:
;;
;;  (require 'smart-tabs-mode)
;;
;; Then, for each language you want to use smart tabs, set up a hook
;; and advice like so:
;;
;;  (add-hook 'MODE-HOOK 'smart-tabs-mode-enable)
;;  (smart-tabs-advice INDENT-FUNC TAB-WIDTH-VAR)
;;
;; Here are some specific examples for a few popular languages:
;;
;;  ;; C/C++
;;  (add-hook 'c-mode-hook 'smart-tabs-mode-enable)
;;  (smart-tabs-advice c-indent-line c-basic-offset)
;;  (smart-tabs-advice c-indent-region c-basic-offset)
;;
;;  ;; JavaScript
;;  (add-hook 'js2-mode-hook 'smart-tabs-mode-enable)
;;  (smart-tabs-advice js2-indent-line js2-basic-offset)
;;
;;  ;; Perl (cperl-mode)
;;  (add-hook 'cperl-mode-hook 'smart-tabs-mode-enable)
;;  (smart-tabs-advice cperl-indent-line cperl-indent-level)
;;
;;  ;; Python
;;  (add-hook 'python-mode-hook 'smart-tabs-mode-enable)
;;  (smart-tabs-advice python-indent-line-1 python-indent)
;;
;;  ;; Ruby
;;  (add-hook 'ruby-mode-hook 'smart-tabs-mode-enable)
;;  (smart-tabs-advice ruby-indent-line ruby-indent-level)
;;
;;
;; smart-tabs-mode.el is licensed under the GPLv2.
;; It is derived from 
;; as modified by John Croisant (jacius), along with Julien Fontanet and
;; Tomita Hiroshi (tomykaira).
;;
;; Modification history is at .

(require 'advice)

(defmacro smart-tabs-mode/no-tabs-mode-advice (function)
  `(unless (ad-find-advice ',function 'around 'smart-tabs)
 (defadvice ,function (around smart-tabs activate)
   (if smart-tabs-mode
   (let ((indent-tabs-mode nil)) ad-do-it)
 ad-do-it


(define-minor-mode smart-tabs-mode
  "Intelligently indent with tabs, align with spaces!"

  (progn
(smart-tabs-mode/no-tabs-mode-advice align)
(smart-tabs-mode/no-tabs-mode-advice align-regexp)
(smart-tabs-mode/no-tabs-mode-advice indent-relative)

(unless
(ad-find-advice 'indent-according-to-mode 'around 'smart-tabs)
  (defadvice indent-according-to-mode (around smart-tabs activate)
(if smart-tabs-mode
(let ((indent-tabs-mode indent-tabs-mode))
  (if (memq indent-line-function
'(indent-relative
  indent-relative-maybe))
  (setq indent-tabs-mode nil))
  ad-do-it)
  ad-do-it)))
nil
))
(defvar smart-tabs-mode nil)

(defun smart-tabs-mode-enable ()
  "Enable smart-tabs-mode."
  (smart-tabs-mode t))


(defmacro smart-tabs-advice (function offset)
  `(progn
 (defadvice ,function (around smart-tabs activate)
   (cond
(smart-tabs-mode
 (save-excursion
   (beginning-of-line)
   (while (looking-at "\t*\\( +\\)\t+")
 (replace-match "" nil nil nil 1)))
 (setq tab-width tab-width)
 (let ((indent-tabs-mode t)
   (tab-width fill-column)
   (,offset fill-column))
   (unwind-protect
   (progn ad-do-it
(t
 ad-do-it)


(provide 'smart-tabs-mode)
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Dropping support for libnl1 and libnl2?

[Dan Winship]

On 12/06/2012 07:11 PM, Dan Williams wrote:
> Hi,
> 
> All the major distros appear to have been shipping libnl3.x for quite a
> while already, and it's becoming increasingly difficult to support
> libnl1.x and 2.x with some of the newer features that are being added to
> NM like bridging, bonding, vlan, etc.
> 
> So, given that libnl 3.2.7 has been out for almost a year (2012-01-20),
> and most major distros are packaging it (Ubuntu, OpenSUSE, Debian,
> Fedora, Gentoo, Arch), would anyone object to libnl >= 3.2.7 as a build
> requirement for the next release of NetworkManager?

In https://bugzilla.gnome.org/show_bug.cgi?id=687630 it was noted that
the wimax libraries as shipped upstream only have support for libnl1.x,
and in Fedora we appear to be shipping a forked libnl3.x port of them.
What's the story there?

-- Dan

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

Re: [PATCH] libnm-gtk: default to system CA certificates for validation for new connections

[Dan Winship]

On 11/08/2012 01:56 PM, Dan Williams wrote:
> Default to passing the system CA path to wpa_supplicant so that
> certificates in /etc/ssl/certs (or whatever was given with
> --with-system-ca-path at build time) can be used as part of
> the verification chain by default.

sure, makes sense
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Gnome 3 style

[Dan Winship]

On 11/16/2012 12:28 PM, Dan Williams wrote:
> Basically, getting the applet to look like GNOME Shell's network applet
> would be a hack, because you'd have to ship a custom theme and then
> somehow convince GTK to use the applet's custom theme instead of the
> default GTK one. 

Well... nm-applet could request the symbolic icons rather than the
full-color ones, but the problem is that the set of available symbolic
networking icons doesn't match the set of fullcolor networking icons, so
you'd need to do something about that. In particular, as of GNOME 3.6,
the shell network indicator is now using multiple icons in the case
where you're connected to a VPN [rather than just overlaying a lock icon
on top of the wifi/ethernet icon], and making nm-applet do that would be
a bunch of work, since you could no longer just use GtkTrayIcon (since
that only supports a single icon).

-- Dan

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

Re: IPv6 default routes / NM vs. kernel autoconfig vs DHCP6

[Dan Winship]

On 08/07/2012 05:00 PM, Stuart D Gathman wrote:
> One situation that ought to work IMHO (although ~1/2 of IPv6 experts
> disagree) is that DHCP6 should work in concert with routes that are not
> /64.  For instance, RA provides a 2001:db8:1:2:3::1/80 default route

Note that:

   If the sum of the prefix length and interface identifier length
   does not equal 128 bits, the Prefix Information option MUST be
   ignored. [RFC 4862]

and

   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format. [RFC 4291]

(The 000 space is used for things like ::1 and IPv4-mapped addresses;
all "real" unicast addresses will have non-000 prefixes.) So any RA
advertising a non-/64 prefix is invalid.

> I find it quite
> handy to be able to subnet the /64 provided by the ISP, and while I
> agree that ISPs should always forever allocate a minimum of /64 to end
> users

FWIW, RFC 3177 recommends:

  -  Home network subscribers, connecting through on-demand or
 always-on connections should receive a /48.

I don't know how much that's actually being followed though.

-- Dan
___
networkmanager-list mailing list
networkmanager-list@gnome.org
https://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager fails to start during boot

[Dan Winship]

On 04/07/2012 03:39 AM, Ajay Garg wrote:
> So, would it be ok if I do some "sed" processing on the
> "/etc/init.d/NetworkManager" ?
> Is "/etc/init.d/NetworkManager" subject to change (text wise) ?

F14 isn't getting updates any more, so nothing's going to change it on
your machine. And when you update to a more recent Fedora release with a
more recent NetworkManager, hopefully your problem will be gone anyway.

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

Re: NM serious usablity challenges

[Dan Winship]

On 03/24/2012 06:24 PM, Robert Moskowitz wrote:
> A major defiency is the loss of deleting SSID configurations.  There is
> no 'delete' feature anymore in the Network Settings panel.

> this 'new' network manager does not tell me why it is failing.

> I cannot turn off wireless from the NM pulldown if it is currently
> trying (and really failing) to connect.

The network status menu is part of gnome-shell, and the Network Settings
panel is part of control-center; although they're built on top of NM's
APIs of course, the UI code is entirely in those other modules, outside
of NM's control. (You can file bugs against the shell and control-center
on bugzilla.gnome.org though.)

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

bonding fixes

[Dan Winship]

>From 7765a481979af6aad48dee4918b63caf4351c5f2 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Tue, 20 Mar 2012 13:06:22 -0400
Subject: [PATCH 1/4] core: fix NMDeviceBond:dispose() to chain up

---
 src/nm-device-bond.c |   10 +++---
 1 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/src/nm-device-bond.c b/src/nm-device-bond.c
index 710de4c..0d99fd7 100644
--- a/src/nm-device-bond.c
+++ b/src/nm-device-bond.c
@@ -45,7 +45,6 @@ G_DEFINE_TYPE (NMDeviceBond, nm_device_bond, NM_TYPE_DEVICE_WIRED)
 #define NM_BOND_ERROR (nm_bond_error_quark ())
 
 typedef struct {
-	gboolean disposed;
 	GSList *slaves;
 } NMDeviceBondPrivate;
 
@@ -506,15 +505,12 @@ dispose (GObject *object)
 	NMDeviceBondPrivate *priv = NM_DEVICE_BOND_GET_PRIVATE (self);
 	GSList *iter;
 
-	if (priv->disposed) {
-		G_OBJECT_CLASS (nm_device_bond_parent_class)->dispose (object);
-		return;
-	}
-	priv->disposed = TRUE;
-
 	for (iter = priv->slaves; iter; iter = g_slist_next (iter))
 		release_slave (NM_DEVICE (self), ((SlaveInfo *) iter->data)->slave);
 	g_slist_free (priv->slaves);
+	priv->slaves = NULL;
+
+	G_OBJECT_CLASS (nm_device_bond_parent_class)->dispose (object);
 }
 
 static void
-- 
1.7.7.6

>From 11b4614d94e4dbab2cabd69762509a4c12b98a03 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Thu, 22 Mar 2012 12:39:16 -0400
Subject: [PATCH 2/4] libnm-util: fix an NMSettingBond bug

NMSettingBond sets the "miimon" option to "100" by default, but this
means that when reading in a saved configuration with "arp_interval"
set, it would end up with both "miimon" and "arp_interval" set, which
is invalid. Fix this by clearing "miimon" if "arp_interval" is set,
and vice versa.
---
 libnm-util/nm-setting-bond.c |   13 +++--
 1 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/libnm-util/nm-setting-bond.c b/libnm-util/nm-setting-bond.c
index 50cad2d..0e9bb0f 100644
--- a/libnm-util/nm-setting-bond.c
+++ b/libnm-util/nm-setting-bond.c
@@ -237,17 +237,26 @@ gboolean nm_setting_bond_add_option (NMSettingBond *setting,
  const char *name,
  const char *value)
 {
+	NMSettingBondPrivate *priv;
 	size_t value_len;
 
 	g_return_val_if_fail (NM_IS_SETTING_BOND (setting), FALSE);
 	g_return_val_if_fail (validate_option (name), FALSE);
 	g_return_val_if_fail (value != NULL, FALSE);
 
+	priv = NM_SETTING_BOND_GET_PRIVATE (setting);
+
 	value_len = strlen (value);
 	g_return_val_if_fail (value_len > 0 && value_len < 200, FALSE);
 
-	g_hash_table_insert (NM_SETTING_BOND_GET_PRIVATE (setting)->options,
-	 g_strdup (name), g_strdup (value));
+	g_hash_table_insert (priv->options, g_strdup (name), g_strdup (value));
+
+	if (!strcmp (name, NM_SETTING_BOND_OPTION_MIIMON)) {
+		g_hash_table_remove (priv->options, NM_SETTING_BOND_OPTION_ARP_INTERVAL);
+		g_hash_table_remove (priv->options, NM_SETTING_BOND_OPTION_ARP_IP_TARGET);
+	} else if (!strcmp (name, NM_SETTING_BOND_OPTION_ARP_INTERVAL))
+		g_hash_table_remove (priv->options, NM_SETTING_BOND_OPTION_MIIMON);
+
 	return TRUE;
 }
 
-- 
1.7.7.6

>From d719b6af2fa42a198369c96f7a2e133541560656 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Tue, 20 Mar 2012 09:39:57 -0400
Subject: [PATCH 3/4] libnm-util: improve NMSettingBond:verify()

Add NM_SETTING_BOND_ERROR_INVALID_OPTION and
NM_SETTING_BOND_ERROR_MISSING_OPTION error codes so we can better
distinguish errors in different options, and add checks for various
incompatible sets of options.
---
 libnm-util/nm-setting-bond.c |  136 +++---
 libnm-util/nm-setting-bond.h |2 +
 2 files changed, 130 insertions(+), 8 deletions(-)

diff --git a/libnm-util/nm-setting-bond.c b/libnm-util/nm-setting-bond.c
index 0e9bb0f..9f9f438 100644
--- a/libnm-util/nm-setting-bond.c
+++ b/libnm-util/nm-setting-bond.c
@@ -23,6 +23,7 @@
 
 #include 
 #include 
+#include 
 #include 
 
 #include "nm-setting-bond.h"
@@ -353,6 +354,15 @@ dev_valid_name(const char *name)
 	return TRUE;
 }
 
+static gint
+find_setting_by_name (gconstpointer a, gconstpointer b)
+{
+	NMSetting *setting = NM_SETTING (a);
+	const char *str = (const char *) b;
+
+	return strcmp (nm_setting_get_name (setting), str);
+}
+
 static gboolean
 verify (NMSetting *setting, GSList *all_settings, GError **error)
 {
@@ -367,6 +377,8 @@ verify (NMSetting *setting, GSList *all_settings, GError **error)
 	  "balance-tlb",
 	  "balance-alb",
 	  NULL };
+	int miimon = 0, arp_interval = 0;
+	const char *arp_ip_target = NULL;
 
 	if (!priv->interface_name || !strlen(priv->interface_name)) {
 		g_set_error (error,
@@ -388,24 +400,131 @@ verify (NMSetting *setting, GSList *all_settings, GError **error)
 	while (g_hash_table

[PATCH] dbus error enum fixes

[Dan Winship]

I'm not sure I got the description of the problem right in the commit
message...

This fixes all of the enums that had been manually registered
pre-glib-mkenums to have the same values now as they did then. It also
fixes a few new enum types (bond and vlan stuff) to use the same
conventions. It doesn't change non-GError enum types, and it doesn't
change NMDnsManagerError or NMNetlinkMonitorError, because they weren't
registered before, and so presumably aren't being sent across D-Bus.

-- Dan
>From d34d24d36faba480c832d6bb9d2bf176cb13600d Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Fri, 9 Mar 2012 09:39:58 -0500
Subject: [PATCH] Fix names of error enum values

When NM was registering all of its enum types by hand, it was using
NamesListThis rather than the default names-like-this for the "nick"
values. When we switched to using glib-mkenums, this resulted in
dbus-glib using different strings for the D-Bus error names, causing
some problems.

Fix this by using glib-mkenums annotations to manually fix all the
enum values back to what they were before. (This can't be done in a
more automated way, because they old names aren't 100% consistent. Eg,
"UNKNOWN" frequently becomes "UnknownError" rather than just
"Unknown".)
---
 libnm-glib/nm-remote-settings.h   |6 ++--
 libnm-glib/nm-secret-agent.h  |   12 +-
 libnm-glib/nm-vpn-plugin.h|   18 
 libnm-util/nm-connection.h|8 +++---
 libnm-util/nm-setting-8021x.h |6 ++--
 libnm-util/nm-setting-bluetooth.h |8 +++---
 libnm-util/nm-setting-bond.h  |6 ++--
 libnm-util/nm-setting-cdma.h  |8 +++---
 libnm-util/nm-setting-connection.h|   10 
 libnm-util/nm-setting-gsm.h   |8 +++---
 libnm-util/nm-setting-infiniband.h|6 ++--
 libnm-util/nm-setting-ip4-config.h|8 +++---
 libnm-util/nm-setting-ip6-config.h|8 +++---
 libnm-util/nm-setting-olpc-mesh.h |6 ++--
 libnm-util/nm-setting-ppp.h   |8 +++---
 libnm-util/nm-setting-pppoe.h |8 +++---
 libnm-util/nm-setting-serial.h|8 +++---
 libnm-util/nm-setting-vlan.h  |6 ++--
 libnm-util/nm-setting-vpn.h   |6 ++--
 libnm-util/nm-setting-wimax.h |6 ++--
 libnm-util/nm-setting-wired.h |6 ++--
 libnm-util/nm-setting-wireless-security.h |   14 ++--
 libnm-util/nm-setting-wireless.h  |   10 
 libnm-util/nm-setting.h   |8 +++---
 src/dhcp-manager/nm-dhcp-manager.h|4 +-
 src/logging/nm-logging.h  |4 +-
 src/modem-manager/nm-modem-cdma.h |6 ++--
 src/modem-manager/nm-modem-gsm.h  |6 ++--
 src/nm-config.h   |2 +-
 src/nm-device-bond.h  |6 ++--
 src/nm-device-bt.h|6 ++--
 src/nm-device-ethernet.h  |6 ++--
 src/nm-device-infiniband.h|6 ++--
 src/nm-device-olpc-mesh.h |6 ++--
 src/nm-device-vlan.h  |6 ++--
 src/nm-device-wifi.h  |8 +++---
 src/nm-device.h   |6 ++--
 src/nm-manager.h  |   20 +-
 src/nm-session-utils.h|8 +++---
 src/settings/nm-agent-manager.h   |   14 ++--
 src/settings/nm-settings-error.h  |   32 ++--
 src/vpn-manager/nm-vpn-manager.h  |8 +++---
 src/wimax/nm-device-wimax.h   |8 +++---
 43 files changed, 180 insertions(+), 180 deletions(-)

diff --git a/libnm-glib/nm-remote-settings.h b/libnm-glib/nm-remote-settings.h
index 510c954..dd6c5a3 100644
--- a/libnm-glib/nm-remote-settings.h
+++ b/libnm-glib/nm-remote-settings.h
@@ -50,9 +50,9 @@ G_BEGIN_DECLS
  *
  **/
 typedef enum {
-	NM_REMOTE_SETTINGS_ERROR_UNKNOWN = 0,
-	NM_REMOTE_SETTINGS_ERROR_CONNECTION_REMOVED,
-	NM_REMOTE_SETTINGS_ERROR_CONNECTION_UNAVAILABLE,
+	NM_REMOTE_SETTINGS_ERROR_UNKNOWN = 0,/*< nick=UnknownError >*/
+	NM_REMOTE_SETTINGS_ERROR_CONNECTION_REMOVED, /*< nick=ConnectionRemoved >*/
+	NM_REMOTE_SETTINGS_ERROR_CONNECTION_UNAVAILABLE, /*< nick=ConnectionUnavailable >*/
 } NMRemoteSettingsError;
 
 #define NM_REMOTE_SETTINGS_ERROR nm_remote_settings_error_quark ()
diff --git a/libnm-glib/nm-secret-agent.h b/libnm-glib/nm-secret-agent.h
index 6a513ba..19f257e 100644
--- a/libnm-glib/nm-secret-agent.h
+++ b/libnm-glib/nm-secret-agent.h
@@ -30,12 +30,12 @@ G_BEGIN_DECLS
 GQuark nm_secret_agent_error_quark (void);
 
 typedef enum {
-	NM_SECRET_AGENT_ERROR_NOT_AUTHORIZED = 0,
-	NM_SECRET_AGENT_ERROR_INVALID_CONNECTION,
-	NM_SECRET_AGENT_ERR

Re: libnm-glib 0.9 depends on glib 2.28 now

[Dan Winship]

On 02/06/2012 11:45 AM, Dan Williams wrote:
>> 'g_simple_async_result_take_error' was introduced with commit 9fd98ef9
>> 'g_clear_object' was introduced with commit cc90f101
>>
>>
>> Was this intended?
> 
> I think so

Actually, I meant to stick with the current glib requirements, I just
forgot that take_error() was new-ish, and then the g_clear_object()
slipped by without me noticing.

Patch attached. I made a compat macro for take_error, since it's useful,
and just rewrote the one use of g_clear_object().

Oh, this is untested since I don't have a machine with old enough
glib... Thomas, can you try it?

-- Dan
>From a366864a6f38eea4b336750b91e08281c72e3876 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Mon, 6 Feb 2012 15:11:43 -0500
Subject: [PATCH] libnm-glib: fix to not depend on newer glib

---
 include/nm-glib-compat.h  |   10 ++
 libnm-glib/nm-client.c|1 +
 libnm-glib/nm-object.c|3 ++-
 libnm-glib/nm-remote-connection.c |1 +
 libnm-glib/nm-remote-settings.c   |1 +
 5 files changed, 15 insertions(+), 1 deletions(-)

diff --git a/include/nm-glib-compat.h b/include/nm-glib-compat.h
index 4b96871..c404ca6 100644
--- a/include/nm-glib-compat.h
+++ b/include/nm-glib-compat.h
@@ -1,3 +1,4 @@
+/* -*- Mode: C; tab-width: 4; indent-tabs-mode: t; c-basic-offset: 4 -*- */
 /* NetworkManager -- Network link manager
  *
  * Dan Williams 
@@ -29,4 +30,13 @@
 #define g_value_get_schar g_value_get_char
 #endif
 
+#if !GLIB_CHECK_VERSION(2,28,0)
+#define g_simple_async_result_take_error(result, error) \
+	G_STMT_START { \
+		GError *__error = error; \
+		g_simple_async_result_set_from_error (result, __error); \
+		g_error_free (__error); \
+	} G_STMT_END
+#endif
+
 #endif  /* NM_GLIB_COMPAT_H */
diff --git a/libnm-glib/nm-client.c b/libnm-glib/nm-client.c
index 06cf3a5..6c9eaa6 100644
--- a/libnm-glib/nm-client.c
+++ b/libnm-glib/nm-client.c
@@ -36,6 +36,7 @@
 #include "nm-vpn-connection.h"
 #include "nm-object-cache.h"
 #include "nm-dbus-glib-types.h"
+#include "nm-glib-compat.h"
 
 void _nm_device_wifi_set_wireless_enabled (NMDeviceWifi *device, gboolean enabled);
 
diff --git a/libnm-glib/nm-object.c b/libnm-glib/nm-object.c
index d76129d..51219b3 100644
--- a/libnm-glib/nm-object.c
+++ b/libnm-glib/nm-object.c
@@ -602,7 +602,8 @@ object_created (GObject *obj, gpointer user_data)
 	} else {
 		GObject **obj_p = pi->field;
 
-		g_clear_object (obj_p);
+		if (*obj_p)
+			g_object_unref (*obj_p);
 		*obj_p = odata->objects[0];
 	}
 
diff --git a/libnm-glib/nm-remote-connection.c b/libnm-glib/nm-remote-connection.c
index be78a09..c5e3864 100644
--- a/libnm-glib/nm-remote-connection.c
+++ b/libnm-glib/nm-remote-connection.c
@@ -30,6 +30,7 @@
 #include "nm-remote-connection.h"
 #include "nm-remote-connection-private.h"
 #include "nm-dbus-glib-types.h"
+#include "nm-glib-compat.h"
 
 #define NM_REMOTE_CONNECTION_BUS "bus"
 
diff --git a/libnm-glib/nm-remote-settings.c b/libnm-glib/nm-remote-settings.c
index e8d3386..588c120 100644
--- a/libnm-glib/nm-remote-settings.c
+++ b/libnm-glib/nm-remote-settings.c
@@ -29,6 +29,7 @@
 #include "nm-dbus-glib-types.h"
 #include "nm-remote-settings.h"
 #include "nm-remote-connection-private.h"
+#include "nm-glib-compat.h"
 
 static void nm_remote_settings_initable_iface_init (GInitableIface *iface);
 static void nm_remote_settings_async_initable_iface_init (GAsyncInitableIface *iface);
-- 
1.7.7.5

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

[PATCH] libnm-glib cleanups and fixes

[Dan Winship]

>From 9b662ac8676f6a823a1fadee90645c65036e7953 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Thu, 5 Jan 2012 13:36:03 -0500
Subject: [PATCH 01/12] libnm-glib: Fix _nm_string_array_demarshal

dbus-glib returns 'as' results as G_TYPE_STRV (NULL-terminated
char**), not DBUS_TYPE_G_ARRAY_OF_STRING (GPtrArray of char*).
---
 libnm-glib/nm-types.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/libnm-glib/nm-types.c b/libnm-glib/nm-types.c
index 6d76787..8598113 100644
--- a/libnm-glib/nm-types.c
+++ b/libnm-glib/nm-types.c
@@ -172,9 +172,9 @@ nm_string_array_get_type (void)
 gboolean
 _nm_string_array_demarshal (GValue *value, GPtrArray **dest)
 {
-	GPtrArray *array;
+	char **array;
 
-	if (!G_VALUE_HOLDS (value, DBUS_TYPE_G_ARRAY_OF_STRING))
+	if (!G_VALUE_HOLDS (value, G_TYPE_STRV))
 		return FALSE;
 
 	if (*dest) {
@@ -182,13 +182,13 @@ _nm_string_array_demarshal (GValue *value, GPtrArray **dest)
 		*dest = NULL;
 	}
 
-	array = (GPtrArray *) g_value_get_boxed (value);
-	if (array && array->len) {
+	array = (char **) g_value_get_boxed (value);
+	if (array && array[0]) {
 		int i;
 
-		*dest = g_ptr_array_sized_new (array->len);
-		for (i = 0; i < array->len; i++)
-			g_ptr_array_add (*dest, g_strdup (g_ptr_array_index (array, i)));
+		*dest = g_ptr_array_new ();
+		for (i = 0; array[i]; i++)
+			g_ptr_array_add (*dest, g_strdup (array[i]));
 	}
 
 	return TRUE;
-- 
1.7.7.5

>From 4788f6930590ca23475774c2125973169f6cd240 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Thu, 5 Jan 2012 13:34:58 -0500
Subject: [PATCH 02/12] libnm-glib: implement NMActiveConnection uuid property

This property existed as a #define and a get method, but the actual
GObject property itself was accidentally never implemented.
---
 libnm-glib/nm-active-connection.c |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/libnm-glib/nm-active-connection.c b/libnm-glib/nm-active-connection.c
index ddde4cc..55c50c9 100644
--- a/libnm-glib/nm-active-connection.c
+++ b/libnm-glib/nm-active-connection.c
@@ -371,6 +371,9 @@ get_property (GObject *object,
 	case PROP_CONNECTION:
 		g_value_set_string (value, nm_active_connection_get_connection (self));
 		break;
+	case PROP_UUID:
+		g_value_set_string (value, nm_active_connection_get_uuid (self));
+		break;
 	case PROP_SPECIFIC_OBJECT:
 		g_value_set_boxed (value, nm_active_connection_get_specific_object (self));
 		break;
@@ -483,6 +486,19 @@ nm_active_connection_class_init (NMActiveConnectionClass *ap_class)
 		  G_PARAM_READABLE));
 
 	/**
+	 * NMActiveConnection:uuid:
+	 *
+	 * The active connection's UUID
+	 **/
+	g_object_class_install_property
+		(object_class, PROP_UUID,
+		 g_param_spec_string (NM_ACTIVE_CONNECTION_UUID,
+		  "UUID",
+		  "UUID",
+		  NULL,
+		  G_PARAM_READABLE));
+
+	/**
 	 * NMActiveConnection:specific-object:
 	 *
 	 * The specific object's path of the active connection.
-- 
1.7.7.5

>From ee00af5446ae829b294dffc3ceb035ca851385c9 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Wed, 4 Jan 2012 13:52:46 -0500
Subject: [PATCH 03/12] libnm-glib: pre-emptively avoid some -Wshadow errors

including  will drag in some additional system headers that
result in new -Wshadow warnings. Fix those.
---
 libnm-glib/nm-client.c |6 +++---
 libnm-glib/nm-client.h |2 +-
 libnm-glib/nm-types.c  |8 
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/libnm-glib/nm-client.c b/libnm-glib/nm-client.c
index 918bc99..c622d25 100644
--- a/libnm-glib/nm-client.c
+++ b/libnm-glib/nm-client.c
@@ -1160,14 +1160,14 @@ nm_client_networking_set_enabled (NMClient *client, gboolean enable)
 /**
  * nm_client_sleep:
  * @client: a #NMClient
- * @sleep: %TRUE to put the daemon to sleep
+ * @sleep_: %TRUE to put the daemon to sleep
  *
  * Deprecated; use nm_client_networking_set_enabled() instead.
  **/
 void
-nm_client_sleep (NMClient *client, gboolean sleep)
+nm_client_sleep (NMClient *client, gboolean sleep_)
 {
-	nm_client_networking_set_enabled (client, !sleep);
+	nm_client_networking_set_enabled (client, !sleep_);
 }
 
 /**
diff --git a/libnm-glib/nm-client.h b/libnm-glib/nm-client.h
index c9fd7c1..44f1d2b 100644
--- a/libnm-glib/nm-client.h
+++ b/libnm-glib/nm-client.h
@@ -156,7 +156,7 @@ const char *nm_client_get_version(NMClient *client);
 NMState   nm_client_get_state(NMClient *client);
 gboolean  nm_client_get_manager_running  (NMClient *client);
 const GPtrArray *nm_client_get_active_connections (NMClient *client);
-void  nm_client_sleep(NMClient *client, gboolean sleep);
+void  nm_client_sleep(NMClient *client, gboolean sleep_);
 
 NMClientPermissionResult nm_client_get_permission_result (NMClient *client,
   NMClientPermission permission);
diff

[PATCH] ipoib fixes

[Dan Winship]

>From 1df0d45f94b72fbbfea698195209700757a2bcf1 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Tue, 31 Jan 2012 11:14:56 -0500
Subject: [PATCH 1/2] introspection: add missing error description for
 INFINIBAND_MODE

---
 introspection/nm-device.xml |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/introspection/nm-device.xml b/introspection/nm-device.xml
index 2f3aa8f..df40b4e 100644
--- a/introspection/nm-device.xml
+++ b/introspection/nm-device.xml
@@ -496,6 +496,11 @@
   GSM Modem's SIM wrong
 
   
+  
+
+  Infiniband device does not support connected mode.
+
+  
 
 
   
-- 
1.7.7.5

>From f05d11f403b29e6088fe81a05a0975ed0320cbe5 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Tue, 31 Jan 2012 11:15:41 -0500
Subject: [PATCH 2/2] ifcfg-rh: belatedly add writer support for infiniband
 (and tests)

---
 .../tests/network-scripts/ifcfg-test-infiniband|8 +
 .../plugins/ifcfg-rh/tests/test-ifcfg-rh.c |  225 
 src/settings/plugins/ifcfg-rh/writer.c |   46 
 3 files changed, 279 insertions(+), 0 deletions(-)
 create mode 100644 src/settings/plugins/ifcfg-rh/tests/network-scripts/ifcfg-test-infiniband

diff --git a/src/settings/plugins/ifcfg-rh/tests/network-scripts/ifcfg-test-infiniband b/src/settings/plugins/ifcfg-rh/tests/network-scripts/ifcfg-test-infiniband
new file mode 100644
index 000..b1a5743
--- /dev/null
+++ b/src/settings/plugins/ifcfg-rh/tests/network-scripts/ifcfg-test-infiniband
@@ -0,0 +1,8 @@
+TYPE=Infiniband
+DEVICE=ib0
+HWADDR=80:00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff:00:11:22
+CONNECTED_MODE=yes
+MTU=65520
+IPADDR=192.168.2.2
+NETMASK=255.255.255.0
+GATEWAY=192.168.2.1
diff --git a/src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c b/src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
index 15a3c7f..6b480ad 100644
--- a/src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
+++ b/src/settings/plugins/ifcfg-rh/tests/test-ifcfg-rh.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -11774,6 +11775,228 @@ test_read_vlan_interface (void)
 	g_free (route6file);
 }
 
+#define TEST_IFCFG_INFINIBAND TEST_IFCFG_DIR"/network-scripts/ifcfg-test-infiniband"
+
+static void
+test_read_infiniband (void)
+{
+	NMConnection *connection;
+	NMSettingInfiniband *s_infiniband;
+	char *unmanaged = NULL;
+	char *keyfile = NULL;
+	char *routefile = NULL;
+	char *route6file = NULL;
+	gboolean ignore_error = FALSE;
+	GError *error = NULL;
+	const GByteArray *array;
+	char expected_mac_address[INFINIBAND_ALEN] = { 0x80, 0x00, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0xaa, 0xbb, 0xcc, 0xdd, 0xee, 0xff, 0x00, 0x11, 0x22 };
+	const char *transport_mode;
+
+	connection = connection_from_file (TEST_IFCFG_INFINIBAND,
+	   NULL,
+	   TYPE_INFINIBAND,
+	   NULL,
+	   &unmanaged,
+	   &keyfile,
+	   &routefile,
+	   &route6file,
+	   &error,
+	   &ignore_error);
+	ASSERT (connection != NULL,
+	"infiniband-read", "failed to read %s: %s", TEST_IFCFG_INFINIBAND, error->message);
+
+	ASSERT (nm_connection_verify (connection, &error),
+	"infiniband-verify", "failed to verify %s: %s", TEST_IFCFG_INFINIBAND, error->message);
+
+	ASSERT (unmanaged == NULL,
+	"infiniband-verify", "failed to verify %s: unexpected unmanaged value", TEST_IFCFG_INFINIBAND);
+
+	/* = INFINIBAND SETTING = */
+
+	s_infiniband = nm_connection_get_setting_infiniband (connection);
+	ASSERT (s_infiniband != NULL,
+	"infiniband-verify-wired", "failed to verify %s: missing %s setting",
+	TEST_IFCFG_INFINIBAND,
+	NM_SETTING_INFINIBAND_SETTING_NAME);
+
+	/* MAC address */
+	array = nm_setting_infiniband_get_mac_address (s_infiniband);
+	ASSERT (array != NULL,
+	"infiniband-verify-infiniband", "failed to verify %s: missing %s / %s key",
+	TEST_IFCFG_INFINIBAND,
+	NM_SETTING_INFINIBAND_SETTING_NAME,
+	NM_SETTING_INFINIBAND_MAC_ADDRESS);
+	ASSERT (array->len == INFINIBAND_ALEN,
+	"infiniband-verify-infiniband", "failed to verify %s: unexpected %s / %s key value length",
+	TEST_IFCFG_INFINIBAND,
+	NM_SETTING_INFINIBAND_SETTING_NAME,
+	NM_SETTING_INFINIBAND_MAC_ADDRESS);
+	ASSERT (memcmp (array->data, &expected_mac_address[0], sizeof (expected_mac_address)) == 0,
+	"infiniband-verify-infiniband", "failed to verify %s: unexpected %s / %s key value",
+	  

Re: Fedora16 - Brain dead wireless network manager

[Dan Winship]

On 01/17/2012 08:14 AM, Robert Moskowitz wrote:
> Oh, this is on a Lenovo x120e where I see the following in the log
> messages:
> 
> Jan 16 22:16:42 lx120e kernel: [81433.007709] rtl8192c_common: Loading
> firmware file rtlwifi/rtl8192cfw.bin

The driver for that chipset is apparently broken in the current kernel:
https://bugzilla.redhat.com/show_bug.cgi?id=729618

(There are links to various testing kernels with different patches in
that bug, but it's hard to tell from the comments if they fix the
problem...)

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

[PATCH] ipoib connected mode support

[Dan Winship]

>From 3e74234e11b00ad78e9e0dc9f285e8c51ae3da37 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Mon, 14 Nov 2011 14:52:40 -0500
Subject: [PATCH] Infiniband: add transport-mode property

Add transport-mode property to NMSettingInfiniband (and parse it
correctly in ifcfg-rh), and set it up properly on the device in
NMDeviceInfiniband.
---
 include/NetworkManager.h   |3 ++
 libnm-util/libnm-util.ver  |1 +
 libnm-util/nm-setting-infiniband.c |   55 
 libnm-util/nm-setting-infiniband.h |6 ++-
 src/nm-device-infiniband.c |   49 
 src/nm-device.c|2 +
 src/settings/plugins/ifcfg-rh/reader.c |3 ++
 7 files changed, 117 insertions(+), 2 deletions(-)

diff --git a/include/NetworkManager.h b/include/NetworkManager.h
index 79cad05..3f97e28 100644
--- a/include/NetworkManager.h
+++ b/include/NetworkManager.h
@@ -479,6 +479,9 @@ typedef enum {
/* GSM Modem's SIM wrong */
NM_DEVICE_STATE_REASON_GSM_SIM_WRONG = 48,
 
+   /* Infiniband device does not support connected mode */
+   NM_DEVICE_STATE_REASON_INFINIBAND_MODE = 49,
+
/* Unused */
NM_DEVICE_STATE_REASON_LAST = 0x
 } NMDeviceStateReason;
diff --git a/libnm-util/libnm-util.ver b/libnm-util/libnm-util.ver
index 84ef039..d2c4318 100644
--- a/libnm-util/libnm-util.ver
+++ b/libnm-util/libnm-util.ver
@@ -242,6 +242,7 @@ global:
nm_setting_infiniband_error_quark;
nm_setting_infiniband_get_mac_address;
nm_setting_infiniband_get_mtu;
+   nm_setting_infiniband_get_transport_mode;
nm_setting_infiniband_get_type;
nm_setting_infiniband_new;
nm_setting_ip4_config_add_address;
diff --git a/libnm-util/nm-setting-infiniband.c 
b/libnm-util/nm-setting-infiniband.c
index 10a20ad..9e8ec9a 100644
--- a/libnm-util/nm-setting-infiniband.c
+++ b/libnm-util/nm-setting-infiniband.c
@@ -81,6 +81,7 @@ G_DEFINE_TYPE (NMSettingInfiniband, nm_setting_infiniband, 
NM_TYPE_SETTING)
 
 typedef struct {
GByteArray *mac_address;
+   char *transport_mode;
guint32 mtu;
 } NMSettingInfinibandPrivate;
 
@@ -88,6 +89,7 @@ enum {
PROP_0,
PROP_MAC_ADDRESS,
PROP_MTU,
+   PROP_TRANSPORT_MODE,
 
LAST_PROP
 };
@@ -133,6 +135,23 @@ nm_setting_infiniband_get_mtu (NMSettingInfiniband 
*setting)
return NM_SETTING_INFINIBAND_GET_PRIVATE (setting)->mtu;
 }
 
+/**
+ * nm_setting_infiniband_get_transport_mode:
+ * @setting: the #NMSettingInfiniband
+ *
+ * Returns the transport mode for this device. Either 'datagram' or
+ * 'connected'.
+ *
+ * Returns: the IPoIB transport mode
+ **/
+const char *
+nm_setting_infiniband_get_transport_mode (NMSettingInfiniband *setting)
+{
+   g_return_val_if_fail (NM_IS_SETTING_INFINIBAND (setting), NULL);
+
+   return NM_SETTING_INFINIBAND_GET_PRIVATE (setting)->transport_mode;
+}
+
 
 static gboolean
 verify (NMSetting *setting, GSList *all_settings, GError **error)
@@ -147,6 +166,20 @@ verify (NMSetting *setting, GSList *all_settings, GError 
**error)
return FALSE;
}
 
+   if (!g_strcmp0 (priv->transport_mode, "datagram")) {
+   if (priv->mtu > 2044)
+   priv->mtu = 2044;
+   } else if (!g_strcmp0 (priv->transport_mode, "connected")) {
+   if (priv->mtu > 65520)
+   priv->mtu = 65520;
+   } else {
+   g_set_error (error,
+NM_SETTING_INFINIBAND_ERROR,
+NM_SETTING_INFINIBAND_ERROR_INVALID_PROPERTY,
+NM_SETTING_INFINIBAND_TRANSPORT_MODE);
+   return FALSE;
+   }
+
return TRUE;
 }
 
@@ -161,6 +194,7 @@ finalize (GObject *object)
 {
NMSettingInfinibandPrivate *priv = NM_SETTING_INFINIBAND_GET_PRIVATE 
(object);
 
+   g_free (priv->transport_mode);
if (priv->mac_address)
g_byte_array_free (priv->mac_address, TRUE);
 
@@ -182,6 +216,10 @@ set_property (GObject *object, guint prop_id,
case PROP_MTU:
priv->mtu = g_value_get_uint (value);
break;
+   case PROP_TRANSPORT_MODE:
+   g_free (priv->transport_mode);
+   priv->transport_mode = g_value_dup_string (value);
+   break;
default:
G_OBJECT_WARN_INVALID_PROPERTY_ID (object, prop_id, pspec);
break;
@@ -201,6 +239,9 @@ get_property (GObject *object, guint prop_id,
case PROP_MTU:
g_value_set_uint (value, nm_setting_infiniband_get_mtu 
(setting));
break;
+   case PROP_TRANSPORT_MODE:
+   g_value_set_string (value, 
nm_setting_infiniband_get_transport_mode (setting));
+   break;
default:
 

bonding of non-ethernet devices

[Dan Winship]

One of the bonding commits says:

  bonding: detect virtual bonding devices and create an ethernet device

  A bonding device is like a virtual ethernet device. We therefore reuse
  nm-device-ethernet and add some special handling to detect bonding
  connections.

Exactly how much "like a virtual ethernet device" is a bond? In
particular, when you bond two infiniband devices together (or an
ethernet device and a wifi device, which is supported by the kernel
according to the internet), is the result still "like a virtual ethernet
device" in the same way? Is it more like an NMDeviceWired than an
NMDeviceEthernet? (Which may depend to some extent on questions like
"would anyone ever run 802.1x over a bond?")

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

Re: [PATCH 4/8] ethernet: Move all connection <-> device matching into a single function

[Dan Winship]

On 11/22/2011 12:44 AM, Dan Williams wrote:
> On Mon, 2011-11-21 at 17:50 +0100, Thomas Graf wrote:
>> Moves all code to match an ethernet connection into a single function
>> match_ethernet_connection() and use it from everywhere within
>> NMDeviceEthernet.
> 
> Looks good pending the outcome of the connection/interface patch.  Note
> that danw's IPoIB patches will conflict with this, do you want to wait
> for that to merge (I can do that ASAP) or do you want me to rebase his
> stuff on top of this one?  (he splits up NMDeviceEthernet into an
> abstract NMDeviceWired and a concrete NMDeviceEthernet so that
> NMDeviceInfiniband can be a subclass of NMDeviceWired).

There will need to be a little bit of additional work beyond the
reorganization to get infiniband bonding to work as well, so it might
make sense to land bonding first? (Or not. I guess we could land base
ipoib first, then ethernet bonding, then ipoib bonding later.)

(FWIW, I'm gone for the rest of this week and then at the WebKitGTK
hackfest next week, so I won't be hacking on ipoib much for the next two
weeks.)

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

Re: [PATCH] core: add internet connectivity check

[Dan Winship]

On 11/16/2011 01:19 AM, Dan Williams wrote:
>> ./NetworkManager --no-daemon --log-level=DEBUG --log-domains=CORE
>> --connectivity-uri=http://toabctl.de
>> --connectivity-response="toabctl.de"
> 
> Pretty much what I was thinking about, but I wonder what we should do
> for the expected response.  I'm not sure a regex is the right way to go
> at the moment because regex libraries differ in syntax and that might
> tie us into a specific one.  But regex is powerful :)  I think maybe for
> the moment we should just specify that it's a string match.  Then later
> when more intelligently handling hotspot perhaps we'll do regexes.

My theory on this was to always request a plain-text file, and then if
you get back anything HTML, you automatically know it's wrong.

-- Dan

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

Re: glib >= 2.31.0 Threads and Mutexes

[Dan Winship]

On 10/31/2011 10:26 AM, martin...@gmx.net wrote:
> Hello list!
> 
> There was a change in the threads and mutexes API in glib starting with 
> version 2.31, see http://git.gnome.org/browse/glib/tree/NEWS. Especially 
> g_thread_init(), g_thread_create(), g_mutex_new() and g_mutex_free() are 
> gone.  I replaced those as follows:
> 
> - made g_thread_init conditional, as demonstrated in 
> https://bugs.freedesktop.org/show_bug.cgi?id=42036.

g_thread_init() has been unnecessary since glib 2.24 in any program that
uses GObjects. NM claims to only require glib 2.18 right now... I don't
know if that's true or not.

> - g_mutex_new() replaced by static declarations of GMutex-es and 
> (conditionally) passing their references where g_mutex_new() used to be called

The right replacement is to replace

  GMutex *foo;
  ...
  foo = g_mutex_new ();
  ...
  g_mutex_lock (foo);
  ...
  g_mutex_free (foo);

with:

  GMutex foo;
  ...
  g_mutex_init (&foo);
  ...
  g_mutex_lock (&foo);
  ...
  g_mutex_clear (&foo);
___
networkmanager-list mailing list
networkmanager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list

[PATCH] libnm-util: add some more introspection annotations to, silence warnings

[Dan Winship]

the warnings were annoying me :)

It doesn't fix everything. These warnings:

nm-ip4-config.h:65: Warning: NMClient: Return value is not superclass
for constructor; symbol='nm_ip4_config_new'
constructed='NMClient.IP4Config' return='GObject.Object'

are only fixed with the very latest gobject-introspection.

These warnings:

:: Warning: NetworkManager:
(ErrorQuarkFunction)setting_error_quark:
context=ErrorQuarkFunction('setting_error_quark')
nm_setting_error_quark: Couldn't find corresponding enumeration

aren't fixed. https://bugzilla.gnome.org/show_bug.cgi?id=656506
>From c8457c586afc9d9d3ec36a2b140b450845a68a94 Mon Sep 17 00:00:00 2001
From: Dan Winship 
Date: Thu, 13 Oct 2011 12:24:04 -0400
Subject: [PATCH] libnm-util: add some more introspection annotations to
 silence warnings

---
 libnm-util/nm-connection.c |4 ++--
 libnm-util/nm-setting.c|8 
 libnm-util/nm-utils.c  |   10 +-
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/libnm-util/nm-connection.c b/libnm-util/nm-connection.c
index d59c8b4..6a10128 100644
--- a/libnm-util/nm-connection.c
+++ b/libnm-util/nm-connection.c
@@ -975,8 +975,8 @@ nm_connection_clear_secrets (NMConnection *connection)
 /**
  * nm_connection_clear_secrets_with_flags:
  * @connection: the #NMConnection
- * @func: function to be called to determine whether a specific secret should 
be
- *  cleared or not
+ * @func: (scope call): function to be called to determine whether a
+ * specific secret should be cleared or not
  * @user_data: caller-supplied data passed to @func
  *
  * Clears and frees secrets determined by @func.
diff --git a/libnm-util/nm-setting.c b/libnm-util/nm-setting.c
index 7ec4278..2b3bdc5 100644
--- a/libnm-util/nm-setting.c
+++ b/libnm-util/nm-setting.c
@@ -308,8 +308,8 @@ nm_setting_get_name (NMSetting *setting)
 /**
  * nm_setting_verify:
  * @setting: the #NMSetting to verify
- * @all_settings: a #GSList of all settings in the connection from which 
@setting
- * came
+ * @all_settings: (element-type NMSetting): a #GSList of all settings
+ * in the connection from which @setting came
  * @error: location to store error, or %NULL
  *
  * Validates the setting.  Each setting's properties have allowed values, and
@@ -670,8 +670,8 @@ clear_secrets_with_flags (NMSetting *setting,
 /**
  * nm_setting_clear_secrets_with_flags:
  * @setting: the #NMSetting
- * @func: function to be called to determine whether a specific secret should 
be
- *  cleared or not
+ * @func: (scope call): function to be called to determine whether a
+ * specific secret should be cleared or not
  * @user_data: caller-supplied data passed to @func
  *
  * Clears and frees secrets determined by @func.
diff --git a/libnm-util/nm-utils.c b/libnm-util/nm-utils.c
index d8bcf34..9d4418e 100644
--- a/libnm-util/nm-utils.c
+++ b/libnm-util/nm-utils.c
@@ -490,7 +490,7 @@ nm_utils_gvalue_hash_dup (GHashTable *hash)
 }
 
 /**
- * nm_utils_slist_free:
+ * nm_utils_slist_free: (skip)
  * @list: a #GSList
  * @elem_destroy_fn: user function called for each element in @list
  *
@@ -1373,7 +1373,7 @@ nm_utils_ip4_addresses_from_gvalue (const GValue *value)
 
 /**
  * nm_utils_ip4_addresses_to_gvalue:
- * @list: a list of #NMIP4Address objects
+ * @list: (element-type NMIP4Address): a list of #NMIP4Address objects
  * @value: a pointer to a #GValue into which to place the converted addresses,
  * which should be unset by the caller (when no longer needed) with
  * g_value_unset().
@@ -1456,7 +1456,7 @@ nm_utils_ip4_routes_from_gvalue (const GValue *value)
 
 /**
  * nm_utils_ip4_routes_to_gvalue:
- * @list: a list of #NMIP4Route objects
+ * @list: (element-type NMIP4Route): a list of #NMIP4Route objects
  * @value: a pointer to a #GValue into which to place the converted routes,
  * which should be unset by the caller (when no longer needed) with
  * g_value_unset().
@@ -1664,7 +1664,7 @@ nm_utils_ip6_addresses_from_gvalue (const GValue *value)
 
 /**
  * nm_utils_ip6_addresses_to_gvalue:
- * @list: a list of #NMIP6Address objects
+ * @list: (element-type NMIP6Address): a list of #NMIP6Address objects
  * @value: a pointer to a #GValue into which to place the converted addresses,
  * which should be unset by the caller (when no longer needed) with
  * g_value_unset().
@@ -1786,7 +1786,7 @@ nm_utils_ip6_routes_from_gvalue (const GValue *value)
 
 /**
  * nm_utils_ip6_routes_to_gvalue:
- * @list: a list of #NMIP6Route objects
+ * @list: (element-type NMIP6Route): a list of #NMIP6Route objects
  * @value: a pointer to a #GValue into which to place the converted routes,
  * which should be unset by the caller (when no longer needed) with
  * g_value_unset().
-- 
1.7.6.4

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

Re: [Fwd: [vpnc-devel] IPv6 support in vpnc-script]

[Dan Winship]

On 11/11/2009 05:07 AM, David Woodhouse wrote:
> We have IPv6 support in NetworkManager now, right? So extending
> NetworkManager-openconnect and NetworkManager-vpnc to set up the IPv6
> routing shouldn't be so hard?

It supports IPv6 for direct connections, but not yet for VPNs. See
https://bugzilla.gnome.org/show_bug.cgi?id=593813.

I guess if VPNC supports IPv6 then I guess we could just say "all VPNs
at least potentially support IPv6" and just unconditionally add the IPv6
page when configuring a VPN too. The iface vs ip_iface thing mentioned
in the bug will probably still be a problem though.

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