[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH 11/13] Update iptables.c to also support ip6tables.



On 01/04/2011 10:48 AM, Daniel P. Berrange wrote:

@@ -735,6 +765,7 @@ iptablesForwardMasquerade(iptablesContext *ctx,
      if (protocol&&  protocol[0]) {
          if (physdev&&  physdev[0]) {
              ret = iptablesAddRemoveRule(ctx->nat_postrouting,
+                                        VIR_SOCKET_FAMILY(netaddr),
                                          action,
                                          "--source", networkstr,
                                          "-p", protocol,
@@ -745,6 +776,7 @@ iptablesForwardMasquerade(iptablesContext *ctx,
                                          NULL);
          } else {
              ret = iptablesAddRemoveRule(ctx->nat_postrouting,
+                                        VIR_SOCKET_FAMILY(netaddr),
                                          action,
                                          "--source", networkstr,
                                          "-p", protocol,
@@ -756,6 +788,7 @@ iptablesForwardMasquerade(iptablesContext *ctx,
      } else {
          if (physdev&&  physdev[0]) {
              ret = iptablesAddRemoveRule(ctx->nat_postrouting,
+                                        VIR_SOCKET_FAMILY(netaddr),
                                          action,
                                          "--source", networkstr,
                                          "!", "--destination", networkstr,
@@ -764,6 +797,7 @@ iptablesForwardMasquerade(iptablesContext *ctx,
                                          NULL);
          } else {
              ret = iptablesAddRemoveRule(ctx->nat_postrouting,
+                                        VIR_SOCKET_FAMILY(netaddr),
                                          action,
                                          "--source", networkstr,
                                          "!", "--destination", networkstr,
Masquerading doesn't exist in IPv6 world, so technically we should be
raising an error for AF_INET6 in these 4 cases as a sanity check.

Good point. I was just absent-mindedly following the form of the other changes, relying on the fact that we never call it that way. :-)

I'll make an appropriate patch that gives an error if someone tries to call it with an IPv6 address (I guess it should be an internal error, since the higher level code is currently already assuring that we don't do that).


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]