nfq_set_verdict_mark

nfq_set_verdict_mark

[Robert Scott]

i noticed that this function doesn't automatically convert the mark  
into the expected network byte order.  this is a minor detail, but  
the current behavior may confuse users. since nfq_get_nfmark  
automatically converts the mark into host order, i thought  
nfq_set_verdict_mark would also  do the reverse.

not really a big deal, and this will probably break most existing  
installations in the field, but perhaps a note in the docs to give  
new users a heads up.

cheers,
--robert

Re: nfq_set_verdict_mark

[Pablo Neira Ayuso]

Robert Scott wrote:
> i noticed that this function doesn't automatically convert the mark into
> the expected network byte order.  this is a minor detail, but the
> current behavior may confuse users. since nfq_get_nfmark automatically
> converts the mark into host order, i thought nfq_set_verdict_mark would
> also  do the reverse.
> 
> not really a big deal, and this will probably break most existing
> installations in the field, but perhaps a note in the docs to give new
> users a heads up.

Yes, I agree what you, we have to document this minor issue, I think
that we can introduce more API that can solve this inconsistency.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: nfq_set_verdict_mark

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Robert Scott wrote:
> 
>>i noticed that this function doesn't automatically convert the mark into
>>the expected network byte order.  this is a minor detail, but the
>>current behavior may confuse users. since nfq_get_nfmark automatically
>>converts the mark into host order, i thought nfq_set_verdict_mark would
>>also  do the reverse.
>>
>>not really a big deal, and this will probably break most existing
>>installations in the field, but perhaps a note in the docs to give new
>>users a heads up.
> 
> 
> Yes, I agree what you, we have to document this minor issue, I think
> that we can introduce more API that can solve this inconsistency.

Do we actually have documentation where we can document it? :)

I'm beginning to wonder how much more kludges we will have in these
libraries by continuing to treat them as stable without having had
even a single beta version.

Re: nfq_set_verdict_mark

[Pablo Neira Ayuso]

Hi Patrick,

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Robert Scott wrote:
>>
>>> i noticed that this function doesn't automatically convert the mark into
>>> the expected network byte order.  this is a minor detail, but the
>>> current behavior may confuse users. since nfq_get_nfmark automatically
>>> converts the mark into host order, i thought nfq_set_verdict_mark would
>>> also  do the reverse.
>>>
>>> not really a big deal, and this will probably break most existing
>>> installations in the field, but perhaps a note in the docs to give new
>>> users a heads up.
>>
>> Yes, I agree what you, we have to document this minor issue, I think
>> that we can introduce more API that can solve this inconsistency.
> 
> Do we actually have documentation where we can document it? :)
> 
> I'm beginning to wonder how much more kludges we will have in these
> libraries by continuing to treat them as stable without having had
> even a single beta version.

OK, I start thinking that I'm getting obsessed with breaking current
deployed apps :(. I also think that we can solve this minor annoying
issues by fixing the problem and then releasing a new version asap.

The current release process is too slow, I have the impression that
nobody is using the lastest official releases. For conntrackd, I'm
currently doing unnofficial releases of libnetfilter_conntrack because
the official release is broken with NAT handlings, well apart from the
fact that I also introduce some patches with new features that I need.

Just tell you that I don't mind about spending some time on
administration tasks like releases and any other stuff related with the
website if that can help to speed up the release process. I worked on
some scripts to automate the release process time ago after the workshop
that I can recover.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: nfq_set_verdict_mark

[Patrick McHardy]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
> 
>>I'm beginning to wonder how much more kludges we will have in these
>>libraries by continuing to treat them as stable without having had
>>even a single beta version.
> 
> 
> OK, I start thinking that I'm getting obsessed with breaking current
> deployed apps :(. I also think that we can solve this minor annoying
> issues by fixing the problem and then releasing a new version asap.

I checked google code-search and the two users I could find already
do the conversion manually, so they will break. Thats definitely not
good, but I wonder if we should trust that this will be the last
of these bugs or if we should clearly mark this as beta/unstable API
and appologize for not beeing clear from the beginning. Its just
not a good idea to release a library with an interface that is more
or less cast in stone without any real testing.

> The current release process is too slow, I have the impression that
> nobody is using the lastest official releases. For conntrackd, I'm
> currently doing unnofficial releases of libnetfilter_conntrack because
> the official release is broken with NAT handlings, well apart from the
> fact that I also introduce some patches with new features that I need.

You're probably right (about people not using official releases) and
definitely right about releasing too seldom.

> Just tell you that I don't mind about spending some time on
> administration tasks like releases and any other stuff related with the
> website if that can help to speed up the release process. I worked on
> some scripts to automate the release process time ago after the workshop
> that I can recover.

That would be great. Let me know if you need anything (I think I recall
your keys expired?).

Re: nfq_set_verdict_mark

[Pablo Neira Ayuso]

Patrick McHardy wrote:
> Pablo Neira Ayuso wrote:
>> Patrick McHardy wrote:
>>
>>> I'm beginning to wonder how much more kludges we will have in these
>>> libraries by continuing to treat them as stable without having had
>>> even a single beta version.
>>
>> OK, I start thinking that I'm getting obsessed with breaking current
>> deployed apps :(. I also think that we can solve this minor annoying
>> issues by fixing the problem and then releasing a new version asap.
> 
> I checked google code-search and the two users I could find already
> do the conversion manually, so they will break. Thats definitely not
> good, but I wonder if we should trust that this will be the last
> of these bugs or if we should clearly mark this as beta/unstable API
> and appologize for not beeing clear from the beginning. Its just
> not a good idea to release a library with an interface that is more
> or less cast in stone without any real testing.

We can warn about incompatibilities in the announce of new releases for
this kind of minor issues that we need to fix up and that result in
breakages, some kind of "heads up" section.

For the rest of the API, I remember that in one of my discussions with
Harald we conclude that is better to introduce new API than breaking
current just not to annoy users. We can strongly recommend the use of
the new API and mark old one as deprecated (with the gcc attribute) to
warn users that such obsolete function will vanish soon. That would
stagger changes.

>> The current release process is too slow, I have the impression that
>> nobody is using the lastest official releases. For conntrackd, I'm
>> currently doing unnofficial releases of libnetfilter_conntrack because
>> the official release is broken with NAT handlings, well apart from the
>> fact that I also introduce some patches with new features that I need.
> 
> You're probably right (about people not using official releases) and
> definitely right about releasing too seldom.
> 
>> Just tell you that I don't mind about spending some time on
>> administration tasks like releases and any other stuff related with the
>> website if that can help to speed up the release process. I worked on
>> some scripts to automate the release process time ago after the workshop
>> that I can recover.
> 
> That would be great. Let me know if you need anything (I think I recall
> your keys expired?).

I need to renew my key in order to tag new releases in SVN, I also need
to generate some kind of "release master GPG key" or something in other
to sign new releases.

-- 
The dawn of the fourth age of Linux firewalling is coming; a time of
great struggle and heroic deeds -- J.Kadlecsik got inspired by J.Morris

Re: nfq_set_verdict_mark

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 2282 bytes --]

Le mercredi 11 octobre 2006 à 23:47 +0200, Pablo Neira Ayuso a écrit :

> We can warn about incompatibilities in the announce of new releases for
> this kind of minor issues that we need to fix up and that result in
> breakages, some kind of "heads up" section.

Why not to add a API release number in the code.

As developper of NuFW, I've got no problem to change my code but, I need
a way to have my users not bored when they use my software. In fact I
can not control which version of libnetfilter_queue.

Something like "#define NFQUEUE_API_VERSION NNN" in libnetfilter_queue.h
could really be used easily in application code to detect which flavour
of the API they need to use.

BR,
--
Regit


> 
> For the rest of the API, I remember that in one of my discussions with
> Harald we conclude that is better to introduce new API than breaking
> current just not to annoy users. We can strongly recommend the use of
> the new API and mark old one as deprecated (with the gcc attribute) to
> warn users that such obsolete function will vanish soon. That would
> stagger changes.
> 
> >> The current release process is too slow, I have the impression that
> >> nobody is using the lastest official releases. For conntrackd, I'm
> >> currently doing unnofficial releases of libnetfilter_conntrack because
> >> the official release is broken with NAT handlings, well apart from the
> >> fact that I also introduce some patches with new features that I need.
> > 
> > You're probably right (about people not using official releases) and
> > definitely right about releasing too seldom.
> > 
> >> Just tell you that I don't mind about spending some time on
> >> administration tasks like releases and any other stuff related with the
> >> website if that can help to speed up the release process. I worked on
> >> some scripts to automate the release process time ago after the workshop
> >> that I can recover.
> > 
> > That would be great. Let me know if you need anything (I think I recall
> > your keys expired?).
> 
> I need to renew my key in order to tag new releases in SVN, I also need
> to generate some kind of "release master GPG key" or something in other
> to sign new releases.
> 
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: nfq_set_verdict_mark

[Patrick McHardy]

Eric Leblond wrote:
> Le mercredi 11 octobre 2006 à 23:47 +0200, Pablo Neira Ayuso a écrit :
> 
> 
>>We can warn about incompatibilities in the announce of new releases for
>>this kind of minor issues that we need to fix up and that result in
>>breakages, some kind of "heads up" section.
> 
> 
> Why not to add a API release number in the code.
> 
> As developper of NuFW, I've got no problem to change my code but, I need
> a way to have my users not bored when they use my software. In fact I
> can not control which version of libnetfilter_queue.
> 
> Something like "#define NFQUEUE_API_VERSION NNN" in libnetfilter_queue.h
> could really be used easily in application code to detect which flavour
> of the API they need to use.

That doesn't really solve the problem of incompatibilities. Any breakage
is really bad for a supposedly stable library. Pablo's suggestion about
adding new functions without breaking the old ones makes sense of
course, but there is no guarantee that we won't fuck up again. Which is
why I wanted to raise the question whether we want to continue this
way or go back to beta state until we're reasonable sure about the API.

Well, for now I guess the best way is to add the new functions and
go through a really long beta phase with the new API (after releasing
the current versions, which contain quite a few bugfixes since the
last release).