Can't enable tests on OS X because: Could not find librt

[ryandesign]

I'm trying to build the latest git version of ettercap on OS X 10.9 Mavericks with the -DENABLE_TESTS=ON cmake flag. I have check 0.9.10 installed with MacPorts. cmake fails with:

-- Found PkgConfig: /opt/local/bin/pkg-config (found version "0.28") 
-- checking for module 'libcheck'
--   package 'libcheck' not found
-- checking for module 'check'
--   found check, version 0.9.10
-- Found LibCheck: /opt/local/lib/libcheck.dylib  
CMake Error at cmake/Modules/EttercapLibCheck.cmake:231 (message):
  Could not find librt, which is required for linking tests.
Call Stack (most recent call first):
  CMakeLists.txt:104 (include)

As far as I can tell, librt is a thing that some Unix distributions have, but OS X does not. Is librt really needed to test ettercap? Version 0.8.0 did not check for librt.

[LocutusOfBorg]

I don't know, can you try to remove the FATAL_ERROR and see if it builds? I can push an exception, it is just for linking pourposes, maybe it isn't really needed

[LocutusOfBorg]

can you please try 417?

[ryandesign]

Thanks, with that patch, cmake and make work fine and make test says:

Running tests...
/opt/local/bin/ctest --force-new-ctest-process 
Test project /opt/local/var/macports/build/_Users_rschmidt_macports_dports_net_ettercap-ng/ettercap/work/build
    Start 1: test_ec_decode
1/1 Test #1: test_ec_decode ...................   Passed    0.01 sec

100% tests passed, 0 tests failed out of 1

Total Test time (real) =   0.02 sec

[LocutusOfBorg]

Ok thanks, so I'll merge shortly, can I close this?

[ryandesign]

Does the test output look ok? (Is there really only one test?) If so then yes we can close it.

[LocutusOfBorg]

tests for the moment are just "fake" :) we are working on a real libettercap library, after we will be able to make some more tests, for the moment travis and the other checks are still too much for our little forces :)

[ryandesign]

Are there some simple commands I could run to verify that ettercap is working? I've never used it before, don't know what it's supposed to do, and the manpage is large...

[LocutusOfBorg]

ettercap -G, than you can scan for hosts, enable or disable plugins, enable sniffing and arp spoofing

[ryandesign]

Ok, I reinstalled ettercap with gtk2 support. Running ettercap -G causes an X11 window to appear with the Ettercap logo and a menubar. Guessing, I selected "Unified sniffing" from the "Sniff" menu. It asked me to select a network interface. The only option in the drop-down menu is "D-Bus system bus". (I didn't know that was considered a network interface.) Pressing "OK" causes ettercap to exit with this error:

ERROR : 9, Bad file descriptor
[/opt/local/var/macports/build/_Users_rschmidt_macports_dports_net_ettercap-ng/ettercap/work/ettercap-65ae58622094ef104088bde87588722293b30fbc/src/ec_network.c:source_init:240]

 libnet_init: libnet_check_iface() ioctl: Device not configured

[LocutusOfBorg]

Of course it isn't a network interface... Sorry, you are right but did you run ettercap with sudo?

[ryandesign]

Ok, things make more sense now that I'm running with sudo. I'll add a note to the MacPorts package telling users to do that.

Now I'm able to select my en2 interface and I get this output in the window:

Listening on:
   en2 -> (my computer's MAC address, IP address, subnet mask, IPv6 address)

SSL dissection needs a valid 'redir_command_on' script in the etter.conf file
Privileges dropped to UID 65534 GID 65534...

  33 plugins
  42 protocol dissectors
  57 ports monitored
18663 mac vendor fingerprint
1766 tcp OS fingerprint
2182 known services

The menubar has also changed with various new options.

Does this indicate that Ettercap is working correctly? Is there anything else I should be testing?

[ryandesign]

I selected "Start Sniffing" from the "Start" menu and "Connections" from the "View" menu, and various connections showed up in the window. I guess it's working!

[LocutusOfBorg]

yes it is working :)

May I ask you a final question? can you please run this program http://pastebin.com/ehRLMT4t and report back here? (with and without sudo) if pcap lists some "bad" interfaces would be nice to just drop them by code

[ryandesign]

Sure:

$ clang test.c -L/opt/local/lib -lpcap
$ ./a.out
Interface: Name: dbus-system Description: D-Bus system bus
Interface: Name: dbus-session Description: D-Bus session bus
End!
$ sudo ./a.out
Password:
Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
Dynamic session lookup supported but failed: launchd did not provide a socket path, verify that org.freedesktop.dbus-session.plist is loaded!
Interface: Name:        en0 Empty Description
Interface: Name:    bridge0 Empty Description
Interface: Name:      utun0 Empty Description
Interface: Name:       p2p0 Empty Description
Interface: Name:        en2 Empty Description
Interface: Name:        en4 Empty Description
Interface: Name:        en5 Empty Description
Interface: Name:        lo0 Empty Description
End!
$

[LocutusOfBorg]

I think I fixed in https://github.com/Ettercap/ettercap/pull/417 can you please try to run without sudo?

and another question, do you think all your interfaces (the second run, with sudo) are good for usage? I mean, do they work? or some of them doesn't initialize because of the dbus error or similar?

sorry for bothering, but today we are doing a giant leap in mac os stuff!

[ryandesign]

Thanks, now when not using sudo, no interfaces are shown in the menu, so I can't get to the unexpected quit situation I had earlier. Good.

Note that dbus is not installed on OS X normally, but it is in MacPorts, and is a dependency of many other MacPorts packages, which is why I have it installed.

I'm not sure why my machine has so many network interfaces. Some of them may be leftover configurations; some of them might be the virtual interfaces VMware creates. I can run sudo ettercap -G and select any of them and start sniffing, but most of them don't show any connections, except en0 (my wireless network) and en2 (my gigabit ethernet).

[LocutusOfBorg]

Nice to hear your feedback, I'll wait for feedbacks from other developers and merge my pull request!

If you have many iterfaces even virtual is good, we can handle it, it shouldn't be a problem.

I'm still worrying about the dbus shown here, maybe I'll report to pcap people, just to let them know this!

thanks for your bug reports!

[guyharris]

I'm still worrying about the dbus shown here, maybe I'll report to pcap people, just to let them know this!

That's not a bug, it's a feature.

I suspect the ultimate problem is that libnet isn't doing a good job if you hand it, as the second argument to libnet_init(), a name that's not a regular network interface.

This will probably cause problems with ettercap on other platforms; for example, on Linux, libpcap can capture traffic on USB (meaning "traffic on the Universal Serial Bus", not "traffic on USB-attached network adapters"; it can also do that, but those are just regular network interfaces), Bluetooth devices, Netlink devices, etc.

If I look at the latest libnet_init.c on GitHub, I don't see a call to libnet_check_iface(), so perhaps a newer version of libnet might not have this problem.

[LocutusOfBorg]

@guyharris it is called on libnet_select_device() function, file https://github.com/sam-github/libnet/blob/master/libnet/src/libnet_if_addr.c

should I file a bug on libnet then?

btw thanks for your explanation so far, I wasn't aware of this feature! Seems to be pcap and libnet are more and more than my thoughts :)