ether_aton() allows addresses like "0:1:2:3:4:5" which was casusing
some problems when reading connections after switching callers of
ether_aton() to nm_utils_hwaddr_aton().
"mac-address-blacklist" property is added to the ethernet and WiFi connections.
It is the MAC addresses list of devices on which the connection won't be
activated.
Original patch (NM_0_8 branch) from Thomas Bechtold <thomasbechtold@jpberlin.de>
It turns out we need a way to ignore transient (agent-owned or unsaved)
secrets during connection comparison. For example, if the user is
connecting to a network where the password is not saved, other
changes could trigger a writeout of that connection to disk when
connecting, which would the connection back in due to inotify, and the
re-read connection would then no longer be recognized as the same as
the in-memory connection due to the transient secret which obviously
wasn't read in from disk.
Adding these compare flags allows the code to not bother writing the
connection out to disk when the only difference between the on-disk
and in-memory connections are secrets that shouldn't get written to
disk anyway.
The ETSI specs state that valid characters are only ASCII alphanumeric
characters, but then state that APNs should generally follow DNS
naming rules. Well, that means a lot more characters are allowed,
but modems don't like many of them. So let's slowly allow more
characters as people find ones that actually are used. The restriction
was originally put in place to disallow spaces, because they
certainly aren't allowed APN characters and modems and the
network puke when they see spaces.
By 'base type' I mean a hardware-related type that can actually be used
to activate the connection, like wifi, wired, gsm, cdma, wimax, bluetooth,
etc, but not ipv4, ipv6, 8021x, etc.
The old function took a string value, which wasn't really correct as
the property type is a GHashTable of string:string. For whatever
reason this is how nm-applet passed VPN secrets back to NM in the return
from the GetSecrets() D-Bus call. This was probably easier or
something but it was a special case that's magic and quite unclear.
Since we use nm_connection_update_secrets() more these days, and we
depend on the GValue types we pass into it matching the property
types of the setting property the secret is for, we need to fix that
up for VPN connections. But keep the old code for backwards
compatibility.
In the future secret agents should pass back VPN secrets in the same
form as the VPN setting specifies them for the "secrets" property:
a GHashTable of string:string. But the old mechanism of just dumping
the key/value pairs into the returned VPN hash as string:string will
still work.
The first-level hash table key should be the setting name itself,
not the GType name of the setting's GObject. There's probably a
better way to do this to reduce that confusion.
Simplifies code internally, and makes it easier for clients as well in
some cases where they want to control what ends up in the resulting
hash and what does not.
APNs can only contain alphanumeric characters, '.', and '-'. To be
helpful we strip spaces off before setting the APN internally so that
previously (and incorrectly) valid APNs don't cause the whole
connection to fail validation and thus disappear. The only case seen
in the wild was a Pelephone IL APN which erroneously had a trailing
space in the mobile broadband provider database. Bad characters
cause the connection to fail with vague error messages about being
unable to activate the PDP context during PPP negotiation.
Ensure it still works correctly if something tries to set the
'addresses' property using the old GType. Also make sure that
the various IP6 address comparison operations and string conversion
functions handle the gateway.
