On 03/24/2013 08:25 PM, Mr Dash Four wrote:
>
>>> See my previous post on my thoughts on this.
>>>
>>
>> I've reverted that change for RC 1.
>>
> Thanks! If you send me the appropriate patch(es), I'll test this
> tomorrow as well when I get back.
The patch is at
http://sourceforge.net/p/
On 3/24/13 8:24 PM, "Mr Dash Four" wrote:
>
>> 2) The ${VARDIR}/undo__routing scripts no longer invoke
>> a Shorewall internal function so that they may be processed
>> directly by a shell.
>>
>I've just had an idea about this - can you integrate this into some sort
>of "shorewall "
>> See my previous post on my thoughts on this.
>>
>
> I've reverted that change for RC 1.
>
Thanks! If you send me the appropriate patch(es), I'll test this
tomorrow as well when I get back.
--
Everyone hates s
> 2) The ${VARDIR}/undo__routing scripts no longer invoke
> a Shorewall internal function so that they may be processed
> directly by a shell.
>
I've just had an idea about this - can you integrate this into some sort
of "shorewall " command -
it would be easier to do than mess abou
On 03/24/2013 01:56 PM, Mr Dash Four wrote:
>
>> 1) The 'replace' command is now used rather than 'add' for creating
>> routes defined in /etc/shorewall[6]/routes.
>>
> See my previous post on my thoughts on this.
I've reverted that change for RC 1.
>
>> 3) The compiler now detects mult
> 1) The 'replace' command is now used rather than 'add' for creating
> routes defined in /etc/shorewall[6]/routes.
>
See my previous post on my thoughts on this.
> 3) The compiler now detects multiple entries in
> /etc/shorewall[6]/routes with the same PROVIDER and DEST and raises
>
> I don't see any particular harm in 'replace' now that we have duplicate
> destination detection.
>
It is another line of defence. It ensures that duplicate routes will
*never* me allowed to be created. If shorewall duplicate-route detection
is not perfect and fails (let's face it, no softwa
> Please see my later post which included a patch that implements
> duplicate destination detection.
>
Oops, I've missed that, sorry. It tells me of a warning emitted and the
duplicate route suppressed, but I am not sure what that means - to me
the processing should stop (with an error) if su
Beta 3 is now available for testing.
Changes since Beta 2:
1) The 'replace' command is now used rather than 'add' for creating
routes defined in /etc/shorewall[6]/routes.
2) The ${VARDIR}/undo__routing scripts no longer invoke
a Shorewall internal function so that they may be processed
On 03/24/2013 09:10 AM, Tom Eastep wrote:
> On 03/24/2013 07:59 AM, Tom Eastep wrote:
>> On 03/24/2013 07:48 AM, Tom Eastep wrote:
>>> On 03/23/2013 05:54 PM, Mr Dash Four wrote:
>> Another suggestion: for all table IDs shorewall uses provider numbers.
>> Can you change that to provid
On 03/24/2013 07:59 AM, Tom Eastep wrote:
> On 03/24/2013 07:48 AM, Tom Eastep wrote:
>> On 03/23/2013 05:54 PM, Mr Dash Four wrote:
>>>
> Another suggestion: for all table IDs shorewall uses provider numbers.
> Can you change that to provider names instead?
>
That would
On 03/24/2013 07:48 AM, Tom Eastep wrote:
> On 03/23/2013 05:54 PM, Mr Dash Four wrote:
>>
Another suggestion: for all table IDs shorewall uses provider numbers.
Can you change that to provider names instead?
>>>
>>> That would break if KEEP_RT_TABLES=Yes were set.
>>>
>> Co
On 03/23/2013 05:54 PM, Mr Dash Four wrote:
>
>>> Another suggestion: for all table IDs shorewall uses provider numbers.
>>> Can you change that to provider names instead?
>>>
>>
>> That would break if KEEP_RT_TABLES=Yes were set.
>>
> Could you adopt a more flexible approach then and use
On 03/23/2013 05:54 PM, Mr Dash Four wrote:
>
>> I've updated the MultiISP page -- please have a look.
>>
> Thanks Tom.
>
> "simply discarded (DROPed." misses a right bracket.
>
> "then ALL routes defined or attached"
>
> "ALL" should be changed to [bold]all[/bold] (lowercase and bold) -
>
On 03/23/2013 05:54 PM, Mr Dash Four wrote:
>>> What does ${VARDIR}/firewall do exactly? I am
>>> particularly interested to know whether any of the rules or
>>> traffic-shaping rules are (re-)defined or reset?
>>>
>>
>> It depends; see the tables in http://www.shorewall.net/Shorewall-ini
On 03/23/2013 05:53 PM, Mr Dash Four wrote:
>
>>> routes
>>>
>>> main 10.0.0.0/8 blackhole
>>> main 10.0.0.0/8 prohibit
>>>
>>> generates:
>>>
>>> run_ip route add blackhole 10.0.0.0/8 table 254
>>> run_ip route add prohibit 10.0.0.0/8 table 254
>>>
>>> That is not going to work (ip will comp
16 matches
Mail list logo
