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.
The example of ifcfg-vlan is as followed:
VLAN=yes
TYPE=Vlan
DEVICE=vlan43 or "DEVICE=eth9.43"
PHYSDEV=eth9
REORDER_HDR=0
VLAN_FLAGS=GVRP,LOOSE_BINDING
VLAN_INGRESS_PRIORITY_MAP=0:1,2:5
VLAN_EGRESS_PRIORITY_MAP=12:3,14:7
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.43.149
NETMASK=255.255.255.0
And we try to make it compitable with the format used by initscripts,
and there is no need to change anything in ifcfg-eth9.
Signed-off-by: Weiping Pan <wpan@redhat.com>
(dcbw: complete VLAN testcase)
Add documentation so the API spec generator can do something
for the VLAN setting. Also enforce validation of the ingress
and egress priority maps; 802.1D priorities are limited to
values from 0 - 7 and Linux SKB values are 32 bits.
Also, the 'slave' property is a duplicate of the 'master'
property added to NMSettingConnection in the bonding work
so we can get rid of it and use 'master' instead.
Due to an omission in the port to the new supplicant D-Bus API
during the 0.9 cycle, if the scan list didn't change, APs may
not have been removed properly from the scan list.
Removes all bonding options properties and adds a "options" dict to hold
them all. Accessible via accessor functions. ifcfg interface is
unchanged.
Signed-off-by: Thomas Graf <tgraf@redhat.com>
Rather than generating enum classes by hand (and complaining in each
file that "this should really be standard"), use glib-mkenums.
Unfortunately, we need a very new version of glib-mkenums in order to
deal with NM's naming conventions and to fix a few other bugs, so just
import that into the source tree temporarily.
Also, to simplify the use of glib-mkenums, import Makefile.glib from
https://bugzilla.gnome.org/654395.
To avoid having to run glib-mkenums for every subdirectory of src/,
add a new "generated" directory, and put the generated enums files
there.
Finally, use Makefile.glib for marshallers too, and generate separate
ones for libnm-glib and NetworkManager.
commit ae34fa900b introduced a new
function nm_netlink_route6_add(). Its declaration in the header
includes a parameter with type 'struct in6_addr', but the proper
system header for that type was not included.
nm_firewall_manager_remove_from_zone() is called from
nm_device_deactivate()
Also fix nm_firewall_manager_add_to_zone() to the latest
FirewallD1.zone.addInterface signature.
Add two helper functions, one for IPv4 and one for IPv6, to ensure
that the core code benefits from compiler type checking when adding
routes. Previously nm_netlink_route_add() took a void* which meant
we messed up adding IPv6 routes sometimes due to confusion over
what was supposed to be passed to it. Also fixes what appears to
be a C&P error with add_ip6_route_to_gateway().
Reported by Tomáš Trnka <tomastrnka@gmx.com>
