Re: Notice on upcoming ipdbtools 1.1.1

[Dr. Rolf Jansen]

> Am 14.08.2016 um 12:15 schrieb Dr. Rolf Jansen :
> 
> As was noticed by the port maintainer, the initial release of ipdbtools 1.1.0 
> into the ports did not compile on i386 systems because the lack of the 
> __uint128_t data type on 32bit systems, and which was used for IPv6 computing.
> 
> In the meantime, I rolled in the necessary uint128 comparison, shift and 
> basic arithmetic operations that provide the missing built-in __uint128_t 
> operations on 32bit systems. The 64bit targets x86-64 and arm64 continue to 
> utilize the built-in operations.
> 
> The changes are ready on GitHub, and I will submit a changed port PR on 
> Monday (tomorrow) night, most of the post-mortem fixes since the initial 
> release are included -- I won't rename the tool 'ipup', though.

I just submitted the PR for updating the port of ipdbtools to v1.1.1.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211881

Best regards

Rolf
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"

Re: Named states in ipfw (and old rulesets)

[Lev Serebryakov]

On 15.08.2016 9:11, Ian Smith wrote:

> One thing I wondered about earlier but didn't ask is that the order of 
> options is generally not relevant, so for example the commonly used:
> 
>   ipfw add skipto $somewhere tcp from $a to $b setup keep-state
> 
> would currently be equally valid as:
> 
>   ipfw add skipto $somewhere tcp from $a to $b keep-state setup
> 
> with possibly other options following?
  Both work now on -CURRENT as expected , but second one will show you
two-line warning, that state name was changed to "default".

> I think existing rulesets working out of the box is vital too; the last 
> thing needed on managed remote boxes is firewall breakage on upgrading.
  Existing rulesets are not broken, but could give you non-intuitive
warnings now :)

-- 
// Lev Serebryakov AKA Black Lion



signature.asc
Description: OpenPGP digital signature

Re: Named states in ipfw (and old rulesets)

[Ian Smith]

On Mon, 15 Aug 2016 02:20:19 +0300, Lev Serebryakov wrote:

 > >  Please, change this to some prefix to state name (:name, @name or 
 > > something
 > > like this) or to "state-action(name)" format. It will be much better: less
 > > error-prone and will work without ugly warnings on old rulesets.

I like the idea of something like :name, @name or perhaps =name ? as a 
distinct state name identifier.  (name) seems like overkill, especially 
since it requires escaping on the command line as \(name\), and while of 
course such escaping is required now to identify table names, we don't 
need anything that might tend to confuse table names with state names.

 >  Or, maybe, state names should be pre-declared (except "default"), as
 >  table's ones does. Like
 > 
 >  ipfw flow create my-name
 >  ipfw add allow ip from an to any keep-state my-name

I really hope that's not necessary; the assumption of 'default' name for 
existing rulesets is good, and requiring pre-declaration of state names 
- except default - would be less .. orthogonal :) and not necessary.

One thing I wondered about earlier but didn't ask is that the order of 
options is generally not relevant, so for example the commonly used:

  ipfw add skipto $somewhere tcp from $a to $b setup keep-state

would currently be equally valid as:

  ipfw add skipto $somewhere tcp from $a to $b keep-state setup

with possibly other options following?

And while 'setup' should be recognised as an existing keyword, not a 
state name - as will '//' when that's fixed I guess? - still I wondered 
whether the keyword 'setup' would get "pushed back" for later parsing?

 >  This will be somewhat bullet-proof!

I think existing rulesets working out of the box is vital too; the last 
thing needed on managed remote boxes is firewall breakage on upgrading.

cheers, Ian
___
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"