On Wednesday 2010-03-17 15:16, Patrick McHardy wrote: >>> I guess this makes sense, however iptables has special interpretations >>> of errno values. How will this interact? >> >> Since we are "just going back", the effect should be none - dig out >> an old iptables and kernel and you get the same environment. > >No, we're now returning additional errno values from modules. > >> Well, libiptc prints a few specialized error messages for certain >> codes (cf libiptc.c, TC_STRERROR), else uses plain libc strerror. > >That's what I was talking about. Unfortunately quite a few >of the reasonable combinations have special meaning, f.i. >TC_INIT/ENOENT, TC_INIT/EINVAL, ... We need only be concerned about TC_COMMIT (which calls setsockopt with SO_SET_REPLACE, which leads to checkentry). TC_COMMIT returns 0 or 1, with errno set from what setsockopt left - this will be the error code, as it is also just propagated inside the kernel, if I read it right. So flow control ends up at iptables-standalone.c at the end and the errno code is just used for printing/choosing an error code. If I missed something, please enlighten me. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
