[ANNOUNCE] ipset 6.13 released

[ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

Hi,

I have just released ipset 6.13 with a few bugfixes and some new features.

Userspace changes:
 - Explain in more detail src/dst for hash:net,iface
 - ipset help lists set types multiple times, fixed 
   (reported by Mr Dash Four)
 - The commandline parser was too permissive, make it more strict
 - Allow saving to/restoring from a file without shell redirection
 - Fix typo of word "unkown" to "unknown" (Neutron Soutmun)

Kernel part changes:
 - ipset: Handle properly an IPSET_CMD_NONE (Tomasz Bursztyka)
 - netfilter: ipset: hash:net,iface: fix interface comparison (Florian
   Westphal)
 - Timeout fixing bug broke SET target special timeout value, fixed
 - Use MSEC_PER_SEC instead of harcoded value

You can download the source code of ipset from:
        http://ipset.netfilter.org
        ftp://ftp.netfilter.org/pub/ipset/
        git://git.netfilter.org/ipset.git

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Jan Engelhardt]

The following changes since commit 7c7b022a18ea2bae11d889b345caef87f3bf145e:

  ipset 6.13 released (2012-06-29 21:48:45 +0200)

are available in the git repository at:
  git://git.inai.de/ipset master

Jan Engelhardt (1):
      build: restore -version-info

 Make_global.am  |    2 +-
 lib/Makefile.am |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

[PATCH] build: restore -version-info

[Jan Engelhardt]

There was no noticable reason to switch to -version-number;
version-number would have also seen the use of 3:0:0, not 3:0:1.

3:0:1 only makes sense with -version-info, so put "-version-info"
back. However, since ipset-6.13 already released libipset.so.3, going
back to .so.2 might not be such a good idea, so continue using .so.3
by means of 3:0:0.

Also note that the version names in libipset.map generally are not
supposed to follow SO versions, but the program version):
IPSET_6.13 {...}.
---
 Make_global.am  |    2 +-
 lib/Makefile.am |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Make_global.am b/Make_global.am
index 4a8f61a..446c4de 100644
--- a/Make_global.am
+++ b/Make_global.am
@@ -69,7 +69,7 @@
 # interface. 
 
 #            curr:rev:age
-LIBVERSION = 3:0:1
+LIBVERSION = 3:0:0
 
 AM_CPPFLAGS = $(kinclude_CFLAGS) $(all_includes) -I$(top_srcdir)/include \
 	-I/usr/local/include
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 392b5f9..fd853dd 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -19,7 +19,7 @@ lib_LTLIBRARIES = libipset.la
 
 include $(top_srcdir)/lib/Make_extra.am
 
-libipset_la_LDFLAGS = -Wl,--version-script=$(top_srcdir)/lib/libipset.map -version-number $(LIBVERSION)
+libipset_la_LDFLAGS = -Wl,--version-script=$(top_srcdir)/lib/libipset.map -version-info $(LIBVERSION)
 libipset_la_LIBADD  = ${libmnl_LIBS} $(IPSET_SETTYPE_STATIC_OBJECTS)
 libipset_la_SOURCES = \
 	data.c \
-- 
1.7.7

Re: [PATCH] build: restore -version-info

[Jozsef Kadlecsik]

Hi Jan,

On Sat, 30 Jun 2012, Jan Engelhardt wrote:

> There was no noticable reason to switch to -version-number;
> version-number would have also seen the use of 3:0:0, not 3:0:1.
> 
> 3:0:1 only makes sense with -version-info, so put "-version-info"
> back. However, since ipset-6.13 already released libipset.so.3, going
> back to .so.2 might not be such a good idea, so continue using .so.3
> by means of 3:0:0.
> 
> Also note that the version names in libipset.map generally are not
> supposed to follow SO versions, but the program version):
> IPSET_6.13 {...}.
> ---
>  Make_global.am  |    2 +-
>  lib/Makefile.am |    2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Make_global.am b/Make_global.am
> index 4a8f61a..446c4de 100644
> --- a/Make_global.am
> +++ b/Make_global.am
> @@ -69,7 +69,7 @@
>  # interface. 
>  
>  #            curr:rev:age
> -LIBVERSION = 3:0:1
> +LIBVERSION = 3:0:0

The new library release is backward compatible with the previous one, so 
age must be incremented. That's why I set LIBVERSION to 3:0:1 from 2:1:0. 
Or do I miss something from the library interface version description 
cited in Make_global.am?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH] build: restore -version-info

[Jan Engelhardt]

On Sunday 2012-07-01 00:05, Jozsef Kadlecsik wrote:
>> 
>> diff --git a/Make_global.am b/Make_global.am
>> index 4a8f61a..446c4de 100644
>> --- a/Make_global.am
>> +++ b/Make_global.am
>> @@ -69,7 +69,7 @@
>>  # interface. 
>>  
>>  #            curr:rev:age
>> -LIBVERSION = 3:0:1
>> +LIBVERSION = 3:0:0
>
>The new library release is backward compatible with the previous one, so 
>age must be incremented. That's why I set LIBVERSION to 3:0:1 from 2:1:0. 

Correct -- if you had stayed with "-version-info", which you did not.

Re: [PATCH] build: restore -version-info

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Jan Engelhardt wrote:

> On Sunday 2012-07-01 00:05, Jozsef Kadlecsik wrote:
> >> 
> >> diff --git a/Make_global.am b/Make_global.am
> >> index 4a8f61a..446c4de 100644
> >> --- a/Make_global.am
> >> +++ b/Make_global.am
> >> @@ -69,7 +69,7 @@
> >>  # interface. 
> >>  
> >>  #            curr:rev:age
> >> -LIBVERSION = 3:0:1
> >> +LIBVERSION = 3:0:0
> >
> >The new library release is backward compatible with the previous one, so 
> >age must be incremented. That's why I set LIBVERSION to 3:0:1 from 2:1:0. 
> 
> Correct -- if you had stayed with "-version-info", which you did not.

So if it's reverted back (second part of your patch), the the first part 
is to be skipped.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH] build: restore -version-info

[Jan Engelhardt]

On Sunday 2012-07-01 00:31, Jozsef Kadlecsik wrote:

>On Sun, 1 Jul 2012, Jan Engelhardt wrote:
>
>> On Sunday 2012-07-01 00:05, Jozsef Kadlecsik wrote:
>> >> 
>> >> diff --git a/Make_global.am b/Make_global.am
>> >> index 4a8f61a..446c4de 100644
>> >> --- a/Make_global.am
>> >> +++ b/Make_global.am
>> >> @@ -69,7 +69,7 @@
>> >>  # interface. 
>> >>  
>> >>  #            curr:rev:age
>> >> -LIBVERSION = 3:0:1
>> >> +LIBVERSION = 3:0:0
>> >
>> >The new library release is backward compatible with the previous one, so 
>> >age must be incremented. That's why I set LIBVERSION to 3:0:1 from 2:1:0. 
>> 
>> Correct -- if you had stayed with "-version-info", which you did not.
>
>So if it's reverted back (second part of your patch), the the first part 
>is to be skipped.

Since you already have made a release (ipset-6.13) emitting an .so.3
file, I don't think you should go back to .so.2. Hence I am using 3:0:0.

Re: [ANNOUNCE] ipset 6.13 released

[Mr Dash Four]

> I have just released ipset 6.13 with a few bugfixes and some new features.
>
> Userspace changes:
>  - Explain in more detail src/dst for hash:net,iface
>   
Assuming this is what you've had in mind (taken from "man ipset"):

The second direction parameter of the set match and
SET target modules corresponds to the incoming/outgoing interface:
src to the incoming one (similar to the -i flag of iptables), while
dst to the outgoing one (similar to the -o flag of iptables). When
the interface is flagged with physdev:, the interface is interpreted
as the incoming/outgoing bridge port.

I think that is plain wrong!

You refer to the incoming interface (interface on which packets arrive) 
as the "source". That cannot be right. To me, it should be a 
"destination", not  "source" as the very definition of a "destination" 
is where something ends, this is where a packet arrives and where the 
journey of the packet "stops" (or where the packet is "destined" to 
arrive anyway). It should definitely not be a "source" as the packet 
does not originate there, nor does it start its journey there.

Similarly for the outgoing interface - this isn't a "destination" 
interface as the packet doesn't arrive there - it is where it starts its 
journey from!

So, I think you should reverse both definitions and match "src" with the 
outgoing interface and "dst" with the incoming interface - exactly the 
opposite of what you have now. Documenting something which was done 
wrong in the first place doesn't make it right.

Re: [ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Mr Dash Four wrote:

> > I have just released ipset 6.13 with a few bugfixes and some new features.
> > 
> > Userspace changes:
> >  - Explain in more detail src/dst for hash:net,iface
> >   
> Assuming this is what you've had in mind (taken from "man ipset"):
> 
> The second direction parameter of the set match and
> SET target modules corresponds to the incoming/outgoing interface:
> src to the incoming one (similar to the -i flag of iptables), while
> dst to the outgoing one (similar to the -o flag of iptables). When
> the interface is flagged with physdev:, the interface is interpreted
> as the incoming/outgoing bridge port.
> 
> I think that is plain wrong!
> 
> You refer to the incoming interface (interface on which packets arrive) as the
> "source". That cannot be right. To me, it should be a "destination", not
> "source" as the very definition of a "destination" is where something ends,
> this is where a packet arrives and where the journey of the packet "stops" (or
> where the packet is "destined" to arrive anyway). It should definitely not be
> a "source" as the packet does not originate there, nor does it start its
> journey there.
> 
> Similarly for the outgoing interface - this isn't a "destination" interface as
> the packet doesn't arrive there - it is where it starts its journey from!
> 
> So, I think you should reverse both definitions and match "src" with the
> outgoing interface and "dst" with the incoming interface - exactly the
> opposite of what you have now. Documenting something which was done wrong in
> the first place doesn't make it right.

The hash:net,iface type is out for a long time. It is not possible to 
change the meaning of src/dst without breaking backward compatibility, 
therefore I won't do it. As a "workaround" I tried to explain the meaning 
of src/dst for iface as clearly as possible.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH] build: restore -version-info

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Jan Engelhardt wrote:

> On Sunday 2012-07-01 00:31, Jozsef Kadlecsik wrote:
> 
> >On Sun, 1 Jul 2012, Jan Engelhardt wrote:
> >
> >> On Sunday 2012-07-01 00:05, Jozsef Kadlecsik wrote:
> >> >> 
> >> >> diff --git a/Make_global.am b/Make_global.am
> >> >> index 4a8f61a..446c4de 100644
> >> >> --- a/Make_global.am
> >> >> +++ b/Make_global.am
> >> >> @@ -69,7 +69,7 @@
> >> >>  # interface. 
> >> >>  
> >> >>  #            curr:rev:age
> >> >> -LIBVERSION = 3:0:1
> >> >> +LIBVERSION = 3:0:0
> >> >
> >> >The new library release is backward compatible with the previous one, so 
> >> >age must be incremented. That's why I set LIBVERSION to 3:0:1 from 2:1:0. 
> >> 
> >> Correct -- if you had stayed with "-version-info", which you did not.
> >
> >So if it's reverted back (second part of your patch), the the first part 
> >is to be skipped.
> 
> Since you already have made a release (ipset-6.13) emitting an .so.3
> file, I don't think you should go back to .so.2. Hence I am using 3:0:0.

What I meant is to keep LIBVERSION = 3:0:1, because that's right from 
backward compatibility view, and restore back -version-info.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Mr Dash Four]

> The hash:net,iface type is out for a long time. It is not possible to 
> change the meaning of src/dst without breaking backward compatibility, 
> therefore I won't do it.
It has nothing to do with "backward compatibility" at all, but 
everything to do with something which was done wrong initially and needs 
to be fixed. The fact that this "has been out for a long time" is not an 
excuse - if anything, it reflects pretty badly that this wasn't spotted 
earlier. Besides, when a bug is discovered do you write a man page 
documenting it or do you fix that particular bug?

>  As a "workaround" I tried to explain the meaning 
> of src/dst for iface as clearly as possible.
>   
As I stated before - documenting a bug doesn't make it right. The proper 
course of action is to fix that particular bug, not document it in a 
bloody man page!

Re: [ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Mr Dash Four wrote:

> 
> > The hash:net,iface type is out for a long time. It is not possible to change
> > the meaning of src/dst without breaking backward compatibility, therefore I
> > won't do it.
> It has nothing to do with "backward compatibility" at all, but everything to
> do with something which was done wrong initially and needs to be fixed. The
> fact that this "has been out for a long time" is not an excuse - if anything,
> it reflects pretty badly that this wasn't spotted earlier. Besides, when a bug
> is discovered do you write a man page documenting it or do you fix that
> particular bug?

Call it a bug, whatever. I won't change the meaning of src/dst for 
hash:net,iface which then will break someone's working firewall after an 
upgrade.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Mr Dash Four]

> Call it a bug, whatever. I won't change the meaning of src/dst for 
> hash:net,iface which then will break someone's working firewall after an 
> upgrade.
>   
In other words, you are not only intent on keeping this bug in the 
netfilter/kernel code, but willing to document it in a man page simply 
because of the remote possibility that someone somewhere may have been 
using hash:net,iface and decided to upgrade while not willing to change 
its configuration to put right something which was wrong in the first place?

Re: [ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Mr Dash Four wrote:

> > Call it a bug, whatever. I won't change the meaning of src/dst for
> > hash:net,iface which then will break someone's working firewall after an
> > upgrade.
> >   
> In other words, you are not only intent on keeping this bug in the
> netfilter/kernel code, but willing to document it in a man page simply because
> of the remote possibility that someone somewhere may have been using
> hash:net,iface and decided to upgrade while not willing to change its
> configuration to put right something which was wrong in the first place?

Yes. You argue the meaning of a keyword. The meaning is well documented in 
the manpage, but it's totally counter-intuitive for you. Changing the 
meaning might break working firewalls. Therefore the meaning won't be 
changed.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Mr Dash Four]

> Yes. You argue the meaning of a keyword. The meaning is well documented in 
> the manpage, but it's totally counter-intuitive for you. Changing the 
> meaning might break working firewalls. Therefore the meaning won't be 
> changed.
>   
This isn't simply a question of "meaning" - it is an issue caused by the 
fact that you have introduced something which, it seems, wasn't properly 
checked initially for whatever reason and that is causing a great deal 
of inconsistency and inconvenience for people, like myself, who use 
ipset on a daily basis.

When I match an incoming packet destined to an IP address for example, I 
have to use, quite rightly, a "dst" designation, but when I match 
against the interface to which this same IP address belongs to, 
according to your man page, I have to use "src" instead - all this, 
simply because you didn't check this properly when hash:net,iface was 
first released and you can't be bothered, for one reason or another, to 
change it simply because "this has been out for a long time"?

Do you think that all the network admins out there will have to remember 
to use "dst" when matching on destination IP addresses, port numbers 
etc, but use exactly the opposite designation - "src" - when matching on 
the same destination interface that same IP address belongs to? Do you 
not see how inconvenient and downright misleading this is? If you can't, 
you are beyond hope, I am afraid.

Right, I am going to include Patrick in this as this whole saga is 
becoming something of a monologue and I need a bit of clarity on this.

Re: [ANNOUNCE] ipset 6.13 released

[Andreas Herz]

On 29/06/12 at 22:04, Jozsef Kadlecsik wrote:
> I have just released ipset 6.13 with a few bugfixes and some new features.

Great, perfect timing, because i will go back to the testing and coding
stuff for my ipset setup :)

>  - Timeout fixing bug broke SET target special timeout value, fixed
>  - Use MSEC_PER_SEC instead of harcoded value

Does this also fix the jiffies issue with the kernel?
But i will see it in my testcases nevertheless.

-- 
Andreas Herz

Re: [ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Andreas Herz wrote:

> On 29/06/12 at 22:04, Jozsef Kadlecsik wrote:
> > I have just released ipset 6.13 with a few bugfixes and some new features.
> 
> Great, perfect timing, because i will go back to the testing and coding
> stuff for my ipset setup :)
> 
> >  - Timeout fixing bug broke SET target special timeout value, fixed
> >  - Use MSEC_PER_SEC instead of harcoded value
> 
> Does this also fix the jiffies issue with the kernel?

That was fixed in the previous version. 

> But i will see it in my testcases nevertheless.

I'm looking forward your testing results!

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Mr Dash Four wrote:

> > the manpage, but it's totally counter-intuitive for you. Changing the
> > meaning might break working firewalls. Therefore the meaning won't be
> > changed.
> >   
> This isn't simply a question of "meaning" - it is an issue caused by the 
> fact that you have introduced something which, it seems, wasn't properly 
> checked initially for whatever reason and that is causing a great deal 
> of inconsistency and inconvenience for people, like myself, who use 
> ipset on a daily basis.

I have to weight the "great deal of inconsistency and inconvenience" 
caused to you against breaking firewall setups out there. I really 
appreciate your comments, but in this case you should adapt.
 
> When I match an incoming packet destined to an IP address for example, I 
> have to use, quite rightly, a "dst" designation, but when I match 
> against the interface to which this same IP address belongs to, 
> according to your man page, I have to use "src" instead - all this, 
> simply because you didn't check this properly when hash:net,iface was 
> first released and you can't be bothered, for one reason or another, to 
> change it simply because "this has been out for a long time"?
> 
> Do you think that all the network admins out there will have to remember 
> to use "dst" when matching on destination IP addresses, port numbers 
> etc, but use exactly the opposite designation - "src" - when matching on 
> the same destination interface that same IP address belongs to? Do you 
> not see how inconvenient and downright misleading this is? If you can't, 
> you are beyond hope, I am afraid.

Do you think all admins constantly read all changelogs, mailing lists 
about all the software they use to catch backward incompatible changes? 
You are aware of the "inconveniece", and you could adapt yourself to it 
anytime. I'm responsible for every user, for those who never read these 
mailing lists as well.
 
> Right, I am going to include Patrick in this as this whole saga is becoming
> something of a monologue and I need a bit of clarity on this.

Feel free to involve anyone. Just to sum up: in the case of the 
net:hash,iface type of ipset, the manpage says

"The second direction parameter of the set match and SET target modules 
corresponds to the incoming/outgoing interface: src to the incoming one 
(similar to the -i flag of iptables), while dst to the outgoing one 
(similar to the -o flag of iptables)."

You argue that the meaning of src/dst for the interface part is 
counter-intuitieve and therefore must be reversed - regardless of the 
backward compatibility issue and the possible breaking of existing setups.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [PATCH] build: restore -version-info

[Jan Engelhardt]

On Sunday 2012-07-01 14:11, Jozsef Kadlecsik wrote:
>> >> 
>> >> Correct -- if you had stayed with "-version-info", which you did not.
>> >
>> >So if it's reverted back (second part of your patch), the the first part 
>> >is to be skipped.
>> 
>> Since you already have made a release (ipset-6.13) emitting an .so.3
>> file, I don't think you should go back to .so.2. Hence I am using 3:0:0.
>
>What I meant is to keep LIBVERSION = 3:0:1, because that's right from 
>backward compatibility view, and restore back -version-info.

What part was unclear?

* 6.13 uses -version-number 3:0:1
* that causes production of .so.3
* it's set in stone
* next incompatible change requires use of .so.4

* going back to .so.2 not a good idea
* humans are prone to errors and
  would reuse .so.3 in error

* therefore the patch makes a clean restart,
  using -version-info 3:0:0, to continue using .so.3
  starting from ipset-6.13 until the next *real*
  incompatible change.

(If you care about the uninteresting third digit,
-version-info 3:1:0 would be wanted.)

Re: [ANNOUNCE] ipset 6.13 released

[Mr Dash Four]

> I have to weight the "great deal of inconsistency and inconvenience" 
> caused to you against breaking firewall setups out there. I really 
> appreciate your comments, but in this case you should adapt.
>   
You are in no position to tell me what I should be doing. As for the 
"breaking firewall setups" bit - see my previous comments.

Also, there is a flip-side to that particular coin - by keeping buggy 
netfilter/kernel code, I'd argue that this is more likely to "break 
firewall setups" as you put it - by keeping this, wrongful, setup and 
the whole notion that for incoming IP addresses, subnets, ports and 
everything else one should use "dst" designation, but for incoming 
interfaces I should use "src" instead. I mean, really, get a grip of 
yourself!

> Do you think all admins constantly read all changelogs, mailing lists 
> about all the software they use to catch backward incompatible changes? 
>   
They do, if they're worth their salt.

> You are aware of the "inconveniece", and you could adapt yourself to it 
> anytime.
Why should I, as a network admin, have to adapt to this buggy code just 
because you just can't see what's in front of your face?

>  I'm responsible for every user, for those who never read these 
> mailing lists as well.
>   
So, is ignorance an excuse nowadays? I never expected to read that from 
a Netfilter developer, but there is a first time for everything I suppose.

> Feel free to involve anyone.
It is the only way I see forward as, evidently, "debating" this with you 
is completely and utterly pointless - you are like a broken record, 
repeating the same over and over and over again like an automaton.

> You argue that the meaning of src/dst for the interface part is 
> counter-intuitieve and therefore must be reversed - regardless of the 
> backward compatibility issue and the possible breaking of existing setups.
>   
Where did I state, or even hinted that it is "counter-intuitive"? That's 
right, I didn't. Because it is not "counter-intuitive", it is, at best, 
wrong and inconsistent, at worse - buggy and downright misleading! Can 
you read, Jozsef?

Re: [PATCH] build: restore -version-info

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Jan Engelhardt wrote:

> 
> On Sunday 2012-07-01 14:11, Jozsef Kadlecsik wrote:
> >> >> 
> >> >> Correct -- if you had stayed with "-version-info", which you did not.
> >> >
> >> >So if it's reverted back (second part of your patch), the the first part 
> >> >is to be skipped.
> >> 
> >> Since you already have made a release (ipset-6.13) emitting an .so.3
> >> file, I don't think you should go back to .so.2. Hence I am using 3:0:0.
> >
> >What I meant is to keep LIBVERSION = 3:0:1, because that's right from 
> >backward compatibility view, and restore back -version-info.
> 
> What part was unclear?
> 
> * 6.13 uses -version-number 3:0:1
> * that causes production of .so.3
> * it's set in stone
> * next incompatible change requires use of .so.4

Yes ,right.

[...] 
> * therefore the patch makes a clean restart,
>   using -version-info 3:0:0, to continue using .so.3
>   starting from ipset-6.13 until the next *real*
>   incompatible change.

What is still unclear for me, why a clean restart is required. Looking 
into "libtool", as I see, "-version-number 3:0:1" and "-version-info 
3:0:1" produces the same result. Why should the support of the previous 
interface be excluded?

> (If you care about the uninteresting third digit,
> -version-info 3:1:0 would be wanted.)

Now, you have confused me completely. -version-info 3:1:0 is converted 
directly into current, revision and age, in this order.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Steven Kath]

On Sun, Jul 1, 2012 at 3:46 AM, Mr Dash Four
<mr.dash.four@googlemail.com> wrote:
> You refer to the incoming interface (interface on which packets arrive) as
> the "source". That cannot be right. To me, it should be a "destination", not
>  "source" as the very definition of a "destination" is where something ends,
> this is where a packet arrives and where the journey of the packet "stops"
> (or where the packet is "destined" to arrive anyway). It should definitely
> not be a "source" as the packet does not originate there, nor does it start
> its journey there.
>
> Similarly for the outgoing interface - this isn't a "destination" interface
> as the packet doesn't arrive there - it is where it starts its journey from!

I think the current terminology is correct FWIW. From a local network
stack perspective for locally- sourced/destined packets, the source of
incoming packets is the interface and the destination is a local
socket.  The source of an outgoing packet is the local socket (where
it starts its journey) and the destination is the outgoing interface.

More importantly, I would consider your proposed terminology
inarguably backward for the case of forwarded packets.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] build: restore -version-info

[Jan Engelhardt]

On Sunday 2012-07-01 19:20, Jozsef Kadlecsik wrote:
>[...] 
>> * therefore the patch makes a clean restart,
>>   using -version-info 3:0:0, to continue using .so.3
>>   starting from ipset-6.13 until the next *real*
>>   incompatible change.
>
>What is still unclear for me, why a clean restart is required. Looking 
>into "libtool", as I see, "-version-number 3:0:1" and "-version-info 
>3:0:1" produces the same result.

They don't. The libtool manual goes on attempting to explain
"-version-number" with C:R:A, though it could have been a lot easier
to just say "it copies the values as-is to the file suffix".


---8<---
location git://git.inai.de/ipset (updated)

parent 7c7b022a18ea2bae11d889b345caef87f3bf145e (v6.13)
commit 2b145f0794de6f56eaded0a6403be995be98c93b
Author: Jan Engelhardt <jengelh@inai.de>
Date:   Sat Jun 30 20:39:27 2012 +0200

build: restore -version-info

Commit v6.13~7 accidentally swapped "-version-info" with
"-version-number". Because "-version-number" takes the values
"FIRST:AGE:REV", which is different from "-version-info
CURRENT:REV:AGE", libipset.so.3 was emitted.

Restore using "-version-info" and continue to use 3 as the "FIRST"
interface (instead of 2), because it was declared that way in
ipset-6.13.

Also note that the version names in libipset.map generally are not
supposed to follow SO versions, but the program version):
IPSET_6.13 {...}.
---
 Make_global.am  |    2 +-
 lib/Makefile.am |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Make_global.am b/Make_global.am
index 4a8f61a..e9f9afd 100644
--- a/Make_global.am
+++ b/Make_global.am
@@ -69,7 +69,7 @@
 # interface. 
 
 #            curr:rev:age
-LIBVERSION = 3:0:1
+LIBVERSION = 3:1:0
 
 AM_CPPFLAGS = $(kinclude_CFLAGS) $(all_includes) -I$(top_srcdir)/include \
 	-I/usr/local/include
diff --git a/lib/Makefile.am b/lib/Makefile.am
index 392b5f9..fd853dd 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -19,7 +19,7 @@ lib_LTLIBRARIES = libipset.la
 
 include $(top_srcdir)/lib/Make_extra.am
 
-libipset_la_LDFLAGS = -Wl,--version-script=$(top_srcdir)/lib/libipset.map -version-number $(LIBVERSION)
+libipset_la_LDFLAGS = -Wl,--version-script=$(top_srcdir)/lib/libipset.map -version-info $(LIBVERSION)
 libipset_la_LIBADD  = ${libmnl_LIBS} $(IPSET_SETTYPE_STATIC_OBJECTS)
 libipset_la_SOURCES = \
 	data.c \
-- 
# Created with git-export-patch

Re: [PATCH] build: restore -version-info

[Jozsef Kadlecsik]

On Sun, 1 Jul 2012, Jan Engelhardt wrote:

> On Sunday 2012-07-01 19:20, Jozsef Kadlecsik wrote:
> >[...] 
> >> * therefore the patch makes a clean restart,
> >>   using -version-info 3:0:0, to continue using .so.3
> >>   starting from ipset-6.13 until the next *real*
> >>   incompatible change.
> >
> >What is still unclear for me, why a clean restart is required. Looking 
> >into "libtool", as I see, "-version-number 3:0:1" and "-version-info 
> >3:0:1" produces the same result.
> 
> They don't. The libtool manual goes on attempting to explain
> "-version-number" with C:R:A, though it could have been a lot easier
> to just say "it copies the values as-is to the file suffix".
> 
> ---8<---
> location git://git.inai.de/ipset (updated)
> 
> parent 7c7b022a18ea2bae11d889b345caef87f3bf145e (v6.13)
> commit 2b145f0794de6f56eaded0a6403be995be98c93b
> Author: Jan Engelhardt <jengelh@inai.de>
> Date:   Sat Jun 30 20:39:27 2012 +0200
> 
> build: restore -version-info
> 
> Commit v6.13~7 accidentally swapped "-version-info" with
> "-version-number". Because "-version-number" takes the values
> "FIRST:AGE:REV", which is different from "-version-info
> CURRENT:REV:AGE", libipset.so.3 was emitted.

Ohh, I got it - thanks, really. Somehow I stopped at how CURR is 
calculated from FIRST and AGE. 

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Neal Murphy]

On Sunday 01 July 2012 11:21:51 Jozsef Kadlecsik wrote:
> Feel free to involve anyone. Just to sum up: in the case of the
> net:hash,iface type of ipset, the manpage says
> 
> "The second direction parameter of the set match and SET target modules
> corresponds to the incoming/outgoing interface: src to the incoming one
> (similar to the -i flag of iptables), while dst to the outgoing one
> (similar to the -o flag of iptables)."
> 
> You argue that the meaning of src/dst for the interface part is
> counter-intuitieve and therefore must be reversed - regardless of the
> backward compatibility issue and the possible breaking of existing setups.

FWIW, I think the existing semantics are spot-on.
  - Where did this packet come from (what was its source)?
    It came from src IF eth0.
  - Where is this packet going (what is its destination)?
    It is going to dst IF eth3.

Picture yourself standing in the middle of a (shallow) river. By Mr. Dash 
Four's logic, upstream (where the water comes from) is the destination and 
downstream (where the water is going) is the source; it's rather non-sensical. 
A stream of packets, just like a stream of water, flows from its source toward 
its destination. (A pedant might say that to swap 'source' and 'destination' 
would be to pervert language. And language is about the only thing we can use 
to communicate.)

Perhaps it would help to view netfilter as a small wayside in the universe of 
IPv[46], rather than the center of that universe.

Re: [ANNOUNCE] ipset 6.13 released

[Jan Engelhardt]

On Sunday 2012-07-01 23:30, Neal Murphy wrote:
>
>Picture yourself standing in the middle of a (shallow) river. By Mr.
>Dash Four's logic, upstream (where the water comes from) is the
>destination and downstream (where the water is going) is the source;
>it's rather non-sensical.

Must be a physicist thing. Electrons, those little but important things 
giving us juice on the mains (which in most practical cases are solid 
conductors), have also been declared to be negative. Just because.

Re: [ANNOUNCE] ipset 6.13 released

[Amos Jeffries]

On 02.07.2012 03:21, Jozsef Kadlecsik wrote:
> On Sun, 1 Jul 2012, Mr Dash Four wrote:
>
>> > the manpage, but it's totally counter-intuitive for you. Changing 
>> the
>> > meaning might break working firewalls. Therefore the meaning won't 
>> be
>> > changed.
>> >
>> This isn't simply a question of "meaning" - it is an issue caused by 
>> the
>> fact that you have introduced something which, it seems, wasn't 
>> properly
>> checked initially for whatever reason and that is causing a great 
>> deal
>> of inconsistency and inconvenience for people, like myself, who use
>> ipset on a daily basis.
>
> I have to weight the "great deal of inconsistency and inconvenience"
> caused to you against breaking firewall setups out there. I really
> appreciate your comments, but in this case you should adapt.
>
>> When I match an incoming packet destined to an IP address for 
>> example, I
>> have to use, quite rightly, a "dst" designation, but when I match
>> against the interface to which this same IP address belongs to,
>> according to your man page, I have to use "src" instead - all this,
>> simply because you didn't check this properly when hash:net,iface 
>> was
>> first released and you can't be bothered, for one reason or another, 
>> to
>> change it simply because "this has been out for a long time"?
>>
>> Do you think that all the network admins out there will have to 
>> remember
>> to use "dst" when matching on destination IP addresses, port numbers
>> etc, but use exactly the opposite designation - "src" - when 
>> matching on
>> the same destination interface that same IP address belongs to? Do 
>> you
>> not see how inconvenient and downright misleading this is? If you 
>> can't,
>> you are beyond hope, I am afraid.
>
> Do you think all admins constantly read all changelogs, mailing lists
> about all the software they use to catch backward incompatible 
> changes?
> You are aware of the "inconveniece", and you could adapt yourself to 
> it
> anytime. I'm responsible for every user, for those who never read 
> these
> mailing lists as well.
>
>> Right, I am going to include Patrick in this as this whole saga is 
>> becoming
>> something of a monologue and I need a bit of clarity on this.
>
> Feel free to involve anyone. Just to sum up: in the case of the
> net:hash,iface type of ipset, the manpage says
>
> "The second direction parameter of the set match and SET target 
> modules
> corresponds to the incoming/outgoing interface: src to the incoming 
> one
> (similar to the -i flag of iptables), while dst to the outgoing one
> (similar to the -o flag of iptables)."
>
> You argue that the meaning of src/dst for the interface part is
> counter-intuitieve and therefore must be reversed - regardless of the
> backward compatibility issue and the possible breaking of existing 
> setups.

Jozsef,
  just my 3c on this discussion to see if its any help.

As you say Mr Dash Four brings up a good point about confusion. It 
certainly seems to confuse him/her, and very likely others with less 
documentation reading experience.

IME the practice when this type of thing happens is good to find some 
alternative clear naming for the parameters and to deprecate the old 
ones. That allows the old names to be dropped from documented use, but 
kept supported for existing config with a warning that admin need to 
check the docs for new usage.

For myself, given the man page snippet it is clear what you intended 
src/dst to be the "local" src/dst. But it is inconsistent with iptables 
usages of src/dst and will trip up anyone not reading that page. Which 
is not a good situation to be in.

Having been in that situation myself I sympathize and had this same 
argument about the same scope concept with other developers several 
times now. We usually end up using some form of "local" terminology for 
the box internal details to differentiate from end-to-end scope 
terminology. In this case --iface-ip / --oface-ip would probably be the 
clearest contenders for your selection. But that is up to you.

/3c

HTH
AYJ

Re: [ANNOUNCE] ipset 6.13 released

[Amos Jeffries]

On 02.07.2012 03:21, Jozsef Kadlecsik wrote:
> On Sun, 1 Jul 2012, Mr Dash Four wrote:
>
>> > the manpage, but it's totally counter-intuitive for you. Changing 
>> the
>> > meaning might break working firewalls. Therefore the meaning won't 
>> be
>> > changed.
>> >
>> This isn't simply a question of "meaning" - it is an issue caused by 
>> the
>> fact that you have introduced something which, it seems, wasn't 
>> properly
>> checked initially for whatever reason and that is causing a great 
>> deal
>> of inconsistency and inconvenience for people, like myself, who use
>> ipset on a daily basis.
>
> I have to weight the "great deal of inconsistency and inconvenience"
> caused to you against breaking firewall setups out there. I really
> appreciate your comments, but in this case you should adapt.
>
>> When I match an incoming packet destined to an IP address for 
>> example, I
>> have to use, quite rightly, a "dst" designation, but when I match
>> against the interface to which this same IP address belongs to,
>> according to your man page, I have to use "src" instead - all this,
>> simply because you didn't check this properly when hash:net,iface 
>> was
>> first released and you can't be bothered, for one reason or another, 
>> to
>> change it simply because "this has been out for a long time"?
>>
>> Do you think that all the network admins out there will have to 
>> remember
>> to use "dst" when matching on destination IP addresses, port numbers
>> etc, but use exactly the opposite designation - "src" - when 
>> matching on
>> the same destination interface that same IP address belongs to? Do 
>> you
>> not see how inconvenient and downright misleading this is? If you 
>> can't,
>> you are beyond hope, I am afraid.
>
> Do you think all admins constantly read all changelogs, mailing lists
> about all the software they use to catch backward incompatible 
> changes?
> You are aware of the "inconveniece", and you could adapt yourself to 
> it
> anytime. I'm responsible for every user, for those who never read 
> these
> mailing lists as well.
>
>> Right, I am going to include Patrick in this as this whole saga is 
>> becoming
>> something of a monologue and I need a bit of clarity on this.
>
> Feel free to involve anyone. Just to sum up: in the case of the
> net:hash,iface type of ipset, the manpage says
>
> "The second direction parameter of the set match and SET target 
> modules
> corresponds to the incoming/outgoing interface: src to the incoming 
> one
> (similar to the -i flag of iptables), while dst to the outgoing one
> (similar to the -o flag of iptables)."
>
> You argue that the meaning of src/dst for the interface part is
> counter-intuitieve and therefore must be reversed - regardless of the
> backward compatibility issue and the possible breaking of existing 
> setups.

Jozsef,
  just my 3c on this discussion to see if its any help.

As you say Mr Dash Four brings up a good point about confusion. It 
certainly seems to confuse him/her, and very likely others with less 
documentation reading experience.

IME the practice when this type of thing happens is good to find some 
alternative clear naming for the parameters and to deprecate the old 
ones. That allows the old names to be dropped from documented use, but 
kept supported for existing config with a warning that admin need to 
check the docs for new usage.

For myself, given the man page snippet it is clear what you intended 
src/dst to be the "local" src/dst. But it is inconsistent with iptables 
usages of src/dst and will trip up anyone not reading that page. Which 
is not a good situation to be in.

Having been in that situation myself I sympathize and had this same 
argument about the same scope concept with other developers several 
times now. We usually end up using some form of "local" terminology for 
the box internal details to differentiate from end-to-end scope 
terminology. In this case --iface-ip / --oface-ip would probably be the 
clearest contenders for your selection. But that is up to you.

/3c

HTH
AYJ

Re: [ANNOUNCE] ipset 6.13 released

[Neal Murphy]

On Sunday 01 July 2012 17:55:32 Jan Engelhardt wrote:
> On Sunday 2012-07-01 23:30, Neal Murphy wrote:
> >Picture yourself standing in the middle of a (shallow) river. By Mr.
> >Dash Four's logic, upstream (where the water comes from) is the
> >destination and downstream (where the water is going) is the source;
> >it's rather non-sensical.
> 
> Must be a physicist thing. Electrons, those little but important things
> giving us juice on the mains (which in most practical cases are solid
> conductors), have also been declared to be negative. Just because.

Physicists *are* known to have warped senses of humor. :) Electricity's the 
only current flow I know of that is counter-intuitive on the surface. The flow 
of electron *holes* defines current (+ to -), while electrons flow from - to 
+.

Re: [ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

On Mon, 2 Jul 2012, Amos Jeffries wrote:

> As you say Mr Dash Four brings up a good point about confusion. It certainly
> seems to confuse him/her, and very likely others with less documentation
> reading experience.
> 
> IME the practice when this type of thing happens is good to find some
> alternative clear naming for the parameters and to deprecate the old ones.
> That allows the old names to be dropped from documented use, but kept
> supported for existing config with a warning that admin need to check the docs
> for new usage.
> 
> For myself, given the man page snippet it is clear what you intended src/dst
> to be the "local" src/dst. But it is inconsistent with iptables usages of
> src/dst and will trip up anyone not reading that page. Which is not a good
> situation to be in.
> 
> Having been in that situation myself I sympathize and had this same argument
> about the same scope concept with other developers several times now. We
> usually end up using some form of "local" terminology for the box internal
> details to differentiate from end-to-end scope terminology. In this case
> --iface-ip / --oface-ip would probably be the clearest contenders for your
> selection. But that is up to you.

The issue is related to the hash:net,iface type alone and only the 
interface part of the type: which interface is the "source" of the packet 
and which one is the "destination". (There's no problem whatsoevert to 
associate "src" and "dst" to the IP addresses/port/MAC of the packets.)

Maybe ASCII art helps better to explain the different views:

- Mr Dash Four

                     -----------
  pkt comes in ----- | machine | ----- pkt goes out
                   ^ ----------- ^
                 destination   source

- my view follows how the subsytem sees the interfaces

                             ------------------
  pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
                           ^ ------------------ ^
                       source               destination

As we learned, the latter is wrong and inconsistent, moreover buggy.

"src" and "dst" are generic keywords of the set match and SET target of 
iptables/ip6tables and independent of the set types. The match and target 
have no idea what is "src" and "dst", the given set interprets them 
according to the type. 

Also, it is not possible to introduce alternate keywords just for the sake 
of the hash:net,iface, because ipset supports list of sets and in that 
case the underlying sub-types are practically unknown to the match/target 
(and additionally can be changed anytime).

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Mr Dash Four]

> Maybe ASCII art helps better to explain the different views:
>
> - Mr Dash Four
>
>                      -----------
>   pkt comes in ----- | machine | ----- pkt goes out
>                    ^ ----------- ^
>                  destination   source
>
> - my view follows how the subsytem sees the interfaces
>
>                              ------------------
>   pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
>                            ^ ------------------ ^
>                        source               destination
>
>   
How do you explain that the same "ipset subsystem" treats the IP address 
of the "source" interface (according to your diagram above) as 
"destination" when I match the same (incoming) packet above?

In other words, when I match a packet arriving on the "source" interface 
(again, according to the diagram above) against the IP address this 
"source" interface belongs to, I have to use "dst" designation, not 
"src", but when I match it against the interface then I have to use 
"src" instead? Also, how do you explain that the same designation 
(destination) applies for everything else but the hash:net,iface set for 
the same type of match (incoming packet)?

Give me a reasonable and coherent explanation and I'll accept your argument.

> "src" and "dst" are generic keywords of the set match and SET target of 
> iptables/ip6tables and independent of the set types. The match and target 
> have no idea what is "src" and "dst", the given set interprets them 
> according to the type.
>   
Regardless of whether the set match and SET target use these two 
keywords, across the whole netfilter terminology, there is consistency 
applied with the notable exception of the hash:net,iface and the "iface" 
part in particular.

Re: [ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

On Mon, 2 Jul 2012, Mr Dash Four wrote:

> > Maybe ASCII art helps better to explain the different views:
> > 
> > - Mr Dash Four
> > 
> >                      -----------
> >   pkt comes in ----- | machine | ----- pkt goes out
> >                    ^ ----------- ^
> >                  destination   source
> > 
> > - my view follows how the subsytem sees the interfaces
> > 
> >                              ------------------
> >   pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
> >                            ^ ------------------ ^
> >                        source               destination
> > 
> >   
> How do you explain that the same "ipset subsystem" treats the IP address 
> of the "source" interface (according to your diagram above) as 
> "destination" when I match the same (incoming) packet above?

The source and destination IP addresses come of course from the packets. 
They have nothing to do with the interfaces - one can route any (sort of) 
packet with any source/destination IP addresses to whatever interface.

Do you skip routers and think of end hosts only, where the 
destination/source IP address is that of the receiving/sending interface?

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Mr Dash Four]

>>> Maybe ASCII art helps better to explain the different views:
>>>
>>> - Mr Dash Four
>>>
>>>                      -----------
>>>   pkt comes in ----- | machine | ----- pkt goes out
>>>                    ^ ----------- ^
>>>                  destination   source
>>>
>>> - my view follows how the subsytem sees the interfaces
>>>
>>>                              ------------------
>>>   pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
>>>                            ^ ------------------ ^
>>>                        source               destination
>>>
>>>   
>>>       
>> How do you explain that the same "ipset subsystem" treats the IP address 
>> of the "source" interface (according to your diagram above) as 
>> "destination" when I match the same (incoming) packet above?
>>     
>
> The source and destination IP addresses come of course from the packets. 
> They have nothing to do with the interfaces - one can route any (sort of) 
> packet with any source/destination IP addresses to whatever interface.
>
> Do you skip routers and think of end hosts only, where the 
> destination/source IP address is that of the receiving/sending interface?
>   
I see you are avoiding my questions as per usual, so I'll ask them 
again, for the last time:-

1) Why is it that the same "ipset subsystem" in your diagram above 
doesn't seem to apply the same criteria and treats the IP address of the 
"source" interface as a "destination" (not "source"), in order to get a 
match for the same type of (incoming) packet; and

2) How do you explain that the same designation ("destination") applies 
for everything else in that "ipset system" (not to mention 
iptables/netfilter) with the notable exception of hash:net,iface set for 
the same type of match (incoming packet)?

Re: [ANNOUNCE] ipset 6.13 released

[Jozsef Kadlecsik]

On Mon, 2 Jul 2012, Mr Dash Four wrote:
 
> > > > Maybe ASCII art helps better to explain the different views:
> > > > 
> > > > - Mr Dash Four
> > > > 
> > > >                      -----------
> > > >   pkt comes in ----- | machine | ----- pkt goes out
> > > >                    ^ ----------- ^
> > > >                  destination   source
> > > > 
> > > > - my view follows how the subsytem sees the interfaces
> > > > 
> > > >                              ------------------
> > > >   pkt comes in --- interface | ipset subsytem | interface --- pkt goes
> > > > out
> > > >                            ^ ------------------ ^
> > > >                        source               destination
> > > > 
> > > >         
> > > How do you explain that the same "ipset subsystem" treats the IP address
> > > of the "source" interface (according to your diagram above) as
> > > "destination" when I match the same (incoming) packet above?
> > >     
> > 
> > The source and destination IP addresses come of course from the packets.
> > They have nothing to do with the interfaces - one can route any (sort of)
> > packet with any source/destination IP addresses to whatever interface.
> > 
> > Do you skip routers and think of end hosts only, where the
> > destination/source IP address is that of the receiving/sending interface?
> >   
> I see you are avoiding my questions as per usual, so I'll ask them again, for
> the last time:-
> 
> 1) Why is it that the same "ipset subsystem" in your diagram above doesn't
> seem to apply the same criteria and treats the IP address of the "source"
> interface as a "destination" (not "source"), in order to get a match for the
> same type of (incoming) packet; and

Nobody talks about the IP address of the interface - just you.
 
> 2) How do you explain that the same designation ("destination") applies for
> everything else in that "ipset system" (not to mention iptables/netfilter)
> with the notable exception of hash:net,iface set for the same type of match
> (incoming packet)?

I have wasted my time, so I stop here and the thread is ended for me.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics, Hungarian Academy of Sciences
          H-1525 Budapest 114, POB. 49, Hungary

Re: [ANNOUNCE] ipset 6.13 released

[Andreas Herz]

On 01/07/12 at 16:44, Jozsef Kadlecsik wrote:
> On Sun, 1 Jul 2012, Andreas Herz wrote:
> 
> > On 29/06/12 at 22:04, Jozsef Kadlecsik wrote:
> > > I have just released ipset 6.13 with a few bugfixes and some new features.
> > 
> > Great, perfect timing, because i will go back to the testing and coding
> > stuff for my ipset setup :)
> > 
> > >  - Timeout fixing bug broke SET target special timeout value, fixed
> > >  - Use MSEC_PER_SEC instead of harcoded value
> > 
> > Does this also fix the jiffies issue with the kernel?
> 
> That was fixed in the previous version. 
> 

I thought so, but:

> > But i will see it in my testcases nevertheless.
> 
> I'm looking forward your testing results!

$IPSET create bset32 hash:ip family inet hashsize 1024 maxelem 65536
timeout 1000

ipset add bset32 192.168.0.21 timeout 2147483; ipset list
=> 192.168.0.21 timeout 2147482
ipset add bset32 192.168.0.20 timeout 2147485; ipset list
=> 192.168.0.20 timeout 1073650

although the range should be 0-4294967 as pointed when i enter a value
much higher.

This is for 32-Bit. But i still think this is caused by the kernel bug i
mentioned some time ago. Can you or anyone else confirm this issue with
32-Bit?
I have a workaround patch but i would love to get the maximum value to
lock IPs for more then ~12 days :)

-- 
Andreas Herz

Re: [ANNOUNCE] ipset 6.13 released

[Alex Bligh]

--On 2 July 2012 09:54:20 +0200 Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> 
wrote:

> - my view follows how the subsytem sees the interfaces
>
>                              ------------------
>   pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
>                            ^ ------------------ ^
>                        source               destination

I have no comment on the back compatibility issue, but from a clean sheet
these interfaces should probably be called "ingress" and "egress"
interfaces (or, if you must 'input' and 'output' but those are ripe for
confusion with iptables rules). If those aren't the terms in the RFCs, they
are certainly terms of art commonly used by router vendors.

>From my point of view, the current nomenclature is better than reversing
them (as I think is being proposed), but they are confusing in the case of
forwarded traffic where neither interface might be the 'source' or
'destination' in an IP sense. Swapping them would cause more confusion.

-- 
Alex Bligh

Re: [ANNOUNCE] ipset 6.13 released

[Alex Bligh]

--On 2 July 2012 09:54:20 +0200 Jozsef Kadlecsik <kadlec@blackhole.kfki.hu> 
wrote:

> - my view follows how the subsytem sees the interfaces
>
>                              ------------------
>   pkt comes in --- interface | ipset subsytem | interface --- pkt goes out
>                            ^ ------------------ ^
>                        source               destination

I have no comment on the back compatibility issue, but from a clean sheet
these interfaces should probably be called "ingress" and "egress"
interfaces (or, if you must 'input' and 'output' but those are ripe for
confusion with iptables rules). If those aren't the terms in the RFCs, they
are certainly terms of art commonly used by router vendors.

From my point of view, the current nomenclature is better than reversing
them (as I think is being proposed), but they are confusing in the case of
forwarded traffic where neither interface might be the 'source' or
'destination' in an IP sense. Swapping them would cause more confusion.

-- 
Alex Bligh