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

[Stefan Berger]

  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 at us.ibm.com>
>
> 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