| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Notably, PAGER, TERM and NO_COLORS.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1419
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an interface to the Checkpoint/Restore functionality that's
available for quite some time. It runs a command with a checkpoint taken
and rolls back unless success is confirmed before the checkpoint times
out:
$ nmcli dev checkpoint eth0 -- nmcli dev dis eth0
Device 'eth0' successfully disconnected.
Type "Yes" to commit the changes: No
Checkpoint was removed.
The details about how it's used are documented in nmcli(1) and
nmcli-examples(7).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a global "--offline" option and allows its use with "add" and
"modify" commands. The "add" looks like this:
$ nmcli --offline conn add type ethernet ens3 ipv4.dns 192.168.1.1 \
>output.nmconnection
The "modify" is essentially implementing what's been suggested by
Beniamino in bugzilla ticked (referred to below):
$ nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 \
<input.nmconnection >output.nmconnection
Other commands don't support the argument at the moment:
$ nmcli --offline c up ens3
Error: 'up' command doesn't support --offline mode.
https://bugzilla.redhat.com/show_bug.cgi?id=1361145
|
|
|
|
| |
This is used to move a connection to a different settings plugin.
|
|
|
|
|
|
|
| |
Follow-up commits are going color Wi-Fi networks and connections that rely
on deprecated features differently, to provide a visual cue.
Add color definitions for those.
|
|
|
|
|
|
|
|
| |
These were added without documentation.
Fixes: 16cff1149a76 ('core: fix taking over external connection after restart')
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1137
|
|
|
|
| |
connect|disconnect`
|
| |
|
|
|
|
|
|
|
| |
nmcli now accepts `nmcli device up|down` which works the same way as
`nmcli device connect|disconnect`
I also edited man pages of nmcli with new options.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NetworkManager is now able to configure veth interfaces throught the
NMSettingVeth. Veth interfaces only have "peer" property.
In order to support Veth interfaces in NetworkManager the design need
to pass the following requirements:
* Veth setting only has "peer" attribute.
* Ethernet profiles must be applicable to Veth interfaces.
* When creating a veth interface, the peer will be managed by
NetworkManager but will not have a profile.
* Veth connection can reapply only if the peer has not been modified.
* In order to modify the veth peer, NetworkManager must deactivate the
connection and create a new one with peer modified.
In general, it should support the basis of veth interfaces but without
breaking any existing feature or use case. The users that are using veth
interfaces as ethernet should not notice anything changed unless they
specified the veth peer setting.
Creating a Veth interface in NetworkManager is useful even without the
support for namespaces for some use cases, e.g "connecting one side of
the veth to an OVS bridge and the other side to a Linux bridge" this is
done when using OVN kubernetes [1][2]. In addition, it would provide
persistent configuration and rollback support for Veth interfaces.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1885605
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1894139
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/444
|
| |
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/582
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/565
|
|
|
|
|
|
|
|
| |
There should be a comma after 'Otherwise' and 'Currently'.
https://bugzilla.redhat.com/show_bug.cgi?id=1852452
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/560
|
|
|
|
|
| |
The aliases are now shown in `man nm-settings-nmcli`. Also the list there
gets generated and isn't hardcoded.
|
|
|
|
|
|
|
| |
monitor-connection-files was deprecated and disabled by default for a long
time. In the meantime, it has no effect at all.
Remove references from the manual pages.
|
| |
|
|
|
|
|
|
| |
A quick overview of the currently connected Wi-Fi network, including
credentials. Comes handy if someone wants to connect more devices to
their Hotspot or the same network as they are connected to.
|
|
|
|
| |
See-also: https://no-color.org/
|
|
|
|
|
|
|
|
| |
There is some guess work done on the client side. Perhaps the
o.fd.NM.Device could be extended to indicate which kill switch is the
device disabled by. This could be good enough for now though.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/271/commits
|
| |
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/188
|
|
|
|
| |
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/merge_requests/64
|
|\
| |
| |
| | |
https://github.com/NetworkManager/NetworkManager/pull/137
|
| |
| |
| |
| |
| |
| |
| | |
Try to locate an existing connection before creating a new one when
handling "nmcli device wifi connect". This allows WPA-Enterprise
networks to be activated this way, consistent with the comment that this
command is equivalent to clicking on an SSID in a GUI client.
|
|/
|
|
|
|
|
|
| |
Correct the spelling across the *entire* tree, including translations,
comments, etc. It's easier that way.
Even the places where it's not exposed to the user, such as tests, so
that we learn how is it spelled correctly.
|
|
|
|
| |
Fixes: 17f9801e07df0c544e0416c65cedc28727476e55
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Manually disconnecting a profile of course blocks autoconnect of the
same profile. Otherwise, the profile would likely re-activate right
away, which is clearly against the users intention. If the users just
want to re-activate the profile, they should issue `nmcli connection up`
instead, with does a full down and up cycle.
This is more interesting for profiles that have 'connection.multi-connect'
set to 'multiple'. Would you expect that manually deactivating such a
profile blocks autoconnect of the profile on all devices? Maybe
yes, maybe not. Currently that is indeed the case and autoconnect gets
blocked regardless of multi-connect.
|
|
|
|
| |
Options are displayed in a random order, sort them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Already since 1.0.0 release and commit "3784678177 cli: create a connection
if none exist in 'nmcli dev connect' (rh #1113941)", device-connect can
also create a profile.
That is useful, in particular as opposed to
$ nmcli connection up ifname "$DEVICE"
which wouldn't create a profile (ever).
Document it.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The present version of the specification is somewhat unclear at times,
Unclear points were discussed with the maintainers [1] and probably
some new version will address those.
https://www.spinics.net/lists/util-linux-ng/msg15222.html
Until then here's how the implementation copes with ambiguities
(after the discussion with util-linux maintainers):
1.) It is unclear whether multiple .schem files should override each
other or be merged. We use the overriding behavior -- take the
highest priority one and ignore the rest.
2.) We assume "name.schem" is more specific than "@term.schem".
3.) We assume the "Color name" are to be used as aliases for the color
sequences and translate them to ANSI escape sequences.
4.) The "Escape sequences" are of no use since the specification
pretty much assumes an ANSI terminal and none of the sequences make
any sense in ANSI color codes. We don't support them.
accept that.
5.) We don't implement TERMINAL_COLORS_DEBUG because it's unspecified
what should it do.
|
| |
|
|
|
|
|
|
| |
Clarify that the description refers to the alias, not to the property.
https://bugzilla.redhat.com/show_bug.cgi?id=1482772
|
|
|
|
| |
s/It's equivalent of/It's equivalent to/
|
| |
|
|
|
|
| |
Quick and easy way to get clean and parsable field values.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nmcli has a heuristic when setting the team-config to accepting both
a filename or the plain json text.
Add support for two schemes "file://" and "json://" to explicitly
determine whether to read from file or from json.
Also, no longer silently ignore an all-whitespace word. That is an
error (unless you have a file named " ").
Also, no longer replace newlines with space. Don't mangle the input
text at all.
|
| |
|
| |
|
| |
|