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 >> found
Steven,
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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
