- 02 Mar, 2012 3 commits
-
-
Jiri Popelka authored
When we want to change the zone an interface belongs to we can't use firewalld's addInterface() because this one doesn't allow to add interface to zone when it already has been part of some other/same zone. We need to use changeZone() method instead - hopefuly this is the final name of this method.
-
Jiri Popelka authored
Because firewalld has no idea what interface is part of which zone we need to inform it after it (re)starts what interface belongs to which zone.
-
Mathieu Trudel-Lapierre authored
Drop --strict-order; dnsmasq is intelligent enough to ask nameservers in an order that makes the best of possibly slow nameservers (or broken ones), and interrogating them in strict order breaks this. Add --no-hosts: by default dnsmasq will read /etc/hosts as a list of things to resolve statically; this is something we want to avoid as nsswitch.conf already lists files as the first data store to look at; where the entries in /etc/hosts will already have been returned if that's what the user wants to see. If the /etc/hosts file then changes, dnsmasq would have to be restarted before the user would get the new value resolved externally. Avoid this, let /etc/hosts override DNS entries normally through the resolver and show changes as soon as the file is updated.
-
- 01 Mar, 2012 26 commits
-
-
Dan Williams authored
-
Dan Williams authored
Otherwise if another connection was subsequently activated on a bond interface, and didn't specify all options, ones set for the previous connection could stay set for the new connection.
-
Dan Williams authored
Since the options are a hash table now there wasn't any way to determine what options were allowed and what their default values are. Add some functions to do that.
-
Dan Williams authored
We already have the master device kept in the active connection, so we can just use that instead of having the Policy determine and set it manually. This also should allow slaves to auto-activate their master connections if the master is able to activate.
-
Dan Williams authored
Let the master control how the slave gets enslaved and released since that's dependent on the virtual interface type of the master.
-
Dan Williams authored
Virtual devices that we might create when their slave is started (like bonds) have a virtual carrier that often isn't set on when until the device is brought up. The device is brought up during creation, but the initial carrier check happens before the device is up, so the initial carrier state from the constructor isn't quite accurate in some cases. Since we want to use virtual interfaces that we create right after we create them, we want them to be available too, and that usually requires the carrier to be on. So recheck the carrier right after bringing the interface up, so that the carrier state is accurate immediately after the device is created.
-
Dan Williams authored
-
Dan Williams authored
Before jumping to activation stage 1, make sure dependencies are activated.
-
Dan Williams authored
Track a master active connection and emit wait/ready/fail when it changes state. This signal is intended for devices to delay their activation until a master device is ready.
-
Dan Williams authored
If the connection requires a master connection or master device, find that connection, and activate it if it's not already activated.
-
Dan Williams authored
This function used to be used only from activation paths, so it was fine to assert there because we always expected that there would be an activation request. These days we'd like to use it in more places, so just return NULL if there's no connection.
-
Dan Williams authored
Just split the VPN-specific stuff out to its own function so that nm_manager_activate_connection() isn't so large.
-
Dan Williams authored
They are the basic class that tracks active connections, and we're going to use them for connection dependencies. So use the fact that both NMVPNConnection and NMActRequest have the same base class instead of using object paths.
-
Dan Williams authored
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.
-
Dan Williams authored
We'll want to eventually match (for VLAN) a given hardware address that's not the device's hardware address. Only the device itself knows which NMSetting should contain it's hardware address (ie the 'wired' setting for NMDeviceEthernet, 'infiniband' for NMDeviceInfiniband, etc) and VLANs take their hardware address from the parent interface. So eventually we'll have VLAN interfaces use these new arguments to ask their parent interface to match the VLAN hardware address in a connection, since the VLAN doesn't know (or need to know) what kind of interface it really is underneath.
-
Dan Williams authored
It's useful for more than just NMDeviceWired and subclasses.
-
Dan Williams authored
It's the parent, not the master, that we care about here.
-
Dan Williams authored
The 'parent' property of NMSettingVlan is now what describes the interface from which the VLAN gets created, not master.
-
Dan Williams authored
Add some testcases checking for DEVICE/PHYSDEV/VLAN_ID variations, and read/write the new VLAN_ID tag, which we can use in combination with the 'parent' property to determine the interface name if no interface name/DEVICE is given.
-
Dan Williams authored
-
Thomas Graf authored
For bonding-master: TYPE=bond BONDING_MASTER=yes DEVICE=<NAME> BONDING_OPTS="..." For bonding-slaves: MASTER=<NAME> v2: Resolved test failures after feedback from Jirka. Signed-off-by:
Thomas Graf <tgraf@redhat.com>
-
Colin Walters authored
Necessary when building from git srcdir != builddir.
-
Jiri Popelka authored
-
Jiří Klimeš authored
-
Dan Williams authored
-
Dan Williams authored
It's still enabled by default if you don't pass --with-wext=no. But now it's possible to build without WEXT entirely.
-
- 28 Feb, 2012 8 commits
-
-
Dan Williams authored
NM emits coalesced PropertiesChanged signals, which might be delayed slightly and thus sent after the StateChanged signal for devices. Clients of libnm-glib listening for the 'state-changed' signal and then querying the state manually using nm_device_get_state() would still see the old state until it was updated via the delayed PropertiesChanged signal processing. Since when the StateChanged signal comes in the device is already in the new state, just update the state and leave the GObject property notify signal to the PropertiesChanged signal handling code so that clients have an accurate device state.
-
Yuri Chornoivan authored
-
Gabor Kelemen authored
-
Matej Urbančič authored
-
Mohammed Sadiq authored
-
Piotr Drąg authored
-
Henrique P. Machado authored
-
Jiří Klimeš authored
-
- 27 Feb, 2012 3 commits
-
-
Dan Williams authored
-
Dan Williams authored
-
Dan Williams authored
-