Add NMDeviceGeneric, to provide generic support for unknown device
types, and create NMDeviceGenerics for those devices that NM
previously was ignoring. Allow NMSettingGeneric connections to be
activated on (managed) NMDeviceGenerics.
Avoid warnings about GValueArray being deprecated by adding macros
that wrap G_GNUC_BEGIN_IGNORE_DEPRECATIONS /
G_GNUC_END_IGNORE_DEPRECATIONS around the GValueArray calls.
Some wireless devices don't support Ad-Hoc mode. Expose this fact in
the wireless capabilities so that clients can disable the hot-spot
option if neither CAP_ADHOC nor CAP_AP is available.
https://bugzilla.gnome.org/show_bug.cgi?id=692869
Make setting type registration less icky; instead of having the
connection register all the settings, have the settings themselves
register that information at library load time. Putting this sort
of thing in G_DEFINE_TYPE_WITH_CODE is apparently more standard
than the home-rolled stuff we had before. Also document the
priority stuff so when adding new settings, people know what
priority to use.
(cleanups by jklimes)
A new value for NM80211Mode is introduced (NM_802_11_MODE_AP) and the
new mode is passed to wpa_supplicant analogous to adhoc-mode.
The places which need to know the interface mode have been extended to
handle the new mode.
If the configuration does not contain a fixed frequency, a channel is
selected the same way as with adhoc-mode before.
When the supplicant starts connecting, or gets disconnected, track
whether it ever starts talking to an AP. Then if the connection fails
as a result of an initial connection timeout or a link timeout, we
can use SSID_NOT_FOUND when we're reasonably sure the AP doesn't
exist. Clients can use this to show better error messages.
Note that SSID_NOT_FOUND may only be reported when using nl80211
drivers, as WEXT drivers don't provide the status necessary to
determine whether the network exists or not.
They aren't in the right place anyway (they need to be after the
'enum' and before the '{') and they aren't consistently used. We'll
add them back later for everything if we need them.
Allows agents to provide different behavior depending on whether the
secrets request was initiated by a user (eg by picking a connection
from a UI menu or by 'nmcli con up') or was automatically started by
NetworkManager.
See https://bugzilla.gnome.org/show_bug.cgi?id=660293
Add new API to allow passing both IPv4 and IPv6 configuration
information from VPN plugins to the backend.
Now instead of a single Ip4Config, a plugin has Config, Ip4Config, and
Ip6Config. "Config" contains information which is neither IPv4 nor
IPv6 specific, and also indicates which of Ip4Config and Ip6Config are
present. Ip4Config now only contains the IPv4-specific bits of
configuration.
There is backward compatibility in both directions: if the daemon is
new and the VPN plugin is old, then NM will notice that the plugin
emitted the Ip4Config signal without having emitted the Config signal
first, and so will assume that it is IPv4-only, and that the generic
bits of configuration have been included with the Ip4Config. If the
daemon is old and the plugin is new, then NMVPNPlugin will copy the
values from the generic config into the IPv4 config as well. (In fact,
NMVPNPlugin *always* does this, because it's harmless, and it's easier
than actually checking the daemon version.)
Currently the VPN is still configured all-at-once, after both IPv4 and
IPv6 information has been received, but the APIs allow for the
possibility of configuring them one at a time in the future.
Even if a VPN is only tunneling IPv4, you might still be connected to
the tunnel endpoint via IPv6. Allow
NM_VPN_PLUGIN_IP4_CONFIG_EXT_GATEWAY to be either an IPv4 or an IPv6
address, and set up an appropriate static route either way.
This is the "juice" of the patch series. Initial cut at carrier handling
(by polling /sys/class/atm/$iface/carrier) and also support for calling
pppd with the proper command-line to achieve a connection.
Also implement the necessary boilerplate for the NM state machine to
be happy with our device.
This is a "duct tape and gum" implementation, i.e., prefer copy&paste
over proper refactoring, due to limited time, but the foundations are
now there, so we can make it work right slowly-slowly :)
With this patch, you can already test carrier management but not yet
make a complete connection.
Relevant extract from logs:
<info> (ueagle-atm0): carrier now ON (device state 20)
<info> (ueagle-atm0): device state change: unavailable -> disconnected (reason 'carrier-changed') [20 30 40]
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
This patch adds the settings code (NMSettingAdsl) and the initial
"scaffolding" i.e., a tiny stub version of NMDeviceAdsl and the
udev handler code to get the device detected.
With this patch you should be able to see an atm device being detected
by networkmanager in the logs, although of course it doesn't
do anything useful yet.
Extract from the logs:
[1304668252.341354] [nm-udev-manager.c:562] adsl_add(): adsl_add: ATM Device detected from udev. Adding ..
(ueagle-atm0): failed to look up interface index
(ueagle-atm0): new ADSL device (driver: 'ueagle-atm' ifindex: -1)
(ueagle-atm0): exported as /org/freedesktop/NetworkManager/Devices/2
(ueagle-atm0): now managed
(ueagle-atm0): device state change: unmanaged -> unavailable (reason 'managed') [10 20 2]
(ueagle-atm0): deactivating device (reason: 2).
[1304668252.345102] [nm-system.c:1349] flush_routes(): (ueagle-atm0) failed to lookup interface index
[1304668252.347821] [nm-device.c:3912] nm_device_state_changed(): (ueagle-atm0): device is available,
In this version, we hack the nm-device.c:nm_device_get_priority() to get better priority
instead of changing the DeviceType enum.
Signed-off-by: Pantelis Koukousoulas <pktoss@gmail.com>
In some situations, objects might get used after being disposed, so
clear out their various priv fields so we don't try to access unreffed
objects, freed strings, etc.
https://bugzilla.gnome.org/show_bug.cgi?id=674473
"InfiniBand" has a capital "B". Fix that everywhere it's being used as
a human-readable string.
In particular, the RH initscripts recognize "TYPE=infiniband" and
"TYPE=InfiniBand", but not "TYPE=Infiniband", which is what we were
writing before.
Many different interface types can support VLANs, including
Infiniband, WiFi, etc. So we have to create a new device class
for them instead of keeping the support in NMDeviceEthernet.
NM already includes <linux/if.h> in some places, f.e. nm-netlink-monitor and
we can't mix usage of the two. Stick to using <linux/if.h> as it provides
additional flag definitions such as operational link state and link mode.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
The core problem was the nm_connection_need_secrets() call in
nm-agent-manager.c's get_start() function; for VPN settings this
always returns TRUE. Thus if a VPN connection had only system
secrets, when the agent manager checked if additional secrets
were required, they would be, and agents would be asked for
secrets they didn't have and couldn't provide. Thus the
connection would fail. nm_connection_need_secrets() simply
can't know if VPN secrets are really required because it
doesn't know anything about the internal VPN private data;
only the plugin itself can tell us if secrets are required.
If the system secrets are sufficient we shouldn't be asking any
agents for secrets at all. So implement a three-step secrets
path for VPN connections. First we retrieve existing system
secrets, and ask the plugin if these are sufficient. Second we
request both existing system secrets and existing agent secrets
and again ask the plugin if these are sufficient. If both those
fail, we ask agents for new secrets.
