Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
It is an extension compared to initscripts (not in sysconfig.txt). But it is
necessary for preserving dhcp-send-hostname. Missing DHCP_SEND_HOSTNAME is
treated as "yes", which matches dhcp-send-hostname default value being TRUE.
https://bugzilla.redhat.com/show_bug.cgi?id=1001529
|
|
#1001529)
It is better to leave it to user whether he wants to enable sending hostname,
because he probably disabled it manually (dhcp-send-hostname is TRUE by default).
Also, this would not work for plugins that read and set dhcp-hostname after
dhcp-send-hostname.
https://bugzilla.redhat.com/show_bug.cgi?id=1001529
|
|
Workaround a serious issue, that a connection that failed to activate
might retry to autoconnect indefinitly.
In NMPolicy, device_state_changed() decrements the retry count for
autoconnect. But immediatly it calls nm_connection_clear_secrets(),
which in turn triggers an NM_SETTINGS_SIGNAL_CONNECTION_UPDATED signal.
The problem is, that connection_updated() resets the try count again to
the default, and thus, the counter was effictivly not decremented.
For now, do not reset the retry count in connection_updated(). This
works arount the issue, but means, that when a user changes the
connection, it is not immediatly retried to autoconnect (as the intent
originally was). This will be fixed later.
https://bugzilla.redhat.com/show_bug.cgi?id=1040528
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
Attempting an immediate reconnect if the peer terminates the connection
sometimes results in the peer not being ready to negotiate a new
connection, while a short delay allows the peer to correctly tear
down the old connection and get listen for a new one. Introduce
a short delay when activating a PPPoE connection if a PPPoE
connection was recently deactivated.
https://bugzilla.redhat.com/show_bug.cgi?id=1023503
https://bugzilla.redhat.com/show_bug.cgi?id=602265
Rebased to master by jklimes.
|
|
|
|
`make check` '--with-valgrind=yes' failed due to memory leaks detected
by valgrind. These leaks originate from glib structures, and should be
ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=705160
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
Keyfile plugin writer had a bug, when writing IP6 routes with gateway
"::". Instead of writing "net/plen,,metric" it wrote "net/plen,metric".
- fix this bug and add test cases. Also, add a workaround to reader, to
accept such wrongly written IP6 routes as valid.
- change the writer for IP4 addresses, IP4 routes and IP6 routes to
omit the gateway and the metric, if it is 0.0.0.0/::/0, respectively.
Also change the reader, to accept such empty gateway as valid.
It only omits the gateway, if the metric is not 0, this means it would
write:
route1=1.2.3.4/24,0.0.0.0,1
instead of
route1=1.2.3.4/24,,1
Both representations are now supported by the reader, but older plugin
versions could only read the former (thus, we keep writing that
version).
With a metric of zero, it would instead write:
route1=1.2.3.4/24
- some refactoring and code cleanup. Fix a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=719851
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
ip6_addr_to_string did assume, that inet_ntop might write a scope id to
the result. But it does not (and cannot, because struct in6_addr does
not have any interface identifer).
Simplify and rework the function.
Also fix a memory leak.
https://bugzilla.gnome.org/show_bug.cgi?id=711684
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=711684
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=711684
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
|
|
Commit 6abc7b78f68e2e815bf8a8cec2a3235e35bb07e4 introduced a
bug in nm_connection_diff() by not reading the property value with
g_object_get_property().
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
Because it's not trivial to generate a connection that exactly matches
one which was applied by NetworkManager before a restart, we need to
make matching somewhat fuzzier. Mark any setting property that can be
read from the system or kernel as INFERRABLE, and match only on those
properties when trying to find the persistent connection (if any) which
is already active on that device.
https://bugzilla.redhat.com/show_bug.cgi?id=1029859
|
|
nm_connection_diff must also use the virtual functions like
nm_connection_compare. This way, settings can overwrite the default
comparison of individual properties.
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
When a gateway is not in the prefix of any of the interface's IP addresses,
NetworkManager adds a static host route to the gateway through the
interface to ensure the gateway can be reached. That route will not
be part of the persistent connection (since it was added automatically)
but would normally be picked up by connection generation. This would
cause the generated connection not to match with the persistent
connection, because the persistent connection does not have the host
route. Ignore the gateway host route when capturing the interface's
existing IP configuration.
|
|
When generating a connection, if the device has no non-link-local IPv6
address, then it's unclear whether (a) the connection was link-local
originally, or (b) the connection was 'auto' but IPv6 failed or timed
out.
In this case, if there is a persistent connection that is 'auto' but
the generated connection is 'link-local', the persistent connection
should be used.
Add a more-testable framework for doing the connection matching to
handle this.
|
|
Do a quick check to see if the connetion is compatible with the device
before we start doing a relatively heavy connection comparison.
|
|
INFERRABLE means the opposite of CANDIDATE; a property which NetworkManager
can read ("infer") from the system or the kernel when generating
connections. CANDIDATE isn't a great name and thus dies.
|
|
platform/nm-linux-platform.c: In function 'build_rtnl_addr':
platform/nm-linux-platform.c:116:15: error: 'bcaddr' may be used uninitialized in this function [-Werror=maybe-uninitialized]
nl_addr_put (*object);
^
platform/nm-linux-platform.c:2264:32: note: 'bcaddr' was declared here
auto_nl_addr struct nl_addr *bcaddr;
^
|
|
Suppress logging the following line:
<warn> Error creating directory "/var/run/NetworkManager": 17 (File exists)
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
|
|
We can only create virtual interfaces when the connection has autoconnect
property *and* the device was not manually disconnected before.
Without this commit NetworkManager would auto-activate all virtual connections
when a change was done (e.g. new virtual connection was addded).
|
|
When a device is initialized to be managed, it will transition through states
unmanaged -> unavailable -> disconnected. We don't want to remove software
devices during this initial transition to disconnected, because it prevents
auto-activation.
Test case:
$ nmcli con add type vlan ifname myvlan dev eth0 id 123
NM should immediately create myvlan interface and automatically activate it.
https://bugzilla.redhat.com/show_bug.cgi?id=1035814
|
|
If an agent returns a UserCanceled error in response to a secrets
request, don't ask any other remaining secret agents for secrets.
|
|
When an activation request requires secrets, if there is a secret
agent in the process that made the request, then prefer that to all
other secret agents.
|
|
Rather than explicitly passing around a UID and a flag saying whether
or not it's relevant.
(This also fixes a bug where the wrong UID was being recorded in
nm-settings-connection.c::auth_start(), which caused problems such as
agent-owned secrets not getting saved because of a perceived UID
mismatch.)
|
|
and ensure that main() frees the singleton before exiting
|
|
If the prefix length was 128, that could cause an access beyond the
end of the array. Found by Thomas Haller.
|
|
When moving over the platform, setting of the IPv4 broadcast address
got lost. Bring it back.
https://bugzilla.redhat.com/show_bug.cgi?id=1032819
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=715196
|
|
Slaves have no IP configuration and should not have any IP settings.
This fixes connection comparison between generated slave connections
and persistent slave connections, as persistent slave connections won't
have any IP configuration.
|
|
Generic connections need an interface name, and that can only be
stored in the Connection setting.
|
|
This reverts commit 9a019f1fb5b7d99a7d4ec7af89212402ea81793a.
Generic connections should be bound to their interface names in a more generic
way instead of in nm-device.c. The Generic device itself should set the
attributes it needs when generating the connection, like other device types do.
This will be done in a following commit.
|
|
If the connection describes a bridge/bond/team/etc slave, where the
slave setting (like NMSettingBridgePort or NMSettingTeamPort) has all
default values, the setting does not get written out because the
plugin does not write default values. But then when reading the
connection back in, we need to add that all-default slave type setting
since it's required for a valid connection.
|
|
Zero values are actually valid values for various bridge options
and should be written out. Otherwise, when reading the property
back in, it gets assigned the default value which is often not
zero, causing the wrong value to be set in the connection.
Only properties with default values should not be written out.
|
|
The only property that is not serializes is each settings' 'name'
property, so the flag serves no purpose.
|
|
Signed-off-by: Thomas Haller <thaller@redhat.com>
|
|
In the migration to NMPlatform, support for ptp/peer addresses was
accidentally dropped. This broke OpenVPN configurations using 'p2p'
topology, which send a different peer address than the local address
for tunX, plus the server may also push routes that use the peer
address as the next hop. NetworkManager was unable to add these
routes, because the kernel had no idea how to talk to the peer,
because the peer's address was not assigned to any interface or
reachable over any routes.
Partly based on a patch from Dan Williams.
|
|
https://bugzilla.redhat.com/show_bug.cgi?id=1036545
|
|
This commit fixes a regression from a1f16cd4d9fff66d7feeee0846e554c9c3a5f998
(nm-policy.c change).
https://bugzilla.redhat.com/show_bug.cgi?id=1029854
|
|
|
|
|
|
nm_connection_get_virtual_iface_name() doesn't work when determining virtual
connections, because for VLANs it can return NULL.
See also commit e1e4740648d3ee522c8a80d1af6282afce94f53d.
https://bugzilla.redhat.com/show_bug.cgi?id=1034908
|
|
|
|
|