Bug 646162 - Problem with Passive DNS support
Problem with Passive DNS support
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ettercap (Show other bugs)
13
Unspecified Linux
low Severity high
: ---
: ---
Assigned To: Jon Ciesla
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-24 12:02 EDT by contact
Modified: 2010-11-13 17:03 EST (History)
1 user (show)

See Also:
Fixed In Version: ettercap-0.7.3-36.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-13 17:01:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
acinclude.m4 patch (1.38 KB, patch)
2010-10-24 12:04 EDT, contact
no flags Details | Diff
configure patch (981.68 KB, patch)
2010-10-24 12:05 EDT, contact
no flags Details | Diff
acinclude.m4 patch - new revision (1.27 KB, patch)
2010-10-27 11:51 EDT, contact
no flags Details | Diff
Correction to the sed bug on rawhide (482 bytes, patch)
2010-10-28 11:07 EDT, contact
no flags Details | Diff
New version of the patch to correct sed/grep regexp bug. (466 bytes, application/octet-stream)
2010-10-28 12:35 EDT, contact
no flags Details

  None (edit)
Description contact 2010-10-24 12:02:18 EDT
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.
Comment 1 contact 2010-10-24 12:04:27 EDT
Created attachment 455351 [details]
acinclude.m4 patch
Comment 2 contact 2010-10-24 12:05:30 EDT
Created attachment 455352 [details]
configure patch
Comment 3 Jon Ciesla 2010-10-26 16:02:50 EDT
Will it work with just the acinclude.m4 patch?  I'd rather do that, just for transparency.
Comment 4 contact 2010-10-26 16:16:24 EDT
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…
Comment 5 Jon Ciesla 2010-10-27 08:57:59 EDT
I have no problem re-running autoconf.  I should have specified that.  Will .m4 and re-running autoconf do the trick?
Comment 6 contact 2010-10-27 11:50:00 EDT
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.
Comment 7 contact 2010-10-27 11:51:43 EDT
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.
Comment 8 Jon Ciesla 2010-10-27 13:32:38 EDT
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/
Comment 9 contact 2010-10-27 15:06:28 EDT
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.
Comment 10 Jon Ciesla 2010-10-27 15:23:21 EDT
Ok, great I'll get this out there.  Thanks!

I agree it should be kept.  I just wish there was still an upstream. :(
Comment 11 Jon Ciesla 2010-10-28 10:29:11 EDT
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
Comment 12 contact 2010-10-28 11:06:58 EDT
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.
Comment 13 contact 2010-10-28 11:07:35 EDT
Created attachment 456272 [details]
Correction to the sed bug on rawhide
Comment 14 Jon Ciesla 2010-10-28 11:29:53 EDT
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?
Comment 15 contact 2010-10-28 12:34:38 EDT
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.
Comment 16 contact 2010-10-28 12:35:38 EDT
Created attachment 456283 [details]
New version of the patch to correct sed/grep regexp bug.
Comment 17 Jon Ciesla 2010-10-28 13:36:58 EDT
Ah!  That worked on both, thanks.  I'll get builds out for 13 and 14.  Thanks for your help!
Comment 18 Fedora Update System 2010-10-28 13:55:55 EDT
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
Comment 19 Fedora Update System 2010-10-28 13:56:02 EDT
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
Comment 20 contact 2010-10-28 14:00:05 EDT
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 :)
Comment 21 Fedora Update System 2010-10-29 16:40:01 EDT
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
Comment 22 Fedora Update System 2010-11-13 17:01:37 EST
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.
Comment 23 Fedora Update System 2010-11-13 17:03:14 EST
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.

Note You need to log in before you can comment on or make changes to this bug.