* [ANNOUNCE] ipset 6.13 released
@ 2012-06-29 20:04 Jozsef Kadlecsik
2012-06-30 18:47 ` Jan Engelhardt
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-06-29 20:04 UTC (permalink / raw)
To: netfilter, netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-06-29 20:04 [ANNOUNCE] ipset 6.13 released Jozsef Kadlecsik
@ 2012-06-30 18:47 ` Jan Engelhardt
2012-06-30 18:47 ` [PATCH] build: restore -version-info Jan Engelhardt
2012-07-01 10:46 ` [ANNOUNCE] ipset 6.13 released Mr Dash Four
2012-07-01 13:21 ` Andreas Herz
2 siblings, 1 reply; 37+ messages in thread
From: Jan Engelhardt @ 2012-06-30 18:47 UTC (permalink / raw)
To: kadlec; +Cc: netfilter-devel
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(-)
^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH] build: restore -version-info
2012-06-30 18:47 ` Jan Engelhardt
@ 2012-06-30 18:47 ` Jan Engelhardt
2012-06-30 22:05 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Jan Engelhardt @ 2012-06-30 18:47 UTC (permalink / raw)
To: kadlec; +Cc: netfilter-devel
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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-06-30 18:47 ` [PATCH] build: restore -version-info Jan Engelhardt
@ 2012-06-30 22:05 ` Jozsef Kadlecsik
2012-06-30 22:15 ` Jan Engelhardt
0 siblings, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-06-30 22:05 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-06-30 22:05 ` Jozsef Kadlecsik
@ 2012-06-30 22:15 ` Jan Engelhardt
2012-06-30 22:31 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Jan Engelhardt @ 2012-06-30 22:15 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter-devel
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-06-30 22:15 ` Jan Engelhardt
@ 2012-06-30 22:31 ` Jozsef Kadlecsik
2012-06-30 22:50 ` Jan Engelhardt
0 siblings, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-06-30 22:31 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-06-30 22:31 ` Jozsef Kadlecsik
@ 2012-06-30 22:50 ` Jan Engelhardt
2012-07-01 12:11 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Jan Engelhardt @ 2012-06-30 22:50 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter-devel
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-06-29 20:04 [ANNOUNCE] ipset 6.13 released Jozsef Kadlecsik
2012-06-30 18:47 ` Jan Engelhardt
@ 2012-07-01 10:46 ` Mr Dash Four
2012-07-01 12:09 ` Jozsef Kadlecsik
2012-07-01 18:32 ` Steven Kath
2012-07-01 13:21 ` Andreas Herz
2 siblings, 2 replies; 37+ messages in thread
From: Mr Dash Four @ 2012-07-01 10:46 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter, netfilter-devel
> 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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 10:46 ` [ANNOUNCE] ipset 6.13 released Mr Dash Four
@ 2012-07-01 12:09 ` Jozsef Kadlecsik
2012-07-01 12:19 ` Mr Dash Four
2012-07-01 18:32 ` Steven Kath
1 sibling, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-01 12:09 UTC (permalink / raw)
To: Mr Dash Four; +Cc: netfilter, netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-06-30 22:50 ` Jan Engelhardt
@ 2012-07-01 12:11 ` Jozsef Kadlecsik
2012-07-01 16:03 ` Jan Engelhardt
0 siblings, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-01 12:11 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 12:09 ` Jozsef Kadlecsik
@ 2012-07-01 12:19 ` Mr Dash Four
2012-07-01 12:37 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Mr Dash Four @ 2012-07-01 12:19 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter, netfilter-devel
> 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!
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 12:19 ` Mr Dash Four
@ 2012-07-01 12:37 ` Jozsef Kadlecsik
2012-07-01 12:44 ` Mr Dash Four
0 siblings, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-01 12:37 UTC (permalink / raw)
To: Mr Dash Four; +Cc: netfilter, netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 12:37 ` Jozsef Kadlecsik
@ 2012-07-01 12:44 ` Mr Dash Four
2012-07-01 12:52 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Mr Dash Four @ 2012-07-01 12:44 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter, netfilter-devel
> 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?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 12:44 ` Mr Dash Four
@ 2012-07-01 12:52 ` Jozsef Kadlecsik
2012-07-01 13:17 ` Mr Dash Four
0 siblings, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-01 12:52 UTC (permalink / raw)
To: Mr Dash Four; +Cc: netfilter, netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 12:52 ` Jozsef Kadlecsik
@ 2012-07-01 13:17 ` Mr Dash Four
2012-07-01 15:21 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Mr Dash Four @ 2012-07-01 13:17 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter, netfilter-devel, Patrick McHardy
> 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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-06-29 20:04 [ANNOUNCE] ipset 6.13 released Jozsef Kadlecsik
2012-06-30 18:47 ` Jan Engelhardt
2012-07-01 10:46 ` [ANNOUNCE] ipset 6.13 released Mr Dash Four
@ 2012-07-01 13:21 ` Andreas Herz
2012-07-01 14:44 ` Jozsef Kadlecsik
2 siblings, 1 reply; 37+ messages in thread
From: Andreas Herz @ 2012-07-01 13:21 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 13:21 ` Andreas Herz
@ 2012-07-01 14:44 ` Jozsef Kadlecsik
2012-07-10 9:12 ` Andreas Herz
0 siblings, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-01 14:44 UTC (permalink / raw)
To: Andreas Herz; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 13:17 ` Mr Dash Four
@ 2012-07-01 15:21 ` Jozsef Kadlecsik
2012-07-01 16:52 ` Mr Dash Four
` (2 more replies)
0 siblings, 3 replies; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-01 15:21 UTC (permalink / raw)
To: Mr Dash Four; +Cc: netfilter, netfilter-devel, Patrick McHardy
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-07-01 12:11 ` Jozsef Kadlecsik
@ 2012-07-01 16:03 ` Jan Engelhardt
2012-07-01 17:20 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Jan Engelhardt @ 2012-07-01 16:03 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter-devel
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.)
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 15:21 ` Jozsef Kadlecsik
@ 2012-07-01 16:52 ` Mr Dash Four
2012-07-01 21:30 ` Neal Murphy
2012-07-01 22:58 ` Amos Jeffries
2 siblings, 0 replies; 37+ messages in thread
From: Mr Dash Four @ 2012-07-01 16:52 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter, netfilter-devel, Patrick McHardy
> 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?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-07-01 16:03 ` Jan Engelhardt
@ 2012-07-01 17:20 ` Jozsef Kadlecsik
2012-07-01 18:36 ` Jan Engelhardt
0 siblings, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-01 17:20 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 10:46 ` [ANNOUNCE] ipset 6.13 released Mr Dash Four
2012-07-01 12:09 ` Jozsef Kadlecsik
@ 2012-07-01 18:32 ` Steven Kath
1 sibling, 0 replies; 37+ messages in thread
From: Steven Kath @ 2012-07-01 18:32 UTC (permalink / raw)
To: Mr Dash Four; +Cc: Jozsef Kadlecsik, netfilter, netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-07-01 17:20 ` Jozsef Kadlecsik
@ 2012-07-01 18:36 ` Jan Engelhardt
2012-07-01 20:45 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Jan Engelhardt @ 2012-07-01 18:36 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter-devel
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
^ permalink raw reply related [flat|nested] 37+ messages in thread
* Re: [PATCH] build: restore -version-info
2012-07-01 18:36 ` Jan Engelhardt
@ 2012-07-01 20:45 ` Jozsef Kadlecsik
0 siblings, 0 replies; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-01 20:45 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: netfilter-devel
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 15:21 ` Jozsef Kadlecsik
2012-07-01 16:52 ` Mr Dash Four
@ 2012-07-01 21:30 ` Neal Murphy
2012-07-01 21:55 ` Jan Engelhardt
2012-07-01 22:58 ` Amos Jeffries
2 siblings, 1 reply; 37+ messages in thread
From: Neal Murphy @ 2012-07-01 21:30 UTC (permalink / raw)
To: netfilter
Cc: Jozsef Kadlecsik, Mr Dash Four, netfilter-devel, Patrick McHardy
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 21:30 ` Neal Murphy
@ 2012-07-01 21:55 ` Jan Engelhardt
2012-07-01 22:59 ` Neal Murphy
0 siblings, 1 reply; 37+ messages in thread
From: Jan Engelhardt @ 2012-07-01 21:55 UTC (permalink / raw)
To: Neal Murphy
Cc: netfilter, Jozsef Kadlecsik, Mr Dash Four, netfilter-devel,
Patrick McHardy
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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 15:21 ` Jozsef Kadlecsik
@ 2012-07-01 22:58 ` Amos Jeffries
2012-07-01 21:30 ` Neal Murphy
2012-07-01 22:58 ` Amos Jeffries
2 siblings, 0 replies; 37+ messages in thread
From: Amos Jeffries @ 2012-07-01 22:58 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Mr Dash Four, netfilter, netfilter-devel, Patrick McHardy
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
@ 2012-07-01 22:58 ` Amos Jeffries
0 siblings, 0 replies; 37+ messages in thread
From: Amos Jeffries @ 2012-07-01 22:58 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Mr Dash Four, netfilter, netfilter-devel, Patrick McHardy
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 21:55 ` Jan Engelhardt
@ 2012-07-01 22:59 ` Neal Murphy
0 siblings, 0 replies; 37+ messages in thread
From: Neal Murphy @ 2012-07-01 22:59 UTC (permalink / raw)
To: Jan Engelhardt
Cc: netfilter, Jozsef Kadlecsik, Mr Dash Four, netfilter-devel,
Patrick McHardy
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
+.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 22:58 ` Amos Jeffries
(?)
@ 2012-07-02 7:54 ` Jozsef Kadlecsik
2012-07-02 13:11 ` Mr Dash Four
2012-07-10 16:27 ` Alex Bligh
-1 siblings, 2 replies; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-02 7:54 UTC (permalink / raw)
To: Amos Jeffries; +Cc: Mr Dash Four, netfilter, netfilter-devel, Patrick McHardy
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 7:54 ` Jozsef Kadlecsik
@ 2012-07-02 13:11 ` Mr Dash Four
2012-07-02 13:26 ` Jozsef Kadlecsik
2012-07-10 16:27 ` Alex Bligh
1 sibling, 1 reply; 37+ messages in thread
From: Mr Dash Four @ 2012-07-02 13:11 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Amos Jeffries, netfilter, netfilter-devel, Patrick McHardy
> 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.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 13:11 ` Mr Dash Four
@ 2012-07-02 13:26 ` Jozsef Kadlecsik
2012-07-02 14:28 ` Mr Dash Four
0 siblings, 1 reply; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-02 13:26 UTC (permalink / raw)
To: Mr Dash Four; +Cc: Amos Jeffries, netfilter, netfilter-devel, Patrick McHardy
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 13:26 ` Jozsef Kadlecsik
@ 2012-07-02 14:28 ` Mr Dash Four
2012-07-02 20:26 ` Jozsef Kadlecsik
0 siblings, 1 reply; 37+ messages in thread
From: Mr Dash Four @ 2012-07-02 14:28 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Amos Jeffries, netfilter, netfilter-devel, Patrick McHardy
>>> 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)?
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 14:28 ` Mr Dash Four
@ 2012-07-02 20:26 ` Jozsef Kadlecsik
0 siblings, 0 replies; 37+ messages in thread
From: Jozsef Kadlecsik @ 2012-07-02 20:26 UTC (permalink / raw)
To: Mr Dash Four; +Cc: Amos Jeffries, netfilter, netfilter-devel, Patrick McHardy
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-01 14:44 ` Jozsef Kadlecsik
@ 2012-07-10 9:12 ` Andreas Herz
0 siblings, 0 replies; 37+ messages in thread
From: Andreas Herz @ 2012-07-10 9:12 UTC (permalink / raw)
To: Jozsef Kadlecsik; +Cc: netfilter
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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
2012-07-02 7:54 ` Jozsef Kadlecsik
@ 2012-07-10 16:27 ` Alex Bligh
2012-07-10 16:27 ` Alex Bligh
1 sibling, 0 replies; 37+ messages in thread
From: Alex Bligh @ 2012-07-10 16:27 UTC (permalink / raw)
To: Jozsef Kadlecsik, Amos Jeffries
Cc: Mr Dash Four, netfilter, netfilter-devel, Patrick McHardy, 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
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [ANNOUNCE] ipset 6.13 released
@ 2012-07-10 16:27 ` Alex Bligh
0 siblings, 0 replies; 37+ messages in thread
From: Alex Bligh @ 2012-07-10 16:27 UTC (permalink / raw)
To: Jozsef Kadlecsik, Amos Jeffries
Cc: Mr Dash Four, netfilter, netfilter-devel, Patrick McHardy, 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
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2012-07-10 16:34 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-06-29 20:04 [ANNOUNCE] ipset 6.13 released Jozsef Kadlecsik
2012-06-30 18:47 ` Jan Engelhardt
2012-06-30 18:47 ` [PATCH] build: restore -version-info Jan Engelhardt
2012-06-30 22:05 ` Jozsef Kadlecsik
2012-06-30 22:15 ` Jan Engelhardt
2012-06-30 22:31 ` Jozsef Kadlecsik
2012-06-30 22:50 ` Jan Engelhardt
2012-07-01 12:11 ` Jozsef Kadlecsik
2012-07-01 16:03 ` Jan Engelhardt
2012-07-01 17:20 ` Jozsef Kadlecsik
2012-07-01 18:36 ` Jan Engelhardt
2012-07-01 20:45 ` Jozsef Kadlecsik
2012-07-01 10:46 ` [ANNOUNCE] ipset 6.13 released Mr Dash Four
2012-07-01 12:09 ` Jozsef Kadlecsik
2012-07-01 12:19 ` Mr Dash Four
2012-07-01 12:37 ` Jozsef Kadlecsik
2012-07-01 12:44 ` Mr Dash Four
2012-07-01 12:52 ` Jozsef Kadlecsik
2012-07-01 13:17 ` Mr Dash Four
2012-07-01 15:21 ` Jozsef Kadlecsik
2012-07-01 16:52 ` Mr Dash Four
2012-07-01 21:30 ` Neal Murphy
2012-07-01 21:55 ` Jan Engelhardt
2012-07-01 22:59 ` Neal Murphy
2012-07-01 22:58 ` Amos Jeffries
2012-07-01 22:58 ` Amos Jeffries
2012-07-02 7:54 ` Jozsef Kadlecsik
2012-07-02 13:11 ` Mr Dash Four
2012-07-02 13:26 ` Jozsef Kadlecsik
2012-07-02 14:28 ` Mr Dash Four
2012-07-02 20:26 ` Jozsef Kadlecsik
2012-07-10 16:27 ` Alex Bligh
2012-07-10 16:27 ` Alex Bligh
2012-07-01 18:32 ` Steven Kath
2012-07-01 13:21 ` Andreas Herz
2012-07-01 14:44 ` Jozsef Kadlecsik
2012-07-10 9:12 ` Andreas Herz
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.