* use libsoup to compare a http response from a given
uri with a given response (use g_str_has_prefix () to compare)
* do periodically check the connectivity. Check interval is configurable
* check connectivity when device state change
from/to NM_DEVICE_STATE_ACTIVATED
- changes nm_utils_get_proc_sys_net_value() to allow all values, not just 0,1
- adds nm_utils_get_proc_sys_net_value_with_bounds() for limiting valid values
This message was printed:
GLib-GObject-CRITICAL **: g_value_get_string: assertion `G_VALUE_HOLDS_STRING (value)' failed
It showed out it came from g_cclosure_marshal_VOID__STRING() in BSSRemoved signal.
The signal parameter is object path, so use g_cclosure_marshal_VOID__BOXED instead.
Always removing wep_tx_keyidx will cause wpa_supplicant.conf being
written even if nothing has been changed. Now it will be removed only
when wep is not used anymore.
We need to do the same thing as wpa_supplicant's own config file parser
and ignore '#' characters that occur between the first and last '"'
characters in a config file line.
https://bugzilla.gnome.org/show_bug.cgi?id=670381
Check "VLAN=yes" if "TYPE=Vlan" is missing.
They have the same meaning.
This patch is based on NM/vlan branch,
commit 703196fcdb96ad0d4bf8dac572235e65ba02e844
Signed-off-by: Weiping Pan <wpan@redhat.com>
If we want to support vlan without libnl3,
then we can use ioctl.
Changelog:
V2: fix identation and comments.
Signed-off-by: Weiping Pan <wpan@redhat.com>
There's no way to specify the MAC address bond interfaces have
since they take the MAC address of their slaves, so NMDeviceBond
doesn't implement hwaddr_matches(). This check would always
return FALSE, and thus we'd never match.
The standard D-Bus PropertiesChanged signals are only in 1.0 and
later, so we also have to listen to the deprecated signals for
older supplicant versions. We can revert this commit when we
drop support for wpa_supplicant 0.7.x.
The port to the new supplicant D-Bus API for NM 0.9 had one unfinished
piece, which was to remove old APs from the scan list when the
supplicant returned no scan results or there was a scan error. In
this case, the removal code would not be called. This wasn't much
of a problem until 836f7d177e which
began removing APs from the scan list correctly in this case.
This uncovered a bug in NM's wpa_supplicant management code, which
was that NM only updates its internal AP object 'last seen' timestamp
when the AP is reported by the supplicant as a completely new BSS
(in merge_scanned_ap()). But the new supplicant D-Bus interface
only reports the BSS as "new" when the supplicant doesn't know about
the BSS, either because it is a new BSS or because it's been removed
from the supplicant's scan list at some point in the past.
Thus for BSSes that are consistently kept in the supplicant's scan
list, because the wifi driver is actually doing its job and reporting
them consistently in scan results, NM would not be updating the
'last seen' value for the corresponding NM AP objects. Due to
836f7d177e this would cause APs that
should be kept to be removed from the NM scan list.
To fix this, have the NMAccessPoint object track which supplicant
dbus object it came from, and have NMSupplicantInterface listen for
PropertyChanged signals for those APs the supplicant knows about.
When something changes (like signal strength as the result of updated
scan results) update the AP's 'last seen' timestamp since it clearly
still exists in the scan list. This way we update the timestamp both
when the supplicant finds a new AP and when it updates the properties
of existing APs.
Fix handle_object_array_property() to deal with receiving an empty
list correctly (rather than warning and leaving the property with its
previous value still set).
Also, add two more untracked properties that shouldn't be warned about
(NMDevice:device-type and NMActiveConnection:vpn, both of which are
only used at construct time).
Different modem implementations in ModemManager are now able to specify specific
maximum durations of the IP configuration setup. This is useful when specific
modems need durations greater than the default 20s (for example, for Satellite
network based modems, where delays are pretty high).
To suppress periodic disk wakeups, only write timestamps to disk
when a device gets activated or deactivated. Timestamps are
still updated periodically in memory, just not flushed to disk
at that time.
The check for virtual interface name was too loose, so
restrict it to VLAN only which is what actually uses it,
and ensure we have an interface name to compare against
the device.
Found by Weiping Pan <wpan@redhat.com>
Make sure we don't already have an NMDevice for this interface
before creating it, and also when creating the interface, make
a new NMDevice for it immediately to prevent a race between
telling the kernel to create the interface via netlink, and when
udev later tells us about it. In between there we could be
triggered to try creating the interface again.
add write_vlan_setting() and modify test-ifcfg-rh.c to test it.
Signed-off-by: Weiping Pan <wpan@redhat.com>
(updates by dcbw for changes made to original patch series)
First make it build on libnl1/2. Second, the VLAN
virtual interface name might not always be given in the
NMConnection (if the master is a UUID and thus the name
is determined automatically) so just take the interface
name instead. And make sure we verify it's a VLAN
interface before deleting it.
Lastly, construct the VLAN interface name if it's not
given in the NMConnection. This means we need to know
the master interface name when creating the connection,
which we always will since you can't create the VLAN
interface without it's master being present. That also
means we need to return the name to the caller so it
can be used to create the NMDevice for the VLAN interface
after we've created it in the kernel.
We make use of libnl (>=3.2.1) to create/delete kernel vlan device,
and it can set vlan id, vlan flags and ingress/egress priority mapping.
V3:
1 nm_netlink_iface_to_index() should use slave name
V2:
1 use existing nm_netlink_iface_to_index()
Signed-off-by: Weiping Pan <wpan@redhat.com>
It's a boolean value not a string. Second, apparently the
kernel turns it on by default these days, so if it's missing
then assume it's supposed to be TRUE.
