Currently, we have to make miniupnpd referrer the headers in /usr/src/linux which breaks horrible from time to time. It would really make it easier if iptables could install the two headers (nf_nat.h and nf_conntrack_tuple.h) into /usr/include/net/netfilter . The two header files are included in the iptables tarball in the include subdirectory. I have attached a patch that makes iptables install the headers, which in place make it possible for miniupnpd to build. Reproducible: Always Actual Results: The headers are missing. Expected Results: The headers should have been installed.
Created attachment 281407 [details] Patch to ebuild to make it install headers Here is that patch that changes the ebuild to install the two missing headers.
I'm not opposed to this, but I'd like to hear what upstream tells us first as installing of headers iptables fells really hacky. I've sent mail to netfilter-devel asking for clarification of this situation.
The other alternative is to expand linux-headers. See comment bug #376631 comment #c3.
(In reply to comment #3) > The other alternative is to expand linux-headers. See comment bug #376631 > comment #c3. I have updated the bug with some more info. It seems that if I use the two header files from the 3.0 kernel, it fails, but if I use the two header files from the iptables tarball, it works. So using the ones from iptables would be the best option.
(In reply to comment #4) > (In reply to comment #3) > > The other alternative is to expand linux-headers. See comment bug #376631 > > comment #c3. > > I have updated the bug with some more info. > > It seems that if I use the two header files from the 3.0 kernel, it fails, but > if I use the two header files from the iptables tarball, it works. > So using the ones from iptables would be the best option. It fails because there's more to the kernel headers, so you also need to include linux/list.h.
(In reply to comment #5) In any case the question where fix belongs is a valid one. If this is public api - then fix kernel sources to export as it should. If this is private then it's up to miniupnpd to provide required hack.
(In reply to comment #5) > > It fails because there's more to the kernel headers, so you also need to > include linux/list.h. Right, but then I need to include list_nulls.h poison.h nf_conntrack_pptp.h and several others, so before I'm done, the entire header collection from the kernel has been copied to the /usr/include directory, so thats not really an option :(
(In reply to comment #6) So the real question is, if nf_nat.h is a public API or not?
(In reply to comment #6) > (In reply to comment #5) > > In any case the question where fix belongs is a valid one. If this is public > api - then fix kernel sources to export as it should. If this is private then > it's up to miniupnpd to provide required hack. Fixing the public api is the correct long term solution. Other packages might make use of it. A private fix to miniupnpd should proceed by miniupnpd installing the needed headers without involving iptables package.
(In reply to comment #9) > Fixing the public api is the correct long term solution. Other packages might > make use of it. A private fix to miniupnpd should proceed by miniupnpd > installing the needed headers without involving iptables package. If miniupnpd installs some of the iptables headers, won't that cause problems when package XYZ comes along, and also needs to use nf_nat.h , and tries to install it to, causing a collision?
(In reply to comment #10) > (In reply to comment #9) > > Fixing the public api is the correct long term solution. Other packages might > > make use of it. A private fix to miniupnpd should proceed by miniupnpd > > installing the needed headers without involving iptables package. > > If miniupnpd installs some of the iptables headers, won't that cause problems > when package XYZ comes along, and also needs to use nf_nat.h , and tries to > install it to, causing a collision? Yeah sorry, I didn't say that right. It should make use of private ones while compiling, not put them on the filesystem.
(In reply to comment #11) > Yeah sorry, I didn't say that right. It should make use of private ones while > compiling, not put them on the filesystem. Ahh yeah, that would be the solution I'll go for, if the headers isn't supposed to be installed.
iptables should not be installing any /usr/include/net/ files. if you want linux-headers to install them, send a patch to the net/lkml mailing lists to add them to the user space exported set.
I've fixed it another way already, so for now I'll just let it be as it is. Peter has already written to the netfilter people, so I guess they will get the headers exported if they should have been, since they know better than I do, if they should or not (public vs. private api)
So I'm closing this bug, since it doesn't make sense anymore.
And here is the answer: http://www.spinics.net/lists/netfilter-devel/msg19302.html iptables is actually wrong in copying that file, the userspace portions such as nf_nat_manip_types and nf_nat_*range need to be moved to a new file under include/linux/netfilter_ipv4/ which is installed and used by userspace. So kernel needs to be fixed.
(In reply to comment #16) > And here is the answer: > > http://www.spinics.net/lists/netfilter-devel/msg19302.html > > iptables is actually wrong in copying that file, the userspace portions > such as nf_nat_manip_types and nf_nat_*range need to be moved to a new > file under include/linux/netfilter_ipv4/ which is installed and used > by userspace. > > So kernel needs to be fixed. Do we know if that's in the works, or should we submit a bug upstream? Sounds like its a known issue though.
(In reply to comment #17) > Do we know if that's in the works, or should we submit a bug upstream? Sounds > like its a known issue though. I'm not aware about such work: it looks like other distributions prefer workarounds...
anyone can send patches to lkml ...
Created attachment 282679 [details, diff] Patch to add nf_nat.h, nf_conntrack.h and friends to linux-headers-3.0.1 lkml is a scary place :) I'm willing to try but I would like this community to review the above patch before I do. My one concern is completeness. While this patch does address the needed headers for miniupnpd, I'm not sure about other applications that might need more in the same set. My other concern is that this will clash with iptables which wants to install its own header. Of course I'll cc both groups, but it makes the sale all the harder.
(In reply to comment #20) > lkml is a scary place :) I'm willing to try but I would like this community to > review the above patch before I do. Please submit it to lkml, from what I can see, there shouldn't be anything in there breaking anything :) > My one concern is completeness. While this patch does address the needed > headers for miniupnpd, I'm not sure about other applications that might need > more in the same set. In that case, it can be updated to include more headers by the people needing them. > My other concern is that this will clash with iptables which wants to install > its own header. Of course I'll cc both groups, but it makes the sale all the > harder. Well, since iptables shouldn't be installing the headers, we should be find (this also makes it unneeded to do for iptables)
(In reply to comment #21) > (In reply to comment #20) > > lkml is a scary place :) I'm willing to try but I would like this community to > > review the above patch before I do. > > Please submit it to lkml, from what I can see, there shouldn't be anything in > there breaking anything :) > > > My one concern is completeness. While this patch does address the needed > > headers for miniupnpd, I'm not sure about other applications that might need > > more in the same set. > > In that case, it can be updated to include more headers by the people needing > them. > > > My other concern is that this will clash with iptables which wants to install > > its own header. Of course I'll cc both groups, but it makes the sale all the > > harder. > > Well, since iptables shouldn't be installing the headers, we should be find > (this also makes it unneeded to do for iptables) The patch is submitted upstream: https://lkml.org/lkml/2011/9/3/69
Version 2 of the patch is upstream. Pablo was critical of too much structure being exposed publicly, structure which can change without prediction. http://www.spinics.net/lists/netfilter-devel/msg19625.html
can you attach the actual patch that was merged upstream so we can add it to linux-headers-3.0 ?
(In reply to comment #24) > can you attach the actual patch that was merged upstream so we can add it to > linux-headers-3.0 ? Sorry, I didn't mean it was accepted, I mean I submitted a second version for review and Pablo is still critical of too much being exposed, so there will be a round 3. When it is accepted, I'll post here and be clear about it.
(In reply to comment #25) > (In reply to comment #24) > > can you attach the actual patch that was merged upstream so we can add it to > > linux-headers-3.0 ? > > Sorry, I didn't mean it was accepted, I mean I submitted a second version for > review and Pablo is still critical of too much being exposed, so there will be > a round 3. When it is accepted, I'll post here and be clear about it. I submitted version three of the patch upstream and I'm waiting for a response: http://www.spinics.net/lists/netfilter-devel/msg19771.html
(In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > can you attach the actual patch that was merged upstream so we can add it to > > > linux-headers-3.0 ? > > > > Sorry, I didn't mean it was accepted, I mean I submitted a second version for > > review and Pablo is still critical of too much being exposed, so there will be > > a round 3. When it is accepted, I'll post here and be clear about it. > > I submitted version three of the patch upstream and I'm waiting for a response: > > http://www.spinics.net/lists/netfilter-devel/msg19771.html Okay after some back and forth about how to do this, we came up with a patch that was accepted. Here's the link to the commit: http://1984.lsi.us.es/git/?p=net-next/.git;a=commit;h=2ca5b853f1dd81c605ddc8a55e06bdad85636597 They still haven't migrated back to git.kernel.org. The debate behind this patch is on the email list. You can follow the thread: http://www.spinics.net/lists/netfilter-devel/msg19771.html
Thank you Anthony!
