On Tue, 2007-02-06 at 16:25 -0600, Randy McMurchy wrote: > Andrew Beverley wrote these words on 02/06/07 16:02 CST: > > > Hopefully I'll get this in before 6.2 is released! > > No promises. :-) > > > > Is it possible to update iptables to 1.3.7? I've checked the 'current > > development' version of the book and iptables is still at 1.3.5 > > > > I tried a few weeks ago to compile 1.3.7 on an LFS 6.2 system and found > > that some of the modules didn't compile properly and weren't available > > to use. > > I'm guessing that you mean 1.3.5 in the last sentence. However, I > just compiled and installed the package (1.3.5) and as best as I can > tell, everything seemed to build. There were only a couple of minor > warnings during the building, and no messages during the install > other than the files being installed.
I've spent some time trying to get 1.3.7 working but get a "FATAL: Module ip_tables not found" when trying to use a MARK target. I've sent a request to the netfilter-devel list to try and get it working. > At this point, without something better to go on other than "found > that some of the modules didn't compile properly and weren't available > to use", it's going to be hard to break the package freeze. The modules weren't compiling because iptables was using a default include path of /usr/src/linux/include. This doesn't exist in LFS so needs to be specified when making iptables as follows: make PREFIX=/usr LIBDIR=/lib BINDIR=/sbin KERNEL_DIR=/usr/src/linux-2... If it's not specified the compilation of some modules are not even attempted due to missing headers. As an example, ipt_recent, (which uses extensions/.recent-test to check for the headers) is not built. > > I can provide tests and/or try to replicate if required - I am just > > writing this from memory. > > If you could just identify what didn't work, that would be great. > However, I don't really have any way of testing an IPTables > installation right now, so I'm hesitant to update the book this late > in the release cycle. At this point I'm wondering why the BLFS book states to only use the KERNEL_DIR variable if on a non-x86 architecture. I've tried 1.3.5, 1.3.6 and 1.3.7 and they all need the variable set, otherwise (as I found) some of the modules do not get built because of the missing headers. So unless there is a really good reason for not using the KERNEL_DIR variable, I would suggest that, at a minimum, the book is changed to state that KERNEL_DIR should always be set. There is my current problem with iptables 1.3.7 but it would also be nice to see the version upped to 1.3.6 which I am content works (with KERNEL_DIR set) Many thanks, Andy Beverley -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
