Currently, the Passive DNS support is not enabled on the ettercap Fedora build, because of a (non-fedora-specific) bug in the configure script (and on the acinclude.m4 file, which is used to generate the configure script): it checks the dn_expand function (included in resolv.h, part of libc), but on the resolv.h file, it's named __dn_expand and a there is a "#define dn_expand __dn_expand" so it's used under the name "dn_expand" on the source code of ettercap but on the resolv lib, it's called __dn_expand. The problem is that with the way the configure script (generated by autoconf) checks if dn_expand is present on the resolv lib (making a fake definition of the dn_expand function, calling it on main(), and then compiling with the -lresolv flag to see if there is no error), configure has an error and so does not consider lib resolv as an appropriated lib for the dn_expand function, whereas it's the appropriated lib. My solution is to tell configure to check the dn_expand function, and if there is an error (that's the common case), to check the __dn_expand function. I made a patch for the acinclude.m4 and a patch for the configure script. Both are attached to this bug report, on the tar.gz file. You can also find them on: <http://ftp.paulk.fr/ettercap/>. If you just include and apply the acinclude.m4 patch, please remind to run "autoconf" before launching configure. The Passive DNS support is needed to make the dns_spoof plugin work, so I think it's a quite important problem.
Created attachment 455351 [details] acinclude.m4 patch
Created attachment 455352 [details] configure patch
Will it work with just the acinclude.m4 patch? I'd rather do that, just for transparency.
Since the acinclude.m4 file is used to generate the configure script, if you don't run "autoconf", it will be totally useless to apply the patch and the bug will still be there. You can apply both of the patchs, so you won't have to run "autoconf" before you run configure. I understand that it's a bit unclean to apply a patch (the configure one) which is almost as big as the generated file or to run an unsual program (autoconf) with a smaller patch while creating the RPM. I think that the better solution would be to apply my patch directly on a new version, provided by upstream, but as I saw, upstream seams dead…
I have no problem re-running autoconf. I should have specified that. Will .m4 and re-running autoconf do the trick?
Yes, if you apply the .m4 patch and run "autoconf" (with "BuildRequires: autoconf") on the spec file, it'll enable Passive DNS Support. If you have trouble applying the patch, please try the latest I put here (ettercap-NG-0.7.3-resolv.patch). It will just patch acinclude.m4.
Created attachment 456015 [details] acinclude.m4 patch - new revision There is nothing new about this patch, juste something modified about the path of the file to patch.
Perfect. I'd just prefer to apply fewer lines of patch, so people can more easily see what's going on. It's a shame upstream is basically dead. I'd orphan and retire the package, but it's still in use. Does this look good? http://zanoni.jcomserv.net/fedora/ettercap/
It seems to be good. Maybe you should add "BuildRequires: autoconf" on the SPEC file since it's not a traditional tool that is used to compile (but used directly by the programmer). I don't think it's a good idea to remove this package from fedora: I think it's quite usefull and even if there was no new version since years, it's still a powerfull tool and it does what it's supposed to do.
Ok, great I'll get this out there. Thanks! I agree it should be kept. I just wish there was still an upstream. :(
It builds wonderfully on F-13, but not in rawhide. I've tried adding libtoolize --copy --force as suggested, but that fails. http://koji.fedoraproject.org/koji/getfile?taskID=2561584&name=build.log
The bug seems to come from the new version of GNU grep, wich uses [:space:] instead of [[:space:]] and so is not able to get the ltmain.sh version and cause this bug. Try with the latest patch I put here. Note that it will probably cause a bug if you apply it on a fedora version older than rawhide.
Created attachment 456272 [details] Correction to the sed bug on rawhide
Dies on F-13 as advertized, but also dies in rawhide, with and without libtoolize. http://koji.fedoraproject.org/koji/getfile?taskID=2561655&name=build.log Am I calling liboolize in the right place?
You absolutely don't need to run libtoolize. The only problem is that the regexp to catch the ltmain.sh VERSION is not correct and so it tells that the libtool.m4 and ltmain.sh versions are not compatibles whereas it's not the case : ltmain.sh is also 1.5.18. I uploaded another patch, wihich is less clean but should work (on both f-13 and rawhide). Note that it's also needed to run "autoconf" for this patch.
Created attachment 456283 [details] New version of the patch to correct sed/grep regexp bug.
Ah! That worked on both, thanks. I'll get builds out for 13 and 14. Thanks for your help!
ettercap-0.7.3-36.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/ettercap-0.7.3-36.fc14
ettercap-0.7.3-36.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/ettercap-0.7.3-36.fc13
You're welcome :) I saw that you merged my 2 patch into one only patch, but the latest I uploaded (to correct the sed/grep bug) does not concern the Passive DNS support and I guess that the problem may append if you try to compile ettercap 0.73-3.5 on f-15. Maybe it would be better to make 2 separate patchs, but that's you to decide :)
ettercap-0.7.3-36.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update ettercap'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/ettercap-0.7.3-36.fc14
ettercap-0.7.3-36.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
ettercap-0.7.3-36.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.