* [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: [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: [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: [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: [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-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: [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-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: [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: [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 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 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 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-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
* 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: [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 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
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.