Beta 2 is now available for testing.
Problems corrected in this release:
1) Under rare circumstances where COMMENT is used to attach comments
to rules, OPTIMIZE 8 through 15 could result in invalid
iptables-restore (ip6tables-restore) input.
2) Under rare circumstances involving exclusion, OPTIMIZE 8 through 15
could result in invalid iptables-restore (ip6tables-restore) input.
3) The change in 4.4.12 to detect and use the new ipset match syntax
broke the ability to detect the old ipset match capability. Now,
both versions of the capability can be correctly detected.
4) Previously, if REQUIRE_INTERFACE=Yes then start/restart would fail
if the last optional interface tested was not available.
5) Exclusion in the blacklist file was correctly validated but was then
ignored when generating iptables (ip6tables) rules.
6) Previously, non-trivial exclusion (more than one excluded
address/net) in CONTINUE, NONAT and ACCEPT+ rules generated
valid but incorrect iptables input. This has been corrected but
requires that your iptables/kernel support marking rules in any
Netfilter table.
This fix implements a new ''Mark in any table'' capability;
those
who utilize a capabilities file should re-generate the file using
this release.
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
Sell apps to millions through the Intel(R) Atom(Tm) Developer Program
Be part of this innovative community and reach millions of netbook users
worldwide. Take advantage of special opportunities to increase revenue and
speed time-to-market. Join now, and jumpstart your future.
http://p.sf.net/sfu/intel-atom-d2d
Tom Have you had a look at the following issue from Beta1?>With rule entry:>ACCEPT dmz:eth1,lan all> If the interface entry is changed to: > > dmz eth+ > > then Shorewall accepts it. > > If the interface entry is changed to: > > dmz eth+ - optional > > then the following message is produced: > > /var/lib/shorewall/.restart: line 1562: SW_ETH1,FW_IS_USABLE=: command not > foundSteven ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
On 8/28/10 8:26 AM, Steven Jan Springl wrote:> Tom > > Have you had a look at the following issue from Beta1? > >> With rule entry: > >> ACCEPT dmz:eth1,lan all > >> If the interface entry is changed to: >> >> dmz eth+ >> >> then Shorewall accepts it. >> >> If the interface entry is changed to: >> >> dmz eth+ - optional >> >> then the following message is produced: >> >> /var/lib/shorewall/.restart: line 1562: SW_ETH1,FW_IS_USABLE=: command not >> foundSteven, This issue is not unique to Beta 1; it occurs in any recent version of Shorewall (I suspect that the problem is present in any 4.4 release and probably in earlier ones as well; I have only verified it back to 4.4.11). Note that it can occur with a simple entry in the interfaces file: net ppp,foo - optional Note also that ppp,foo *is a valid interface name*: gateway:~# ip link ls 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 ... 11: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/[65534] 15: f--.9$^: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 4e:36:15:9d:96:3a brd ff:ff:ff:ff:ff:ff 16: foo,bar: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether d6:91:da:b9:95:15 brd ff:ff:ff:ff:ff:ff gateway:~# I have yet to decide what I want to do about it. Shorewall currently uses this function to create shell variable names from interface names: ------------------ # # Transform the passed interface name into a legal shell variable name. # sub chain_base($) { my $chain = $_[0]; $chain =~ s/^@/at_/; $chain =~ tr/[.\-%@]/_/; $chain =~ s/\+$//; $chain; } -------------------- This approach is already flawed since it can easily result in name collisions. I could always manufacture names but that makes the generated code hard to read. I could use the name as is (e.g., ''eth0'' becomes SW_ETH0_IS_USABLE) unless the name is not a valid shell identifier in which case I would manufacture a name (e.g. ''eth0.4'' because SW__n_IS_USABLE, where ''n'' is a serially-assigned integer). Both of these approaches risk breaking existing configurations that use one of these variable names in their ''start'' or ''started'' scripts (although I broke those configs back in 4.4.8 as well when I added the SW_ prefix). The second approach breaks fewer configs than the first does. I''m reluctant to try to verify physical interface names since the rules for these names are not documented (that I can find) and are likely to be subject to change anyway. Anyone have an opinion? -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/28/10 10:05 AM, Tom Eastep wrote:> > I''m reluctant to try to verify physical interface names since the rules > for these names are not documented (that I can find) and are likely to > be subject to change anyway.The kernel doesn''t seem to be very picky: 19: &foo: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 72:4d:34:b2:a0:ff brd ff:ff:ff:ff:ff:ff 20: &foo!: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 5e:3e:7c:90:b1:31 brd ff:ff:ff:ff:ff:ff 21: &foo!(): <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 1e:ae:1e:1f:97:36 brd ff:ff:ff:ff:ff:ff 22: &foo![]: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether 72:b9:3a:27:b4:6c brd ff:ff:ff:ff:ff:ff 23: &fo+o![]: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN link/ether d2:91:08:b7:26:cd brd ff:ff:ff:ff:ff:ff The only character that I''ve found so far that it doesn''t like is ''%''. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d
On 8/28/10 10:05 AM, Tom Eastep wrote:> > I have yet to decide what I want to do about it. > > Shorewall currently uses this function to create shell variable names > from interface names: > ------------------ > # > # Transform the passed interface name into a legal shell variable name. > # > sub chain_base($) { > my $chain = $_[0]; > > $chain =~ s/^@/at_/; > $chain =~ tr/[.\-%@]/_/; > $chain =~ s/\+$//; > $chain; > } > -------------------- > > This approach is already flawed since it can easily result in name > collisions. > > I could always manufacture names but that makes the generated code hard > to read. > > I could use the name as is (e.g., ''eth0'' becomes SW_ETH0_IS_USABLE) > unless the name is not a valid shell identifier in which case I would > manufacture a name (e.g. ''eth0.4'' because SW__n_IS_USABLE, where ''n'' is > a serially-assigned integer). > > Both of these approaches risk breaking existing configurations that use > one of these variable names in their ''start'' or ''started'' scripts > (although I broke those configs back in 4.4.8 as well when I added the > SW_ prefix). The second approach breaks fewer configs than the first does. >I''ve decided to follow the second approach as follows: - Replace periods with underscores - Strip trailing ''+'' If the resulting name is valid for a shell-variable then use it. Otherwise: - Strip out all characters that are not valid in a shell variable name. - If the result begins with a digit, preface the name with ''if_''. - Add a suffix consisting of ''_'' followed by a unique sequence number. The above algorithm results in no change for VLAN and wildcard names. It will be in Beta 3. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d