Shorewall users - Dec 2007 - result of decodeaddr gives "out of range" on busybox

Bash does not seem to mind:

$ test 1107296256 -eq 2953838592

however busybox''s sh does:

# /bin/sh


BusyBox v1.8.2 (2007-12-11 14:13:35 EST) built-in shell (ash)
Enter ''help'' for a list of built-in commands.

# test 1107296256 -eq 2953838592
sh: 2953838592: out of range

Not sure how much we care.  Just thought I''d point it out.

b.



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Brian J. Murrell wrote:
> Bash does not seem to mind:
> 
> $ test 1107296256 -eq 2953838592
> 
> however busybox''s sh does:
> 
> # /bin/sh
> 
> 
> BusyBox v1.8.2 (2007-12-11 14:13:35 EST) built-in shell (ash)
> Enter ''help'' for a list of built-in commands.
> 
> # test 1107296256 -eq 2953838592
> sh: 2953838592: out of range
> 
> Not sure how much we care.  Just thought I''d point it out.
>
Brian,

I don''t have time for puzzles. What input did you give to Shorewall to
produce whatever problem you are trying to report?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Tom Eastep wrote:
> Brian J. Murrell wrote:
>> Bash does not seem to mind:
>>
>> $ test 1107296256 -eq 2953838592
>>
>> however busybox''s sh does:
>>
>> # /bin/sh
>>
>>
>> BusyBox v1.8.2 (2007-12-11 14:13:35 EST) built-in shell (ash)
>> Enter ''help'' for a list of built-in commands.
>>
>> # test 1107296256 -eq 2953838592
>> sh: 2953838592: out of range
>>
>> Not sure how much we care.  Just thought I''d point it out.
>>
> 
> Brian,
> 
> I don''t have time for puzzles. What input did you give to
Shorewall to
> produce whatever problem you are trying to report?
> 
Furthermore:

BusyBox v1.1.3 (Debian 1:1.1.3-5ubuntu7) Built-in shell (ash)
Enter ''help'' for a list of built-in commands.

~ $ test 1107296256 -eq 2953838592
~ $

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

On Wed, 2007-12-19 at 15:02 -0800, Tom Eastep wrote:
> I don''t have time for puzzles. What input did you give to
Shorewall to
> produce whatever problem you are trying to report?
Sorry.  I should have reproduced more of the subject into the message.
The results which can be too large for busybox''s /bin/sh is from
decodeaddr.  I believe the address input was 172.16.0.0 but I''m sure
any
address nearer the top end of the ipv4 address space would yield the
same result.

b.



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

On Wed, 2007-12-19 at 15:19 -0800, Tom Eastep wrote:
> 
> Furthermore:
> 
> BusyBox v1.1.3 (Debian 1:1.1.3-5ubuntu7) Built-in shell (ash)
> Enter ''help'' for a list of built-in commands.
> 
> ~ $ test 1107296256 -eq 2953838592
> ~ $
Interesting.  It would seem my busybox is newer than yours.  It''s on a
mipsel (i.e. openwrt) platform though.  I wonder if that has anything to
do with it.  Although interesting that bash there does not have the same
problems.

b.



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Brian J. Murrell wrote:
> On Wed, 2007-12-19 at 15:19 -0800, Tom Eastep wrote:
>> Furthermore:
>>
>> BusyBox v1.1.3 (Debian 1:1.1.3-5ubuntu7) Built-in shell (ash)
>> Enter ''help'' for a list of built-in commands.
>>
>> ~ $ test 1107296256 -eq 2953838592
>> ~ $
> 
> Interesting.  It would seem my busybox is newer than yours.  It''s
on a
> mipsel (i.e. openwrt) platform though.  I wonder if that has anything to
> do with it.  Although interesting that bash there does not have the same
> problems.
I also have Busybox 1.6.2 on another system that doesn''t show the
problem.

Again -- what Shorewall input produces the problem?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Brian J. Murrell wrote:
> On Wed, 2007-12-19 at 15:02 -0800, Tom Eastep wrote:
>> I don''t have time for puzzles. What input did you give to
Shorewall to
>> produce whatever problem you are trying to report?
> 
> Sorry.  I should have reproduced more of the subject into the message.
> The results which can be too large for busybox''s /bin/sh is from
> decodeaddr.  I believe the address input was 172.16.0.0 but I''m
sure any
> address nearer the top end of the ipv4 address space would yield the
> same result.
172.16.0.0 decodes to 0x100000. Does BusyBox on that architecture only
support 20-bit arithmatic?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Tom Eastep wrote:
> 172.16.0.0 decodes to 0x100000. Does BusyBox on that architecture only
> support 20-bit arithmatic?
What spelling -- and I hold an advanced degree in Mathematics :-(

arithmetic
arithmetic
arithmetic
...

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Tom Eastep wrote:
> Brian J. Murrell wrote:
>> On Wed, 2007-12-19 at 15:02 -0800, Tom Eastep wrote:
>>> I don''t have time for puzzles. What input did you give to
Shorewall to
>>> produce whatever problem you are trying to report?
>> Sorry.  I should have reproduced more of the subject into the message.
>> The results which can be too large for busybox''s /bin/sh is
from
>> decodeaddr.  I believe the address input was 172.16.0.0 but
I''m sure any
>> address nearer the top end of the ipv4 address space would yield the
>> same result.
> 
> 172.16.0.0 decodes to 0x100000. Does BusyBox on that architecture only
> support 20-bit arithmetic?
>
It''s rather odd, actually -- the shell calculates that number, yet it
chokes
when the same number appears as an argument to ''test''.

What is going on here is that IP addresses in dot-4 notation are converted
to the equivalent 32-bit integer. Some shells only do 32-bit signed
arithmetic which produces anomalies at 128.0.0.0 but I''ve not seen
cases
where numbers of this magnitude caused problems.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

On Wed, Dec 19, 2007 at 03:54:55PM -0800, Tom Eastep
wrote:
> Tom Eastep wrote:
> 
> > 172.16.0.0 decodes to 0x100000. Does BusyBox on that architecture only
> > support 20-bit arithmatic?
> 
> What spelling -- and I hold an advanced degree in Mathematics :-(
And perhaps more significantly, it decodes to 0xac100000.


As for the problem itself:

Shell arithmetic was never guaranteed on large numbers, it''s mostly
intended for loop counters and the like. You''re expected to use dc for
this kind of thing, so I suggest you do that.

Here''s a dc expression for arbitrary-precision bitwise and, if you need
it:

7sa 5sb 1st 0sr [La2~sxsa lb2%Lx*lt*Lr+sr Lb2/sb Lt2*st lalb*0!=l]dslx Lrp

Where 7 and 5 are the operands, and the result is on stdout. I know,
dc''s ugly, but it''s the only thing busybox implements, and
most of the
other stuff is much neater.

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It''s the best place to buy or sell services
for just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace

Andrew Suffield wrote:
> On Wed, Dec 19, 2007 at 03:54:55PM -0800, Tom Eastep wrote:
>> Tom Eastep wrote:
>>
>>> 172.16.0.0 decodes to 0x100000. Does BusyBox on that architecture
only
>>> support 20-bit arithmatic?
>> What spelling -- and I hold an advanced degree in Mathematics :-(
> 
> And perhaps more significantly, it decodes to 0xac100000.
The IP address in Brian''s case was 176.16.0.0, not 172.16.0.0 (my bad).
I had inadvertently ignored the leading "B" when I converted the
decimal
number to Hex using a calculator. 2953838592 == 0xb0100000. This is the same
result as given by bash and by ash (OpenSuSE). dash (Ubuntu) gives
-1341128704 (0xffffffffb0100000).
> 
> 
> As for the problem itself:
> 
> Shell arithmetic was never guaranteed on large numbers, it''s
mostly
> intended for loop counters and the like. You''re expected to use dc
for
> this kind of thing, so I suggest you do that.
> 
> Here''s a dc expression for arbitrary-precision bitwise and, if you
need it:
> 
> 7sa 5sb 1st 0sr [La2~sxsa lb2%Lx*lt*Lr+sr Lb2/sb Lt2*st lalb*0!=l]dslx Lrp
> 
> Where 7 and 5 are the operands, and the result is on stdout. I know,
> dc''s ugly, but it''s the only thing busybox implements,
and most of the
> other stuff is much neater.
Barf. I''m certainly not going to convert to ''dc'' for
the normal Shorewall
distributions.

LEFTSHIFT=''<<''

#
# Convert an IP address in dot quad format to an integer
#
decodeaddr() {
    local x
    local temp=0
    local ifs=$IFS

    IFS=.

    for x in $1; do
	temp=$(( $(( $temp $LEFTSHIFT 8 )) | $x ))
    done

    echo $temp

    IFS=$ifs
}

The curious use of LEFTSHIFT prevents emacs from interpreting
"<<" as "here
documents".

Again, the problem is not that the shell is calculating the wrong value but
rather that when it converts the value to a string, it produces an unsigned
number > 2 ** 31.

The problem is occurring on this call:

in_network 66.11.173.224 176.16.0.0/12

ip_netmask() {
    local vlsm=${1#*/}

    [ $vlsm -eq 0 ] && echo 0 || echo $(( -1 $LEFTSHIFT $(( 32 - $vlsm
)) ))
}

in_network() # $1 = IP address, $2 = CIDR network
{
    local netmask=$(ip_netmask $2)

    test $(( $(decodeaddr $1) & $netmask)) -eq \
         $(( $(decodeaddr ${2%/*}) & $netmask ))
}

The netmask is being calculated as -1048576 (0xfff00000) which is correct.

decodeaddr 66.11.173.224 returns 1108061664 (0x420BADE0) which is correct.

decodeaddr 176.16.0.0 returns 2953838592 (0xb0100000) which is correct but
BusyBox shell chokes on it when it tries to convert it back into an integer
(because it is > 2 ** 31). I suspect that if decodeaddr returned -1341128704
(which is equivalent), then all would be well.

Brian: If you modify /usr/share/shorewall-lite/lib.base using the attached
patch, what does "shorewall-lite ipdecimal 176.16.0.0" print?

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 10:02 -0800, Tom Eastep wrote:
> Brian: If you modify /usr/share/shorewall-lite/lib.base using the attached
> patch, what does "shorewall-lite ipdecimal 176.16.0.0" print?
Same as without the patch:

before_patch:# shorewall-lite ipdecimal 176.16.0.0
   2953838592
after_patch:# shorewall-lite ipdecimal 176.16.0.0
   2953838592



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 10:02 -0800, Tom Eastep wrote:
>> Brian: If you modify /usr/share/shorewall-lite/lib.base using the
attached
>> patch, what does "shorewall-lite ipdecimal 176.16.0.0" print?
> 
> Same as without the patch:
> 
> before_patch:# shorewall-lite ipdecimal 176.16.0.0
>    2953838592
> after_patch:# shorewall-lite ipdecimal 176.16.0.0
>    2953838592
Hmmm.

At a shell prompt, please try this sequence of commands:

foo=2953838592
foo=$((- $foo ))
echo $foo
foo=$((- $foo ))
echo $foo

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 10:34 -0800, Tom Eastep wrote:
> Brian J. Murrell wrote:
> > On Thu, 2007-12-20 at 10:02 -0800, Tom Eastep wrote:
> >> Brian: If you modify /usr/share/shorewall-lite/lib.base using the
attached
> >> patch, what does "shorewall-lite ipdecimal 176.16.0.0"
print?
> > 
> > Same as without the patch:
> > 
> > before_patch:# shorewall-lite ipdecimal 176.16.0.0
> >    2953838592
> > after_patch:# shorewall-lite ipdecimal 176.16.0.0
> >    2953838592
> 
> Hmmm.
> 
> At a shell prompt, please try this sequence of commands:
> 
> foo=2953838592
> foo=$((- $foo ))
> echo $foo
> foo=$((- $foo ))
> echo $foo
# foo=2953838592
# foo=$((- $foo ))
# echo $foo
-2953838592
# foo=$((- $foo ))
# echo $foo
2953838592

Cheers,
b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 10:34 -0800, Tom Eastep wrote:
>> Brian J. Murrell wrote:
>>> On Thu, 2007-12-20 at 10:02 -0800, Tom Eastep wrote:
>>>> Brian: If you modify /usr/share/shorewall-lite/lib.base using
the attached
>>>> patch, what does "shorewall-lite ipdecimal
176.16.0.0" print?
>>> Same as without the patch:
>>>
>>> before_patch:# shorewall-lite ipdecimal 176.16.0.0
>>>    2953838592
>>> after_patch:# shorewall-lite ipdecimal 176.16.0.0
>>>    2953838592
>> Hmmm.
>>
>> At a shell prompt, please try this sequence of commands:
>>
>> foo=2953838592
>> foo=$((- $foo ))
>> echo $foo
>> foo=$((- $foo ))
>> echo $foo
> 
> # foo=2953838592
> # foo=$((- $foo ))
> # echo $foo
> -2953838592
> # foo=$((- $foo ))
> # echo $foo
> 2953838592
> 
Ok -- one more test. What does this do?

[ 16777216 -eq 2953838592 ] || echo foo

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 10:50 -0800, Tom Eastep wrote:
> Ok -- one more test. What does this do?
> 
> [ 16777216 -eq 2953838592 ] || echo foo
# [ 16777216 -eq 2953838592 ] || echo foo
foo

FWIW, BTW, I did file a bug with OpenWRT about this.  Not sure it will
go anywhere though.

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 10:50 -0800, Tom Eastep wrote:
>> Ok -- one more test. What does this do?
>>
>> [ 16777216 -eq 2953838592 ] || echo foo
> 
> # [ 16777216 -eq 2953838592 ] || echo foo
> foo
> 
Ok -- the bug appears to be in BusyBox ''test'' then.

The attached patch should work around the problem.
> FWIW, BTW, I did file a bug with OpenWRT about this.  Not sure it will
> go anywhere though.
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 11:11 -0800, Tom Eastep wrote:
> 
> The attached patch should work around the problem.
 
> -    test $(( $(decodeaddr $1) & $netmask)) -eq $(( $(decodeaddr
${2%/*}) & $netmask ))
> +    [ $(( $(decodeaddr $1) & $netmask)) -eq $(( $(decodeaddr ${2%/*})
& $netmask )) ]
>  }
Hrm.  Given:

BusyBox v1.8.2 (2007-12-11 14:13:35 EST) built-in shell (ash)
Enter ''help'' for a list of built-in commands.

# test $(shorewall-lite ipdecimal 176.16.0.0) -gt 0
sh: 2953838592: out of range
# [ $(shorewall-lite ipdecimal 176.16.0.0) -gt 0 ]   
sh: 2953838592: out of range
# ls -l /usr/bin/[
lrwxrwxrwx    1 wasroot  root           17 Dec 31  1999 /usr/bin/[ ->
../../bin/busybox

Am I missing something?

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 11:11 -0800, Tom Eastep wrote:
>> The attached patch should work around the problem.
>  
>> -    test $(( $(decodeaddr $1) & $netmask)) -eq $(( $(decodeaddr
${2%/*}) & $netmask ))
>> +    [ $(( $(decodeaddr $1) & $netmask)) -eq $(( $(decodeaddr
${2%/*}) & $netmask )) ]
>>  }
> 
> Hrm.  Given:
> 
> BusyBox v1.8.2 (2007-12-11 14:13:35 EST) built-in shell (ash)
> Enter ''help'' for a list of built-in commands.
> 
> # test $(shorewall-lite ipdecimal 176.16.0.0) -gt 0
> sh: 2953838592: out of range
> # [ $(shorewall-lite ipdecimal 176.16.0.0) -gt 0 ]   
> sh: 2953838592: out of range
> # ls -l /usr/bin/[
> lrwxrwxrwx    1 wasroot  root           17 Dec 31  1999 /usr/bin/[ ->
../../bin/busybox
> 
> Am I missing something?
> 
I must be missing something -- you specifically tested that number in a "[
-eq ]". So what does this do?

foo=2953838592

[ $foo -eq 0 ]

If that gives you the ''out of range'' error, then try this:

eval [ $foo -eq 0 ]

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 11:35 -0800, Tom Eastep wrote: 
> 
> I must be missing something -- you specifically tested that number in a
"[
> -eq ]". So what does this do?
Aw crap.  No you are not missing something I am.  I did all of my
previous tests in a bash.  I forgot to specifically change my
interactive shell to the busybox /bin/sh.  My apologies.

Here''s your last two tests in the busybox /bin/sh:

# foo=2953838592
# foo=$((- $foo ))
# echo $foo
-2953838592
# foo=$((- $foo ))
# echo $foo
2953838592
# 
# [ 16777216 -eq 2953838592 ] || echo foo
sh: 2953838592: out of range
foo
> foo=2953838592
> 
> [ $foo -eq 0 ]
> 
> If that gives you the ''out of range'' error, then try
this:
> 
> eval [ $foo -eq 0 ]
# foo=2953838592
# [ $foo -eq 0 ]
sh: 2953838592: out of range
# eval [ $foo -eq 0 ]
sh: 2953838592: out of range

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 11:35 -0800, Tom Eastep wrote: 
>> I must be missing something -- you specifically tested that number in a
"[
>> -eq ]". So what does this do?
> 
> Aw crap.  No you are not missing something I am.  I did all of my
> previous tests in a bash.  I forgot to specifically change my
> interactive shell to the busybox /bin/sh.  My apologies.
> 
> Here''s your last two tests in the busybox /bin/sh:
> 
> # foo=2953838592
> # foo=$((- $foo ))
> # echo $foo
> -2953838592
> # foo=$((- $foo ))
> # echo $foo
> 2953838592
> # 
> # [ 16777216 -eq 2953838592 ] || echo foo
> sh: 2953838592: out of range
> foo
> 
>> foo=2953838592
>>
>> [ $foo -eq 0 ]
>>
>> If that gives you the ''out of range'' error, then try
this:
>>
>> eval [ $foo -eq 0 ]
> 
> # foo=2953838592
> # [ $foo -eq 0 ]
> sh: 2953838592: out of range
> # eval [ $foo -eq 0 ]
> sh: 2953838592: out of range
Then I have no clue how work around the bug.

Sorry,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 11:44 -0800, Tom Eastep wrote:
> Then I have no clue how work around the bug.
Could the concept of doing:

a=decodeaddr A
b=decodeaddr B

test a -gt b

be abstracted into a function in the following manner:

compare_addrs A B

and then let compare_addrs() handle the ugliness?

For the case at hand, could you then not decode an address into two
integers representing the MSBs and LSBs and compare them individually?

It''s not pretty, no.

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 11:35 -0800, Tom Eastep wrote: 
>> I must be missing something -- you specifically tested that number in a
"[
>> -eq ]". So what does this do?
> 
> Aw crap.  No you are not missing something I am.  I did all of my
> previous tests in a bash.  I forgot to specifically change my
> interactive shell to the busybox /bin/sh.  My apologies.
> 
> Here''s your last two tests in the busybox /bin/sh:
> 
> # foo=2953838592
> # foo=$((- $foo ))
> # echo $foo
> -2953838592
> # foo=$((- $foo ))
> # echo $foo
> 2953838592
> # 
> # [ 16777216 -eq 2953838592 ] || echo foo
> sh: 2953838592: out of range
> foo
> 
>> foo=2953838592
>>
>> [ $foo -eq 0 ]
>>
>> If that gives you the ''out of range'' error, then try
this:
>>
>> eval [ $foo -eq 0 ]
> 
> # foo=2953838592
> # [ $foo -eq 0 ]
> sh: 2953838592: out of range
> # eval [ $foo -eq 0 ]
> sh: 2953838592: out of range
What does "[ $foo = 0 ]" do?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 12:22 -0800, Tom Eastep wrote:
> 
> What does "[ $foo = 0 ]" do?
# [ $foo = 0 ]

and just to evidence that we are still in busybox''s /bin/sh and that
$foo has our testing value in it:

# echo $foo
2953838592
# eval [ $foo -eq 0 ]
sh: 2953838592: out of range

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 12:22 -0800, Tom Eastep wrote:
>> What does "[ $foo = 0 ]" do?
> 
> # [ $foo = 0 ]
> 
> and just to evidence that we are still in busybox''s /bin/sh and
that
> $foo has our testing value in it:
> 
> # echo $foo
> 2953838592
> # eval [ $foo -eq 0 ]
> sh: 2953838592: out of range
> 
Ok -- you can probably make the obvious change to in_network(), replacing
the ''-eq'' with ''=''.

That will take care of the immediate problem but, as you point out, there
are other cases in the code where addresses are compared numerically for
other than equality. Unfortunately, the arguments to the test are usually
calculated using the value returned by decodeaddr().

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 12:31 -0800, Tom Eastep wrote: 
> 
> Ok -- you can probably make the obvious change to in_network(), replacing
> the ''-eq'' with ''=''.
Ahhh.  The subtle difference between -gt and =.  :-)
> That will take care of the immediate problem but, as you point out, there
> are other cases in the code where addresses are compared numerically for
> other than equality. Unfortunately, the arguments to the test are usually
> calculated using the value returned by decodeaddr().
Right.  I guess I was proposing "test/[" comparisons be replaced by
(a)
function(s) that hid the ugly details of this mess.

i.e. though shall not compare address with test/[ but shall used the
defined functions for doing address comparisons.

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 12:31 -0800, Tom Eastep wrote: 
>> Ok -- you can probably make the obvious change to in_network(),
replacing
>> the ''-eq'' with ''=''.
> 
> Ahhh.  The subtle difference between -gt and =.  :-)
> 
>> That will take care of the immediate problem but, as you point out,
there
>> are other cases in the code where addresses are compared numerically
for
>> other than equality. Unfortunately, the arguments to the test are
usually
>> calculated using the value returned by decodeaddr().
> 
> Right.  I guess I was proposing "test/[" comparisons be replaced
by (a)
> function(s) that hid the ugly details of this mess.
> 
> i.e. though shall not compare address with test/[ but shall used the
> defined functions for doing address comparisons.
Yes -- but that function can blow up the first time that it tries to touch
its arguments in a numeric context. So it would have to break them into two
smaller integers without using arithmetic and without the benefit of
${foo:a:b} (these toy shells don''t support that form of expansion).

That will be ugly and slow.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 12:58 -0800, Tom Eastep wrote:
> 
> Yes -- but that function can blow up the first time that it tries to touch
> its arguments in a numeric context. So it would have to break them into two
> smaller integers without using arithmetic and without the benefit of
> ${foo:a:b} (these toy shells don''t support that form of
expansion).
How about:

# foo=1.2.3.4
# echo ${foo#*.*.}
3.4
# echo ${foo%.*.*}  
1.2
> That will be ugly and slow.
Not the above.  Or am I missing something?

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 12:58 -0800, Tom Eastep wrote:
>> Yes -- but that function can blow up the first time that it tries to
touch
>> its arguments in a numeric context. So it would have to break them into
two
>> smaller integers without using arithmetic and without the benefit of
>> ${foo:a:b} (these toy shells don''t support that form of
expansion).
> 
> How about:
> 
> # foo=1.2.3.4
> # echo ${foo#*.*.}
> 3.4
> # echo ${foo%.*.*}  
> 1.2
> 
>> That will be ugly and slow.
> 
> Not the above.  Or am I missing something?
> 
Please have a look at ip_range() and ip_range_explicit() in lib.base and try
to envision recoding them to use that technique. Maybe you want to spend
your Christmas vacation that way -- I don''t. Especially when I
can''t test
anything without exchanging emails with you.

Yet another question: what does "/bin/sh /sbin/shorewall-lite ipdecimal
2953838592" do?

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 13:12 -0800, Tom Eastep wrote:
> 
> Please have a look at ip_range() and ip_range_explicit() in lib.base and
try
> to envision recoding them to use that technique.
I will admit to not having looked all of the use cases.
> Maybe you want to spend
> your Christmas vacation that way -- I don''t.
:-)
> Yet another question: what does "/bin/sh /sbin/shorewall-lite
ipdecimal
> 2953838592" do?
# /bin/sh /sbin/shorewall-lite ipdecimal 2953838592
   176.16.0.0

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, Dec 20, 2007 at 12:58:43PM -0800, Tom Eastep
wrote:
> Yes -- but that function can blow up the first time that it tries to touch
> its arguments in a numeric context. So it would have to break them into two
> smaller integers without using arithmetic and without the benefit of
> ${foo:a:b} (these toy shells don''t support that form of
expansion).
> 
> That will be ugly and slow.
(Or you could use dc, which would be ugly and fast, and probably less work)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Andrew Suffield wrote:
> On Thu, Dec 20, 2007 at 12:58:43PM -0800, Tom Eastep wrote:
>> Yes -- but that function can blow up the first time that it tries to
touch
>> its arguments in a numeric context. So it would have to break them into
two
>> smaller integers without using arithmetic and without the benefit of
>> ${foo:a:b} (these toy shells don''t support that form of
expansion).
>>
>> That will be ugly and slow.
> 
> (Or you could use dc, which would be ugly and fast, and probably less work)
My initial tests with BusyBox dc have not given me a warm and fuzzy feeling:

teastep@wookie:~/shorewall/trunk/Shorewall-common$ ~/dc
2953838592
p
2.95384e+09

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, Dec 20, 2007 at 01:32:43PM -0800, Tom Eastep
wrote:
> Andrew Suffield wrote:
> > On Thu, Dec 20, 2007 at 12:58:43PM -0800, Tom Eastep wrote:
> >> Yes -- but that function can blow up the first time that it tries
to touch
> >> its arguments in a numeric context. So it would have to break them
into two
> >> smaller integers without using arithmetic and without the benefit
of
> >> ${foo:a:b} (these toy shells don''t support that form of
expansion).
> >>
> >> That will be ugly and slow.
> > 
> > (Or you could use dc, which would be ugly and fast, and probably less
work)
> 
> My initial tests with BusyBox dc have not given me a warm and fuzzy
feeling:
> 
> teastep@wookie:~/shorewall/trunk/Shorewall-common$ ~/dc
> 2953838592
> p
> 2.95384e+09
Hrngh. You''re right, busybox dc is not a correct implementation of
posix dc. I think that means you''re screwed. To hell with it, and
depend on bc for arithmetic?

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Andrew Suffield wrote:
> 
> Hrngh. You''re right, busybox dc is not a correct implementation of
> posix dc. I think that means you''re screwed. To hell with it, and
> depend on bc for arithmetic?
Hence, the proposed function to compare two addresses:

addr_comp() {
    test $(bc <<EOF
$1 > $2
EOF
) -eq 1

}

That will sure make your parents proud. To compare two numbers, you only
have to fork(), pipe(), exec(), ...

Brian: If you copy/paste the above into your BusyBox shell, do you get these
results?

$ addr_comp 2953838592 1107296256 && echo Yes || echo No
Yes
$ addr_comp 1107296256 2953838592 && echo Yes || echo No
No
$

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, Dec 20, 2007 at 03:03:24PM -0800, Tom Eastep
wrote:
> Hence, the proposed function to compare two addresses:
> 
> addr_comp() {
>     test $(bc <<EOF
> $1 > $2
> EOF
> ) -eq 1
> 
> }
> 
> That will sure make your parents proud. To compare two numbers, you only
> have to fork(), pipe(), exec(), ...
I have on several occasions thought that the Bourne shell has been
designed to make arithmetic support horrible in an attempt to disuade
people from writing complex applications in shell.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Thu, 2007-12-20 at 13:12 -0800, Tom Eastep wrote:
>> Please have a look at ip_range() and ip_range_explicit() in lib.base
and try
>> to envision recoding them to use that technique.
> 
> I will admit to not having looked all of the use cases.
> 
>> Maybe you want to spend
>> your Christmas vacation that way -- I don''t.
> 
> :-)
> 
>> Yet another question: what does "/bin/sh /sbin/shorewall-lite
ipdecimal
>> 2953838592" do?
> 
> # /bin/sh /sbin/shorewall-lite ipdecimal 2953838592
>    176.16.0.0
>
Brian,


Attached is a patch to lib.base that attempts to replace the failing tests
with calls to a bc-based function. Please try the "shorewall-lite
iprange"
command with this patch installed.

Thanks,
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Tom Eastep wrote:
> Brian J. Murrell wrote:
>> On Thu, 2007-12-20 at 13:12 -0800, Tom Eastep wrote:
>>> Please have a look at ip_range() and ip_range_explicit() in
lib.base and try
>>> to envision recoding them to use that technique.
>> I will admit to not having looked all of the use cases.
>>
>>> Maybe you want to spend
>>> your Christmas vacation that way -- I don''t.
>> :-)
>>
>>> Yet another question: what does "/bin/sh /sbin/shorewall-lite
ipdecimal
>>> 2953838592" do?
>> # /bin/sh /sbin/shorewall-lite ipdecimal 2953838592
>>    176.16.0.0
>>
> 
> Brian,
> 
> 
> Attached is a patch to lib.base that attempts to replace the failing tests
> with calls to a bc-based function. Please try the "shorewall-lite
iprange"
> command with this patch installed.
Corrected patch attached (first one broke ip_range_explicit().

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Tom Eastep wrote:
> Tom Eastep wrote:
>> Brian J. Murrell wrote:
>>> On Thu, 2007-12-20 at 13:12 -0800, Tom Eastep wrote:
>>>> Please have a look at ip_range() and ip_range_explicit() in
lib.base and try
>>>> to envision recoding them to use that technique.
>>> I will admit to not having looked all of the use cases.
>>>
>>>> Maybe you want to spend
>>>> your Christmas vacation that way -- I don''t.
>>> :-)
>>>
>>>> Yet another question: what does "/bin/sh
/sbin/shorewall-lite ipdecimal
>>>> 2953838592" do?
>>> # /bin/sh /sbin/shorewall-lite ipdecimal 2953838592
>>>    176.16.0.0
>>>
>> Brian,
>>
>>
>> Attached is a patch to lib.base that attempts to replace the failing
tests
>> with calls to a bc-based function. Please try the "shorewall-lite
iprange"
>> command with this patch installed.
> 
> Corrected patch attached (first one broke ip_range_explicit().
> 
-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 15:03 -0800, Tom Eastep wrote:
> Hence, the proposed function to compare two addresses:
> 
> addr_comp() {
>     test $(bc <<EOF
> $1 > $2
> EOF
> ) -eq 1
> 
> }
> 
> That will sure make your parents proud. To compare two numbers, you only
> have to fork(), pipe(), exec(), ...
> 
> Brian: If you copy/paste the above into your BusyBox shell, do you get
these
> results?
> 
> $ addr_comp 2953838592 1107296256 && echo Yes || echo No
> Yes
> $ addr_comp 1107296256 2953838592 && echo Yes || echo No
> No
> $
Sorry about the delay.  Seasonal obligations.  :-)

Yes, I can confirm the above works on my openwrt platform once I
installed bc.

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Thu, 2007-12-20 at 16:13 -0800, Tom Eastep wrote:
> > Corrected patch attached (first one broke ip_range_explicit().
On initial inspection, this patch seems to work.  I no longer get the
complaints from /bin/sh in any case.

I wonder though, if you want to put in a one-time (i.e. capability) test
for the busybox brokenness and only fallback on using bc if the test
fails and just use the shell''s integer comparison otherwise.

Anyway, I will patch the shorewall-lite 4 package I am building for
openwrt with the patch.

Thanx!

b.

P.S.  I hope you (all -- for those that celebrate it) had a Merry
Christmas and I with you all a Happy New Year.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> 
> I wonder though, if you want to put in a one-time (i.e. capability) test
> for the busybox brokenness and only fallback on using bc if the test
> fails and just use the shell''s integer comparison otherwise.
These hacks aren''t in the stable version and I have no intention of
including them there. I have them in the current development thread just
so I can test them easily in a non-broken environment.
> 
> Anyway, I will patch the shorewall-lite 4 package I am building for
> openwrt with the patch.
I think that is the proper place to include the hacks since it appears
that OpenWRT is the only environment that needs them.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Brian J. Murrell wrote:
> On Sun, 2007-12-30 at 10:44 -0800, Tom Eastep wrote:
>> I think that is the proper place to include the hacks since it appears
>> that OpenWRT is the only environment that needs them.
> 
> That''s fair enough.
I will go ahead and change in_network() in Shorewall-perl though since
that fix doesn''t impose any performance penalty.

-Tom
-- 
Tom Eastep    \ Nothing is foolproof to a sufficiently talented fool
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net
PGP Public Key   \ https://lists.shorewall.net/teastep.pgp.key



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Sun, 2007-12-30 at 10:44 -0800, Tom Eastep wrote:
> 
> I think that is the proper place to include the hacks since it appears
> that OpenWRT is the only environment that needs them.
That''s fair enough.

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

On Sun, 2007-12-30 at 10:50 -0800, Tom Eastep wrote:
> 
> I will go ahead and change in_network() in Shorewall-perl though since
> that fix doesn''t impose any performance penalty.
Heh.  You beat me to it.  I was just writing to you about that.  :-)

Great!

b.



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/