speedway does now accept inet6 token

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Generate a policy using token inet6:
header {
  target:: speedway INPUT DROP inet6
}
term deny-all-in {
  comment:: "Clean up rule for INPUT chain"
  logging:: syslog
  action:: deny
}

2. Generate policy using aclgen.py

What is the expected output? What do you see instead?
Expect to render a filter with IPv6 addresses to be used by ip6tables-restore.
 The above example is extremely simple so no special IPv6 filter is expected - just a policy to drop all IPv6 traffic. Instead get the following error:

Traceback (most recent call last):
  File "./aclgen.py", line 172, in <module>
    main()
  File "./aclgen.py", line 152, in main
    count = load_and_render(FLAGS.policy_directory, defs)
  File "./aclgen.py", line 69, in load_and_render
    defs))
  File "./aclgen.py", line 125, in render_filters
    fw = speedway.Speedway(spd)
  File "/home/jorge/Downloads/capirca/lib/aclgenerator.py", line 237, in __init__
    self._TranslatePolicy(pol)
  File "/home/jorge/Downloads/capirca/lib/iptables.py", line 618, in _TranslatePolicy
    filter_options))
lib.iptables.UnsupportedFilterError: 
May only specify one of ['inet', 'inet6'] in filter options: ['DROP', 'inet6']


What version of the product are you using? On what operating system?
Using capirca-r168. Tested on Ubuntu 11.10 and CentOS 6.2.

Please provide any additional information below.
n/a

Original issue reported on code.google.com by jo...@morgado.ch on 19 Mar 2012 at 7:43

[GoogleCodeExporter]

I'm unable to reproduce this issue using capirca-r168, as specified in the 
report.  Can you please verify if this occurs on a fresh install of r168?

----

$ cat > policies/test.pol 
header {
 target:: speedway INPUT DROP inet6
}
term deny-all-in {
  comment:: "Clean up rule for INPUT chain"
  logging:: syslog
  action:: deny
}
^d

$ ./aclgen.py 
writing ./filters/test.ipt
1 filters rendered
watson@watson:~/capirca$ more filters/test.ipt 
*filter
# Speedway INPUT Policy
# $Id:$
# $Date:$
# inet6
:INPUT DROP
-N I_deny-all-in
-A I_deny-all-in -m comment --comment "Clean up rule for INPUT chain"
-A I_deny-all-in -p all -j LOG --log-prefix deny-all-in 
-A I_deny-all-in -p all -j DROP
-A INPUT -j I_deny-all-in

COMMIT

Original comment by watson on 19 Mar 2012 at 7:39

[GoogleCodeExporter]

Sorry, my initial report is incomplete. It works if you just specify one header 
(e.g. an INPUT or OUTPUT target). But with more than one header it actually 
fails on r168. The error happens also for IPv4 only if you specify the inet 
token. Here's an example that fail:

$ cat policies/test.pol 
header {
 target:: speedway INPUT DROP inet6
}
term deny-all-in {
  comment:: "Clean up rule for INPUT chain"
  logging:: syslog
  action:: deny
}

header {
 target:: speedway OUTPUT DROP inet6
}
term deny-all-out {
  comment:: "Clean up rule for OUTPUT chain"
  logging:: syslog
  action:: deny
}
^D


In the example above, replace the inet6 token with inet and the issue still 
happens. Then remove the inet token and it works.

BTW, the issue's subject has a typo. Should read "speedway does not accept 
inet6 token". In any case the issue happens both with iptables and speedway 
when inet or inet6 tokens are specified.

Original comment by jo...@morgado.ch on 19 Mar 2012 at 9:02

[GoogleCodeExporter]

Original comment by watson on 6 Jun 2012 at 10:05

• Changed state: Accepted

[GoogleCodeExporter]

This issue should be resolved in r187.
The problem was filter_type was not being reset to None before processing each 
filter
in a given policy.

Original comment by watson@google.com on 16 Jul 2012 at 3:10

• Changed state: Fixed