Re: [PATCH] [RESEND] [TCK] nwfilter: Adapt to changes how filters are instantiated

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

 



 On 10/21/2010 12:52 PM, Daniel P. Berrange wrote:
On Thu, Oct 21, 2010 at 12:17:40PM -0400, Stefan Berger wrote:
I am resending the patch with 'evolution' and hope no patch-mangling
occurs. At least it looks ok before sending (also sending patch as an
attachment)
Yes it has formatted correctly. Soooooo much easier to read now :-)

Recent changes to how filters are being instantiated require follow-up
changes to the test suite. The following changes are related to

- usage of 'ctdir'
- changes to the host's incoming filter chain

Signed-off-by: Stefan Berger<stefanb@xxxxxxxxxx>

ACK if you can confirm the following are correct:

  #iptables -L HI-vnet0 -n
  Chain HI-vnet0 (1 references)
  target     prot opt source               destination
-ACCEPT     udplite--  0.0.0.0/0            10.1.2.3            MAC 01:02:03:04:05:06 DSCP match 0x02
-ACCEPT     udplite--  0.0.0.0/0            10.1.0.0/22         DSCP match 0x21
-ACCEPT     udplite--  0.0.0.0/0            10.1.0.0/22         DSCP match 0x21
+RETURN     udplite--  0.0.0.0/0            10.1.2.3            MAC 01:02:03:04:05:06 DSCP match 0x02state NEW,ESTABLISHED ctdir REPLY
+RETURN     udplite--  0.0.0.0/0            10.1.0.0/22         DSCP match 0x21state ESTABLISHED ctdir ORIGINAL
+RETURN     udplite--  0.0.0.0/0            10.1.0.0/22         DSCP match 0x21state ESTABLISHED ctdir ORIGINAL

  Chain HI-vnet0 (1 references)
  target     prot opt source               destination
-ACCEPT     udp  --  0.0.0.0/0            10.1.2.3            MAC 01:02:03:04:05:06 DSCP match 0x22udp spts:291:400 dpts:564:1092
+RETURN     udp  --  0.0.0.0/0            10.1.2.3            MAC 01:02:03:04:05:06 DSCP match 0x22udp spts:291:400 dpts:564:1092 state NEW,ESTABLISHED ctdir REPLY
  #iptables -L libvirt-host-in -n | grep HI-vnet0 | tr -s " "
  HI-vnet0 all -- 0.0.0.0/0 0.0.0.0/0 [goto] PHYSDEV match --physdev-in vnet0
  #iptables -L libvirt-in -n | grep FI-vnet0 | tr -s " "

  #ip6tables -L HI-vnet0 -n
  Chain HI-vnet0 (1 references)
  target     prot opt source               destination
-ACCEPT     tcp      ::/0                 a:b:c::/128         tcp spts:256:4369 dpts:32:33
+RETURN     tcp      ::/0                 a:b:c::/128         tcp spts:256:4369 dpts:32:33 state ESTABLISHED ctdir ORIGINAL
  #ip6tables -L libvirt-host-in -n | grep vnet0 | tr -s " "
  HI-vnet0 all ::/0 ::/0 [goto] PHYSDEV match --physdev-in vnet0
  #ip6tables -L libvirt-in -n | grep vnet0 | tr -s " "
Odd to see these ACCEPTs turning into RETURN ? Was that intentional ?

Yes, this was intentional. Rather than having the host accept the packets with the previous "ACCEPT", now the evaluation of the traffic returns to the INPUT chain where it is determined whether the host actually allows that packet. This is lIke the VM is allowed to send ICMP traffic, but the host doesn't want it -> first a 'RETURN' on the outgoing ICMP traffic, then a drop in the host's filter confiuration.

   Stefan

Regards,
Daniel

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]