- 27 6月, 2016 1 次提交
-
-
由 Laine Stump 提交于
I'm tired of mistyping this all the time, so let's do it the same all the time (similar to how we changed all "Pci" to "PCI" awhile back). (NB: I've left alone some things in the esx and vbox drivers because I'm unable to compile them and they weren't obviously *not* a part of some API. I also didn't change a couple of variables named, e.g. "somethingIptables", because they were derived from the name of the "iptables" command)
-
- 14 7月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
The comment above that function says: "This function can be a lot more exhaustive, ...", so let's be. Check for collisions between routes in the system and static routes being added explicitly from the <route/> element of the network XML. Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1094205Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 23 3月, 2015 1 次提交
-
-
由 Martin Kletzander 提交于
Wikipedia's list of common misspellings [1] has a machine-readable version. This patch fixes those misspellings mentioned in the list which don't have multiple right variants (as e.g. "accension", which can be both "accession" and "ascension"), such misspellings are left untouched. The list of changes was manually re-checked for false positives. [1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machinesSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 15 11月, 2014 1 次提交
-
-
由 Martin Kletzander 提交于
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
-
- 25 4月, 2014 2 次提交
-
-
由 Daniel P. Berrange 提交于
The networkCheckRouteCollision, networkAddFirewallRules and networkRemoveFirewallRules APIs all take a virNetworkObjPtr instance, but only ever access the 'def' member. It thus simplifies testing if the APIs are changed to just take a virNetworkDefPtr instead Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
由 Daniel P. Berrange 提交于
Update the iptablesXXXX methods so that instead of directly executing iptables commands, they populate rules in an instance of virFirewallPtr. The bridge driver can thus construct the ruleset and then invoke it in one operation having rollback handled automatically. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 25 3月, 2014 1 次提交
-
-
由 Ján Tomko 提交于
-
- 18 3月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
Any source file which calls the logging APIs now needs to have a VIR_LOG_INIT("source.name") declaration at the start of the file. This provides a static variable of the virLogSource type. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 11 3月, 2014 1 次提交
-
-
由 Daniel P. Berrange 提交于
The bridge_driver_platform.h defines many functions that a platform driver must implement. Only two of these functions are actually called from the main bridge driver code. The remainder can be made internal to the linux driver only. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 08 1月, 2014 1 次提交
-
-
由 Lénaïc Huard 提交于
When the host is configured with very restrictive firewall (default policy is DROP for all chains, including OUTPUT), the bridge driver for Linux adds netfilter entries to allow DHCP and DNS requests to go from the VM to the dnsmasq of the host. The issue that this commit fixes is the fact that a DROP policy on the OUTPUT chain blocks the DHCP replies from the host’s dnsmasq to the VM. As DHCP replies are sent in UDP, they are not caught by any --ctstate ESTABLISHED rule and so, need to be explicitly allowed. Signed-off-by: NLénaïc Huard <lenaic@lhuard.fr.eu.org>
-
- 25 9月, 2013 1 次提交
-
-
由 Laszlo Ersek 提交于
Packets sent by guests on virbrN, *or* by dnsmasq on the same, to - 255.255.255.255/32 (netmask-independent local network broadcast address), or to - 224.0.0.0/24 (local subnetwork multicast range) are never forwarded, hence it is not necessary to masquerade them. In fact we must not masquerade them: translating their source addresses or source ports (where applicable) may confuse receivers on virbrN. One example is the DHCP client in OVMF (= UEFI firmware for virtual machines): http://thread.gmane.org/gmane.comp.bios.tianocore.devel/1506/focus=2640 It expects DHCP replies to arrive from remote source port 67. Even though dnsmasq conforms to that, the destination address (255.255.255.255) and the source address (eg. 192.168.122.1) in the reply allow the UDP masquerading rule to match, which rewrites the source port to or above 1024. This prevents the DHCP client in OVMF from accepting the packet. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=709418Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
-
- 02 8月, 2013 1 次提交
-
-
由 Roman Bogorodskiy 提交于
* Move platform specific things (e.g. firewalling and route collision checks) into bridge_driver_platform * Create two platform specific implementations: - bridge_driver_linux: Linux implementation using iptables, it's actually the code moved from bridge_driver.c - bridge_driver_nop: dumb implementation that does nothing Signed-off-by: NEric Blake <eblake@redhat.com>
-