Move the GObject-related stuff to the bottom of the file and get
rid of no-longer-necessary forward prototypes since the stuff that
required those prototypes is now below the implementation.
Instead of creating most routes with metric 0 and then fixing them
just before applying them, create the routes with the correct metric
in the first place (so that NMIP4Config and NMIP6Config don't have to
try to guess whether "metric 0" means "unset" or "actually metric 0").
If a link's "master" property changes unexpectedly (ie, from outside
NM), update the master and slave NMDevices to reflect it, without
making any changes to them.
The process of activating a slave requires that its master have an
NMActiveConnection. So don't allow generating a connection on a slave
until we have generated the connection on the master.
nm_device_generate_connection() was allowing connections for master
devices to have no IP config, but this didn't really make much sense,
since they would just fail at stage3 in that case anyway.
Now that we get multiple tries at generating a connection on a device,
we can just ignore the device until it has a proper connection.
If the initial attempt to assume a connection on a device fails, and
the device remains un-activated, but then something changes its
configuration externally, try to generate a new connection and assume
that.
If the IP config changes on a device that has assumed a generated
connection, then update the connection's NMSettingIP4Config /
NMSettingIP6Config, under the assumption that the configuration of
that device was in progress but incomplete when NM first observed it.
NMIP4Config and NMIP6Config had methods to update an existing
NMSetting. However, the functions would really only work correctly if
the passed-in setting was empty.
Change them from "update_setting" to "create_setting", and have them
create the NMSetting themselves, and update NMDevice for that.
(If we need update_setting later, we can add it, after figuring out
exactly how it's actually supposed to work.)
Firewalld call addInterface() fails with ZONE_CONFLICT if the interface
is already part of another zone. This complicates the code in NM,
because we would have to keep better track of the zone in which the
interface currently is. Which might be quite difficult because
the zone might be changed from an external program (so we would have
to monitor the firewall configuration and work around potential races).
A better and simpler fix is to simply always use the changeZone() call.
This will do the right thing, regardless if the interface is already part
of a zone or not.
https://bugzilla.redhat.com/show_bug.cgi?id=1103782
Signed-off-by: Thomas Haller <thaller@redhat.com>
The firewalld removeInterface call fails with ZONE_CONFLICT when
removing an interface from a wrong zone. This can happen, when the
connection gets modified, while being active (which is related to
bgo#724041).
By not specifying any zone, we remove the interface from the zone
where it currently is added. This behavior was introduced in upstream
firewalld with commit cc3101ab70a3997228be7bc9f45a069c7fccfa36, March 2012,
r0_2_3-1.
This is the behavior we actually want and we don't have to keep proper track
of the current zone.
https://bugzilla.redhat.com/show_bug.cgi?id=1103782
Signed-off-by: Thomas Haller <thaller@redhat.com>
Fixes the following g_warn():
#0 0x0000003370c504e9 in g_logv () from /lib64/libglib-2.0.so.0
#1 0x0000003370c5063f in g_log () from /lib64/libglib-2.0.so.0
#2 0x0000003370c50956 in g_warn_message () from /lib64/libglib-2.0.so.0
#3 0x0000000000439962 in carrier_changed (device=0x1d94300, carrier=1) at devices/nm-device.c:1021
#4 0x0000000000488f12 in carrier_changed (device=0x1d94300, carrier=1) at devices/nm-device-ethernet.c:1646
#5 0x0000000000434c94 in nm_device_set_carrier (device=device@entry=0x1d94300, carrier=1) at devices/nm-device.c:1104
#6 0x0000000000434dd5 in check_carrier (device=device@entry=0x1d94300) at devices/nm-device.c:1298
#7 0x0000000000434ef8 in constructed (object=0x1d94300) at devices/nm-device.c:550
#8 0x0000003371c15d87 in g_object_new_internal () from /lib64/libgobject-2.0.so.0
#9 0x0000003371c17814 in g_object_new_valist () from /lib64/libgobject-2.0.so.0
#10 0x0000003371c17c11 in g_object_new () from /lib64/libgobject-2.0.so.0
#11 0x000000000048bc2e in nm_device_ethernet_new (platform_device=platform_device@entry=0x1d82e58) at devices/nm-device-ethernet.c:336
#12 0x000000000047c600 in platform_link_added (self=0x1d70150, ifindex=ifindex@entry=2, plink=plink@entry=0x1d82e58, reason=reason@entry=NM_PLATFORM_REASON_INTERNAL) at nm-manager.c:1954
#13 0x000000000047c7db in platform_link_cb (platform=<optimized out>, ifindex=2, plink=0x1d82e58, change_type=<optimized out>, reason=NM_PLATFORM_REASON_INTERNAL, user_data=0x1d70150) at nm-manager.c:2038
#14 0x0000003371805d8c in ffi_call_unix64 () from /lib64/libffi.so.6
#15 0x00000033718056bc in ffi_call () from /lib64/libffi.so.6
#16 0x0000003371c10ad8 in g_cclosure_marshal_generic () from /lib64/libgobject-2.0.so.0
#17 0x0000003371c10298 in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#18 0x0000003371c2235d in signal_emit_unlocked_R () from /lib64/libgobject-2.0.so.0
#19 0x0000003371c2a0f2 in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#20 0x0000003371c2a3af in g_signal_emit () from /lib64/libgobject-2.0.so.0
#21 0x000000000044f6ba in nm_platform_query_devices () at platform/nm-platform.c:330
#22 0x000000000047de4c in nm_manager_start (self=0x1d70150) at nm-manager.c:4025
#23 0x0000000000429d31 in main (argc=1, argv=0x7fffb4c31628) at main.c:654
https://mail.gnome.org/archives/networkmanager-list/2014-June/msg00000.html
Signed-off-by: Thomas Haller <thaller@redhat.com>
This feature requires recent support from the kernel.
Most notably these upstream kernel commits are required:
- 92c0574f11598c8036f81e27d2e8bdd6eed7d76d
- 43598813386f6205edf3c21f1fe97f731ccb4f15
- 30313a3d5794472c3548d7288e306a5492030370
The latter of them was merged to upstream kernel version 3.15-rc5.
https://bugzilla.gnome.org/show_bug.cgi?id=729844
Signed-off-by: Thomas Haller <thaller@redhat.com>
Add an additional address parameter to link_add/bridge_add, to set the
MAC address of software devices.
https://bugzilla.gnome.org/show_bug.cgi?id=729844
Signed-off-by: Thomas Haller <thaller@redhat.com>
It's only ever used as an MAC address array, so we might as well
make it one instead of a string. Saves a memory allocation and
some cycles converting back and forth.
This also fixes a bug, where NMDeviceBt:check_connection_compatible()
would not set GError on mismatch of bdaddr.
Signed-off-by: Thomas Haller <thaller@redhat.com>
Thomas points out that the previous refactoring moved the
link_changed() virtual method invocation relative to
update_for_ip_ifname_change(), which could have weird side effects
given the things that can happen there. So move it back.
Bond, bridge, and team were notifying their "slaves" properties before
the slave actually got removed from priv->slaves, meaning that
anything that looked at the property directly from a notify::slaves
handler would see the old value. Fix that.
Keep priv->slaves in the order that slaves were attached, rather than
in reverse order.
Among other things, this makes the errors from
nm_device_master_check_slave_physical_port() more consistent.
For the factory, the only public symbols should be the factory functions.
For the WWAN library, the only public symbols should be those that
NMDeviceModem and NMDeviceBt use.
Instead of having a GObject property and a factory function to get
the plugin's device type, just use the factory function, since it
always has to be around.
The mesh and Wi-Fi companion share radio hardware and firmware resources
and you need both to exist for the mesh to function properly and to
ensure that the Wi-Fi and mesh sides cooperate correctly for scanning
and activation.
If the supplicant interface object never successfully initialized, remove
the pending action to prevent warnings about "pending action already added"
when supplicant_interface_acquire() adds the pending action again.
Just listen to manager signals all the time, but only respond to
them when necessary. Clean up companion detection to be a bit
clearer, and use nm_device_queue_state() so that we don't need
an idle handler when detecting the companion from a state change
handler.
There used to be many more members of the Supplicant struct, but now
that there are only three, collapse the struct into the NMDeviceWifiPrivate
struct, renaming them slightly at the same time to shorten the names.
Second, consolidate timeout cleanup since the two remaining timeouts
don't need their own cleanup functions.
Third, start_supplicant_connection_timeout() doesn't need its own
function since g_timeout_add() never returns 0, so we don't need to
check for it.
The only reason for the small struct was the idle handler, and the
only reason for the idle handler was to ensure that state was changed
from an idle handler. We've got nm_device_queue_state() to do that
for us now, so use it.
Make Wi-Fi support a plugin using the new device factory interface.
Provides a 7% size reduction in the core NM binary.
Before After
NM: 1154104 1071992 (-7%)
Wi-Fi: 0 110464
(all results from stripped files)
Older Intel "ipw" devices (ipw2100, ipw2200, and ipw2915) only gained
kernel rfkill subsystem integration with 2.6.33. Before then their
custom rfkill functionality had to be polled via sysfs. Since we now
require at least a 3.x kernel, remove this old code.
The domain LOGD_OLPC_MESH is known as "OLPC". This is the only case where
the internal name LOGD_X does not correspond to the external name X.
Signed-off-by: Thomas Haller <thaller@redhat.com>
If IPv6 completes first it would emit the "up" dispatcher event with IPv6
details and move the device to ACTIVATED state. But if DHCPv4 was still
running, no dispatcher event would be emitted with the DHCPv4 information
until the first lease renew. Thus dispatcher scripts would not receive
DHCPv4 information for quite some time.
Ensure that if the other IP version completes first, that when the slower
method's DHCP completes, that it emits the appropriate dhcp4-change
or dhcp6-change event so that dispatcher scripts get the information
as soon as it's available.
https://bugzilla.gnome.org/show_bug.cgi?id=729284
