I have been trying to get Etherape to work in OS X 10.6.6 for a couple days without success.
The host: a MacBook Pro2,1, with a 2.33 Intel Core 2 Duo CPU, 3GB RAM, and 160GB HD. OS 10.6.6 with the latest update
Third party software installed: both Fink and MacPorts, but Fink has been disabled (sudo chmod 0 /sw/bin/dbus-daemon, /sw/bin removed from $PATH), so only MacPorts is used for the moment.
I downloaded the etherape port from MacPorts, and tested it side by side with my own build. Both are on 0.9.10. All dependencies are from MacPorts. Their behavior is the same. Two visible differences from Etherape that I run on Linux (CentOS and Ubuntu):
(1) Neither are quick in responding to network events as their counterpart running on Linux (e.g. CentOS 5.5 and Ubuntu 10.04, both I use active. On Linux, even a ping to a remote host (e.g. www.google.com) generates visible node cicles and traffic graphs in Etherape, not on OS X. Although in the Prot. pane, traffic stats are updated periodically as anticipated.
(2) Even significant network traffic (e.g. downloading OpenOffice dmg file from http://www.openoffice.org/) doesn't generate visible node cicles and traffic graphs in the Etherape running in OS X. In Linux, the entire display probably would be filled completely by such an event. Yes, I do see IP addresses, but where are the nodes and graphs?
I am not sure why there are such "behavior" differences. The lack of visible traffic graphs and node cicles make Etherape much less useful in OS X IMHO.
Has anyone successfully get Etherape to work correctly in OS X 10.6.6? I would appreciate a hint as to how you get it going well.
Regards,
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Then, I launched another Terminal.app, and did some
ping www.google.com
In the Etherape display, I didn't see anything. In the first Terminal.app, I didn't see any further messages either, other than what I showed above. Note that I set the environment variable
APE_DEBUG=debug
already.
Thanks,
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I forgot to mention that when I tried to display etherape from a computer running Ubuntu 9.10 64bit on my MacBook Pro2,1, all traffic graphs showed up properly. Of course, that etherape is using the gnome-canvas library from the Ubuntu, not the OS X.
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Additional information. To test out whether libgnomecanvas is defective or not, I combined tcpdump with etherape as follows. Traffic graphs and nodes all showed up. So, I imagine the issue of etherape not showing these two types of objects probably lie somewhere else. Below is how I did my test:
IMHO, APE_DEBUG=debug did not work because your sudo is configured to not pass environment variables, so APE_DEBUG was set only in your (non root) session.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Replaying a file and reading a live interface differ only at capture level. Once a packet is acquired by EtherApe, its source doesn't matter.
Thus if piping from tcpdump works, perhaps EtherApe can't capture traffic on his own, or points to the wrong interface.
In your first post, you said:
> Although in the Prot. pane, traffic stats are updated periodically as anticipated.
I did interpret is as meaning that you got the Protocol/nodes panels filled, with several rows of data, but without visible statistics. Perhaps I misinterpreted what you said ?
If you truly get traffic statistics, perhaps links expire too fast to draw properly. Can you try increasing the diagram timeouts ?
With APE_DEBUG=info, when pausing the diagram, EtherApe should output something similar to
EtherApe-INFO: Diagram paused
EtherApe-INFO: Nodes: 13 (on canvas:13, shown: 13), Links: 12, Conversations: 0, names 13, protocols 10. Total Packets seen: 331 (in memory: 331, on list 1324). IP cache entries 13. Canvas objs: 63. Refreshed: 0 ms
The: "(on canvas:13, shown: 13)" refers to node drawn and shown. In this istance, 13 nodes should be visible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
IMHO, APE_DEBUG=debug did not work because your sudo is configured to not pass environment variables, so APE_DEBUG was set only in your (non root) session.
You are absolutely correct. I also realized I made a mistake in issuing the etherape command too. Thanks!
Thus if piping from tcpdump works, perhaps EtherApe can't capture traffic on his own, or points to the wrong interface.
What's odd is that I use the active interface (wired Ethernet connection en0) for all my tests. When launched by itself, etherape just shows nothing, despite the fact that I have an active ping session going all the time.
If you truly get traffic statistics, perhaps links expire too fast to draw properly. Can you try increasing the diagram timeouts ?
With APE_DEBUG=info, when pausing the diagram, EtherApe should output something similar to
EtherApe-INFO: Diagram paused
EtherApe-INFO: Nodes: 13 (on canvas:13, shown: 13), Links: 12, Conversations: 0, names 13, protocols 10. Total Packets
seen: 331 (in memory: 331, on list 1324). IP cache entries 13. Canvas objs: 63. Refreshed: 0 ms
This is what I got, regardless how I adjust the timing:
macbook-0:~root# export APE_DEBUG=infomacbook-0:~root# /usr/local/bin/etherape -m=ip(etherape:89226):EtherApe-WARNING**:Unrecognizedmode.Doetherape--helpforalistofmodesEtherApe-Message:Minimumdelaysetto0msEtherApe-Message:Maximumdelaysetto9223372036854775807msEtherApe-INFO:ReadingTCPandUDPservicesfrom/usr/local/etc/etherape/servicesEtherApe-INFO:DDPprotocolsnotsupportedinrtmp1/ddp# Routing Table Maintenance Protocol EtherApe-INFO:DDPprotocolsnotsupportedinnbp2/ddp# Name Binding Protocol EtherApe-INFO:DDPprotocolsnotsupportedinecho4/ddp# AppleTalk Echo Protocol EtherApe-INFO:DDPprotocolsnotsupportedinzip6/ddp# Zone Information Protocol EtherApe-INFO:get_interfaceresult:''EtherApe-INFO:Availableinterfacesforcapture:en0fw0en1lo0EtherApe-INFO:Livedeviceen0openedforcapture.pcap_fd:14EtherApe-INFO:LinktypeisEthernetEtherApe-INFO:DiagramstartedEtherApe-INFO:DiagrampausedEtherApe-INFO:Nodes:0(oncanvas:0,shown:0),Links:0,Conversations:0,names0,protocols0.TotalPacketsseen:0(inmemory:0,onlist0).IPcacheentries0.Canvasobjs:0.Refreshed:0ms
I am new to OS X (just started using it a couple of weeks ago, but I have been a long time UNIX/Linux user), and I must admit, I am puzzled. Any further hints as to where to look are appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I took a look of what I reported above, two more things caught my attention:
Despite the fact that etherap --help outputs the following:
Application options
-d, --diagram-only don't display any node text
identification
-r, --replay-file=<file to="" replay=""> replay packets from file
-f, --filter=<capture filter=""> set capture filter
-i, --interface=<interface name=""> set interface to listen to
-s, --stationary don't move nodes around
(deprecated)
-l, --node-limit=<number of="" nodes=""> limits nodes displayed
-m, --mode=<link|ip|tcp> mode of operation
-n, --numeric don't convert addresses to names
-q, --quiet Disable informational messages
--min-delay=<delay> minimum packet delay in ms for
reading capture files [cli only]
--max-delay=<delay> maximum packet delay in ms for
reading capture files [cli only]
--glade-file=<glade file=""> uses the named libglade file for
widgets</glade></delay></delay></link|ip|tcp></number></interface></capture></file>
I always got this
(etherape:89844): EtherApe-WARNING **: Unrecognized mode. Do etherape --help for a list of modes
Furthermore, despite that I have several active interface active, including a vmnet8 from a running VMWare Fusion's NAT engine, the etherape doesn't recognize this device at all. It only recognize the following:
The "unrecognized mode" message is a bug, but should be harmless, since IP is the default mode. Anyway you can select ip mode with "ip or ipv6" or by selecting from EtherApe menus.
The list of available interfaces comes from pcap, I don't know why it doesn't see your other devices.
Apparently there are other problems with pcap on OSX (or, most likely, with how EtherApe uses it): "Total Packets seen: 0" is pretty clear. No packets were captured.
Just in case, can you try capturing from other interfaces, with link mode, and even with a blank filter expression ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The "unrecognized mode" message is a bug, but should be harmless, since IP is the default mode. Anyway you can select ip mode with "ip or ipv6" or by selecting from EtherApe menus.
Thanks for the tip. I did all above.
The list of available interfaces comes from pcap, I don't know why it doesn't see your other devices.
Although I build the etherape binary myself, but all dependencies are from the MacPorts project. Perhaps the pcap is qustionable. When I build a library (in other platforms), I always do a test. But as far as I can see, people using Mac OS X rarely use network monitoring tools. The maintainer who updated the etherape port told me that he personally have never run etherape!
Apparently there are other problems with pcap on OSX (or, most likely, with how EtherApe uses it): "Total Packets seen: 0" is pretty clear. No packets were captured.
It seems obvious to me by now. Thanks for the info.
Just in case, can you try capturing from other interfaces, with link mode, and even with a blank filter expression ?
Just tried it, with a ping www.google.com session going. Saw absolutely nothing. Then I clicked on the button and got the following:
I used the WiFi interface this time (en1). One saving grace is that during the session, Etherape did see packets, quoted "Total Packets seen: 52384", so it's not a total loss. We just need to figure out how it can get such packets to be drawn one way or the other…
Many thanks for your help so far! Much appreciated!
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think your statement regarding libpcap to be the "culprit" very likely to be right.
Since I knew /usr/sbin/tcpdump that is provided by Apple works. So, I did the following experiments: [code]macbook-0:~ root# ifconfig |more
lo0: flags=8049<up,loopback,running,multicast> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<pointopoint,multicast> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500
ether 00:17:f2:c8:65:0e
inet6 fe80::217:f2ff:fec8:650e%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.99 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect (100baseTX <full-duplex,flow-control>)
status: active
fw0: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 2030
lladdr 00:19:e3:ff:fe:17:e1:68
media: autoselect <full-duplex>
status: inactive
en1: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500
ether 00:17:f2:ee:42:9c
inet6 fe80::217:f2ff:feee:429c%en1 prefixlen 64 scopeid 0x6
inet 192.168.1.106 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect
status: active
vboxnet0: flags=8842<broadcast,running,simplex,multicast> mtu 1500
ether 0a:00:27:00:00:00
vmnet1: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500
ether 00:50:56:c0:00:01
inet 172.16.126.1 netmask 0xffffff00 broadcast 172.16.126.255
vmnet8: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500
ether 00:50:56:c0:00:08
inet 192.168.105.1 netmask 0xffffff00 broadcast 192.168.105.255[/code]
Of all interfaces, I should be able to capture traffic on en0, en1, vmnet1, and vmnet8 (the last two are created by VMWare Fusion). This is indeed the case with tcpdump: [code]macbook-0:~ root# tcpdump -n -w en0
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C6 packets captured
6 packets received by filter
0 packets dropped by kernel
macbook-0:~ root# tcpdump -n -w en1
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C2 packets captured
3 packets received by filter
0 packets dropped by kernel
macbook-0:~ root# tcpdump -n -w vmnet1
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C5 packets captured
5 packets received by filter
0 packets dropped by kernel
macbook-0:~ root# tcpdump -n -w vmnet8
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C2 packets captured
4 packets received by filter
0 packets dropped by kernel[/code]
What version of libpcap that tcpdump depends on? [code]macbook-0:~ root# otool -L /usr/sbin/tcpdump
/usr/sbin/tcpdump:
/usr/lib/libpcap.A.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)[/code]
Now, how about the etherape that I built?
Testing it out usng [code]macbook-0:~ root# etherape -i en1
EtherApe-Message: Minimum delay set to 0 ms
EtherApe-Message: Maximum delay set to 9223372036854775807 ms
^Cmacbook-0:~ root# etherape -i en0
EtherApe-Message: Minimum delay set to 0 ms
EtherApe-Message: Maximum delay set to 9223372036854775807 ms[/code]
But as soon as I tried the following: [code]macbook-0:~ root# etherape -i vmnet1
EtherApe-Message: Minimum delay set to 0 ms
EtherApe-Message: Maximum delay set to 9223372036854775807 ms[/code]
A window popped up with a message "Error opening vmnet1: vmnet1: No such device exists (BIOCSTIF failed: Device not configured) - perhaps you need to be root?"
Note that I launched etherape as 'root'!
How about its libpcap dependency? [code]macbook-0:~ root# otool -L /usr/local/bin/etherape
/usr/local/bin/etherape: [...]
/opt/local/lib/libpcap.A.dylib (compatibility version 1.0.0, current version 1.1.1)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0) [/code]
It's the latest version, but from MacPorts. Based on what I provided above, do you spot anything fishy?
Thanks!
-- Zack</up,broadcast,smart,running,simplex,multicast></up,broadcast,smart,running,simplex,multicast></broadcast,running,simplex,multicast></up,broadcast,smart,running,simplex,multicast></full-duplex></up,broadcast,smart,running,simplex,multicast></full-duplex,flow-control></up,broadcast,smart,running,simplex,multicast></pointopoint,multicast></up,loopback,running,multicast>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did two more experiments, now focusing on libpcap
As I stated before, I used the libpcap that I got from MacPorts. I also know that OS X 10.6.6 comes with an older version 1.0.0, so
In /opt/local/lib, I moved the libpcap files to a subdirectory backup, then I downloaded the libpcap-1.1.1, built and installed it in /usr/local/lib, and then symlink files into /opt/local/lib
Fired up etherape, no packets captured, no graphs either (obviously).
In /opt/local/lib, rm the symlinks and symlinked the two OS X's libpcap files into it. Launched etherape again. Same results.
I am not sure why OS X is such a tough nut to crack. But if you have any ideas and/or suggestions, I am willing to do more tries.
Best,
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, apparently something was captured. Unfortunately it seems you have hit stop and that cleared all stats except the total packet seen counter.
The second run was paused, but no new packets was captured (total packet remained at 52384).
Can you try again ?
On the library: Unfortunately my knowledge of osx is nil, but tcpdump works and EtherApe doesn't. Perhaps if you could link EtherApe with the same libpcap of tcpdump we could have a bit more luck.
You could also try to build a tcpdump linked with MacPorts libpcap and see if it works correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I attempted to use the following simple code to help me figure out what's going on. The more I do, the more I agree with your assessment about the potential problem with libpcap. With the following simple test code
Justing wondering before I take a break in Ubuntu :) Have you ever seen anyone running Etherape in OS X successfully first hand? My google search so far has given me an impression that OS X users (including developers) are a bunch of people who rarely use tools dealing with low-level networking.
I use OS X because my boss wants me to get something done. I wish that I could stay away from this beast. All these translucent menu and eye-candies do not compensate the frustration that I have had.
What? No built-in software package management system? The moment that I discovered this, I felt like in an earthquake zone!
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Why, yes, three or four years ago there was a guy who did use etherApe on OSX :-)
Seriously, he helped me track down some bugs and actually run the program. He used Fink, if I recall correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With the help of a friend with a mac (an old Leopard based) I hope to have found the problem. EtherApe when capturing live uses pcap_fileno to obtain a file descriptor and registering a GDK wait event.
This event should be fired when the file descriptor becomes ready to read, but for some reason on OSX is never called. I don't know if is a problem of gdk, pcap, osx or whatever, but the timeout-based mechanism used for replaying from file works.
I'll try to concoct a patch for you to try.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't know if is a problem of gdk, pcap, osx or whatever, but the timeout-based mechanism used for replaying from file works.
I'll try to concoct a patch for you to try.
As soon as you post it, I will apply the patch to 0.9.10 source tree, rebuild and test it out. Two most obvious issues that I have observed so far:
0. Not all interfaces are shown in the Etherape's Capture -> Interfaces
1. Replay of files or data piped to Etherape (say from tcpdump -n -w -) works, but not direct capturing
Look forward to testing out your patch!
Best Regards,
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
cd ~/work; cp osx.patch etherape-0.9.10; cd etherape-0.9.10; patch -p1 < osx.patch
Immediately after the launch of etherape, both nodes and lines connecting them appeared. ping www.google.com showed some graphs too right away. Downloading a package from OpenOffice filled the display completely until I adjusted both the node circle size and link width.
The issue with some interfaces not shown is still present. Only en0, fw1, en1, and lo0 are present. Other interfaces are not shown. But lets take care of the traffic graphs first.
I am having a hectic day but I wish to give your patch a more extensive test. I will do a more detailed test report in my evening
Thanks and Best,
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As promised, I have done more extensive testing of your patch in my evening. IMHO the patch has made etherape_ much usable_ in OS X 10.6.6. It still emits odd warnings both in popup windows and in the terminal in which I launched the utility. But in terms of displaying protocol traffic, drawing nodes, links etc. It works mostly as anticipated.
As far as why the Capture -> Interfaces doesn't show the two VMWare Fusion related interfaces: vmnet1 and vmnet8, after a bit of investigation I realized that it's a VMWare Fusion issue. Please see http://communities.vmware.com/message/1145924. So, this is NOT an Etherape bug, but a VMWare bug.
Personally, whenever I meet any VMWare Fusion user, I always encourage the person to switch to the free but much better VirtualBox anyways. So, this is not a loss.
Many thanks for the quick fix. It's really a feat that without a Mac handy, you could come up a working patch! Hats off to you!
Best,
Zack
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me make a supplementary post for the convenience of my fellow UNIX/Linux users who are forced to use this odd OS X.
In case you are (again) forced to use this nice looking but broken VMWare Fusion, there is one way to capture its vmnet1 and vmnet8 traffic. Use this (horror)
I have been trying to get Etherape to work in OS X 10.6.6 for a couple days without success.
The host: a MacBook Pro2,1, with a 2.33 Intel Core 2 Duo CPU, 3GB RAM, and 160GB HD. OS 10.6.6 with the latest update
Third party software installed: both Fink and MacPorts, but Fink has been disabled (sudo chmod 0 /sw/bin/dbus-daemon, /sw/bin removed from $PATH), so only MacPorts is used for the moment.
I downloaded the etherape port from MacPorts, and tested it side by side with my own build. Both are on 0.9.10. All dependencies are from MacPorts. Their behavior is the same. Two visible differences from Etherape that I run on Linux (CentOS and Ubuntu):
(1) Neither are quick in responding to network events as their counterpart running on Linux (e.g. CentOS 5.5 and Ubuntu 10.04, both I use active. On Linux, even a ping to a remote host (e.g. www.google.com) generates visible node cicles and traffic graphs in Etherape, not on OS X. Although in the Prot. pane, traffic stats are updated periodically as anticipated.
(2) Even significant network traffic (e.g. downloading OpenOffice dmg file from http://www.openoffice.org/) doesn't generate visible node cicles and traffic graphs in the Etherape running in OS X. In Linux, the entire display probably would be filled completely by such an event. Yes, I do see IP addresses, but where are the nodes and graphs?
I am not sure why there are such "behavior" differences. The lack of visible traffic graphs and node cicles make Etherape much less useful in OS X IMHO.
Has anyone successfully get Etherape to work correctly in OS X 10.6.6? I would appreciate a hint as to how you get it going well.
Regards,
I got EtherApe 0.9.10 working on OS X 10.10 (Yosemite) without fairly simply by way of MacPorts:
Running it with sudo etherape is not ideal, though, yielding the following error message (para) because sudo cannot access the current user's D-Bus:
Instead I launch EtherApe with:
Note the "-l" switch on tcpdump, which enables line buffering on STDOUT. EtherApe will just sit there with no graph updates if you leave it out.
Graphs are drawn with GnomeCanvas. Perhaps it doesn't work correctly on osx ?
If started from a shell, EtherApe outputs warnings ?
Graphs are drawn with GnomeCanvas. Perhaps it doesn't work correctly on osx ?
If started from a shell, EtherApe outputs warnings ?
Here is what I have done in a Terminal.app:
Then, I launched another Terminal.app, and did some
In the Etherape display, I didn't see anything. In the first Terminal.app, I didn't see any further messages either, other than what I showed above. Note that I set the environment variable
already.
Thanks,
I forgot to mention that when I tried to display etherape from a computer running Ubuntu 9.10 64bit on my MacBook Pro2,1, all traffic graphs showed up properly. Of course, that etherape is using the gnome-canvas library from the Ubuntu, not the OS X.
Additional information. To test out whether libgnomecanvas is defective or not, I combined tcpdump with etherape as follows. Traffic graphs and nodes all showed up. So, I imagine the issue of etherape not showing these two types of objects probably lie somewhere else. Below is how I did my test:
IMHO, APE_DEBUG=debug did not work because your sudo is configured to not pass environment variables, so APE_DEBUG was set only in your (non root) session.
Replaying a file and reading a live interface differ only at capture level. Once a packet is acquired by EtherApe, its source doesn't matter.
Thus if piping from tcpdump works, perhaps EtherApe can't capture traffic on his own, or points to the wrong interface.
In your first post, you said:
> Although in the Prot. pane, traffic stats are updated periodically as anticipated.
I did interpret is as meaning that you got the Protocol/nodes panels filled, with several rows of data, but without visible statistics. Perhaps I misinterpreted what you said ?
If you truly get traffic statistics, perhaps links expire too fast to draw properly. Can you try increasing the diagram timeouts ?
With APE_DEBUG=info, when pausing the diagram, EtherApe should output something similar to
EtherApe-INFO: Diagram paused
EtherApe-INFO: Nodes: 13 (on canvas:13, shown: 13), Links: 12, Conversations: 0, names 13, protocols 10. Total Packets seen: 331 (in memory: 331, on list 1324). IP cache entries 13. Canvas objs: 63. Refreshed: 0 ms
The: "(on canvas:13, shown: 13)" refers to node drawn and shown. In this istance, 13 nodes should be visible.
You are absolutely correct. I also realized I made a mistake in issuing the etherape command too. Thanks!
What's odd is that I use the active interface (wired Ethernet connection en0) for all my tests. When launched by itself, etherape just shows nothing, despite the fact that I have an active ping session going all the time.
EtherApe-INFO: Diagram paused
EtherApe-INFO: Nodes: 13 (on canvas:13, shown: 13), Links: 12, Conversations: 0, names 13, protocols 10. Total Packets
seen: 331 (in memory: 331, on list 1324). IP cache entries 13. Canvas objs: 63. Refreshed: 0 ms
This is what I got, regardless how I adjust the timing:
I am new to OS X (just started using it a couple of weeks ago, but I have been a long time UNIX/Linux user), and I must admit, I am puzzled. Any further hints as to where to look are appreciated.
I took a look of what I reported above, two more things caught my attention:
Despite the fact that etherap --help outputs the following:
Application options
-d, --diagram-only don't display any node text
identification
-r, --replay-file=<file to="" replay=""> replay packets from file
-f, --filter=<capture filter=""> set capture filter
-i, --interface=<interface name=""> set interface to listen to
-s, --stationary don't move nodes around
(deprecated)
-l, --node-limit=<number of="" nodes=""> limits nodes displayed
-m, --mode=<link|ip|tcp> mode of operation
-n, --numeric don't convert addresses to names
-q, --quiet Disable informational messages
--min-delay=<delay> minimum packet delay in ms for
reading capture files [cli only]
--max-delay=<delay> maximum packet delay in ms for
reading capture files [cli only]
--glade-file=<glade file=""> uses the named libglade file for
widgets</glade></delay></delay></link|ip|tcp></number></interface></capture></file>
I always got this
Furthermore, despite that I have several active interface active, including a vmnet8 from a running VMWare Fusion's NAT engine, the etherape doesn't recognize this device at all. It only recognize the following:
I hope these two provide some more clues?
The "unrecognized mode" message is a bug, but should be harmless, since IP is the default mode. Anyway you can select ip mode with "ip or ipv6" or by selecting from EtherApe menus.
The list of available interfaces comes from pcap, I don't know why it doesn't see your other devices.
Apparently there are other problems with pcap on OSX (or, most likely, with how EtherApe uses it): "Total Packets seen: 0" is pretty clear. No packets were captured.
Just in case, can you try capturing from other interfaces, with link mode, and even with a blank filter expression ?
The "unrecognized mode" message is a bug, but should be harmless, since IP is the default mode. Anyway you can select ip mode with "ip or ipv6" or by selecting from EtherApe menus.
Thanks for the tip. I did all above.
Although I build the etherape binary myself, but all dependencies are from the MacPorts project. Perhaps the pcap is qustionable. When I build a library (in other platforms), I always do a test. But as far as I can see, people using Mac OS X rarely use network monitoring tools. The maintainer who updated the etherape port told me that he personally have never run etherape!
It seems obvious to me by now. Thanks for the info.
Just tried it, with a ping www.google.com session going. Saw absolutely nothing. Then I clicked on the button and got the following:
I used the WiFi interface this time (en1). One saving grace is that during the session, Etherape did see packets, quoted "Total Packets seen: 52384", so it's not a total loss. We just need to figure out how it can get such packets to be drawn one way or the other…
Many thanks for your help so far! Much appreciated!
I think your statement regarding libpcap to be the "culprit" very likely to be right.
Since I knew /usr/sbin/tcpdump that is provided by Apple works. So, I did the following experiments:
[code]macbook-0:~ root# ifconfig |more
lo0: flags=8049<up,loopback,running,multicast> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<pointopoint,multicast> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500
ether 00:17:f2:c8:65:0e
inet6 fe80::217:f2ff:fec8:650e%en0 prefixlen 64 scopeid 0x4
inet 192.168.1.99 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect (100baseTX <full-duplex,flow-control>)
status: active
fw0: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 2030
lladdr 00:19:e3:ff:fe:17:e1:68
media: autoselect <full-duplex>
status: inactive
en1: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500
ether 00:17:f2:ee:42:9c
inet6 fe80::217:f2ff:feee:429c%en1 prefixlen 64 scopeid 0x6
inet 192.168.1.106 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect
status: active
vboxnet0: flags=8842<broadcast,running,simplex,multicast> mtu 1500
ether 0a:00:27:00:00:00
vmnet1: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500
ether 00:50:56:c0:00:01
inet 172.16.126.1 netmask 0xffffff00 broadcast 172.16.126.255
vmnet8: flags=8863<up,broadcast,smart,running,simplex,multicast> mtu 1500
ether 00:50:56:c0:00:08
inet 192.168.105.1 netmask 0xffffff00 broadcast 192.168.105.255[/code]
Of all interfaces, I should be able to capture traffic on en0, en1, vmnet1, and vmnet8 (the last two are created by VMWare Fusion). This is indeed the case with tcpdump:
[code]macbook-0:~ root# tcpdump -n -w en0
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C6 packets captured
6 packets received by filter
0 packets dropped by kernel
macbook-0:~ root# tcpdump -n -w en1
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C2 packets captured
3 packets received by filter
0 packets dropped by kernel
macbook-0:~ root# tcpdump -n -w vmnet1
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C5 packets captured
5 packets received by filter
0 packets dropped by kernel
macbook-0:~ root# tcpdump -n -w vmnet8
tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C2 packets captured
4 packets received by filter
0 packets dropped by kernel[/code]
What version of libpcap that tcpdump depends on?
[code]macbook-0:~ root# otool -L /usr/sbin/tcpdump
/usr/sbin/tcpdump:
/usr/lib/libpcap.A.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 0.9.8)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)[/code]
Now, how about the etherape that I built?
Testing it out usng
[code]macbook-0:~ root# etherape -i en1
EtherApe-Message: Minimum delay set to 0 ms
EtherApe-Message: Maximum delay set to 9223372036854775807 ms
^Cmacbook-0:~ root# etherape -i en0
EtherApe-Message: Minimum delay set to 0 ms
EtherApe-Message: Maximum delay set to 9223372036854775807 ms[/code]
But as soon as I tried the following:
[code]macbook-0:~ root# etherape -i vmnet1
EtherApe-Message: Minimum delay set to 0 ms
EtherApe-Message: Maximum delay set to 9223372036854775807 ms[/code]
A window popped up with a message "Error opening vmnet1: vmnet1: No such device exists (BIOCSTIF failed: Device not configured) - perhaps you need to be root?"
Note that I launched etherape as 'root'!
How about its libpcap dependency?
[code]macbook-0:~ root# otool -L /usr/local/bin/etherape
/usr/local/bin/etherape:
[...]
/opt/local/lib/libpcap.A.dylib (compatibility version 1.0.0, current version 1.1.1)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 152.0.0)
[/code]
It's the latest version, but from MacPorts. Based on what I provided above, do you spot anything fishy?
Thanks!
-- Zack</up,broadcast,smart,running,simplex,multicast></up,broadcast,smart,running,simplex,multicast></broadcast,running,simplex,multicast></up,broadcast,smart,running,simplex,multicast></full-duplex></up,broadcast,smart,running,simplex,multicast></full-duplex,flow-control></up,broadcast,smart,running,simplex,multicast></pointopoint,multicast></up,loopback,running,multicast>
Hi Riccardo,
I did two more experiments, now focusing on libpcap
As I stated before, I used the libpcap that I got from MacPorts. I also know that OS X 10.6.6 comes with an older version 1.0.0, so
In /opt/local/lib, I moved the libpcap files to a subdirectory backup, then I downloaded the libpcap-1.1.1, built and installed it in /usr/local/lib, and then symlink files into /opt/local/lib
Fired up etherape, no packets captured, no graphs either (obviously).
In /opt/local/lib, rm the symlinks and symlinked the two OS X's libpcap files into it. Launched etherape again. Same results.
I am not sure why OS X is such a tough nut to crack. But if you have any ideas and/or suggestions, I am willing to do more tries.
Best,
Ok, apparently something was captured. Unfortunately it seems you have hit stop and that cleared all stats except the total packet seen counter.
The second run was paused, but no new packets was captured (total packet remained at 52384).
Can you try again ?
On the library: Unfortunately my knowledge of osx is nil, but tcpdump works and EtherApe doesn't. Perhaps if you could link EtherApe with the same libpcap of tcpdump we could have a bit more luck.
You could also try to build a tcpdump linked with MacPorts libpcap and see if it works correctly.
Hi Riccardo,
I attempted to use the following simple code to help me figure out what's going on. The more I do, the more I agree with your assessment about the potential problem with libpcap. With the following simple test code
Opening en0 is not a problem:
Commenting out the en0 line, uncommenting the line with vmnet8, and recompiling, but opening vmnet8 failed:
Something is fishy about OS X. I need to escape to a Ubuntu for a while for relief :)
Hi Riccardo,
Justing wondering before I take a break in Ubuntu :) Have you ever seen anyone running Etherape in OS X successfully first hand? My google search so far has given me an impression that OS X users (including developers) are a bunch of people who rarely use tools dealing with low-level networking.
I use OS X because my boss wants me to get something done. I wish that I could stay away from this beast. All these translucent menu and eye-candies do not compensate the frustration that I have had.
What? No built-in software package management system? The moment that I discovered this, I felt like in an earthquake zone!
Why, yes, three or four years ago there was a guy who did use etherApe on OSX :-)
Seriously, he helped me track down some bugs and actually run the program. He used Fink, if I recall correctly.
Hi Riccardo,
Three or four years ago? That's like OS X 10.3 or 4. 10.6 differs from Tiger and Panther quite much already.
Fink? It won't even cut it. MacPorts at least has a decent coverage, but Fink is only up to 10.5. For 10.6, you need to compile the installer itself
I have a very dim view about OS X … I am sorry. It's not a OS for real IT people.
Thanks for your valuable hints/tips so far. Have a great weekend,
With the help of a friend with a mac (an old Leopard based) I hope to have found the problem. EtherApe when capturing live uses pcap_fileno to obtain a file descriptor and registering a GDK wait event.
This event should be fired when the file descriptor becomes ready to read, but for some reason on OSX is never called. I don't know if is a problem of gdk, pcap, osx or whatever, but the timeout-based mechanism used for replaying from file works.
I'll try to concoct a patch for you to try.
Hi Riccardo,
As soon as you post it, I will apply the patch to 0.9.10 source tree, rebuild and test it out. Two most obvious issues that I have observed so far:
0. Not all interfaces are shown in the Etherape's Capture -> Interfaces
1. Replay of files or data piped to Etherape (say from tcpdump -n -w -) works, but not direct capturing
Look forward to testing out your patch!
Best Regards,
I've opened bug 3214146 with a tentative patch.
Can you try it, please ?
Hi Riccardo,
The patch seems to work.
Immediately after the launch of etherape, both nodes and lines connecting them appeared. ping www.google.com showed some graphs too right away. Downloading a package from OpenOffice filled the display completely until I adjusted both the node circle size and link width.
The issue with some interfaces not shown is still present. Only en0, fw1, en1, and lo0 are present. Other interfaces are not shown. But lets take care of the traffic graphs first.
I am having a hectic day but I wish to give your patch a more extensive test. I will do a more detailed test report in my evening
Thanks and Best,
Hi Riccardo,
As promised, I have done more extensive testing of your patch in my evening. IMHO the patch has made etherape_ much usable_ in OS X 10.6.6. It still emits odd warnings both in popup windows and in the terminal in which I launched the utility. But in terms of displaying protocol traffic, drawing nodes, links etc. It works mostly as anticipated.
As far as why the Capture -> Interfaces doesn't show the two VMWare Fusion related interfaces: vmnet1 and vmnet8, after a bit of investigation I realized that it's a VMWare Fusion issue. Please see http://communities.vmware.com/message/1145924. So, this is NOT an Etherape bug, but a VMWare bug.
Personally, whenever I meet any VMWare Fusion user, I always encourage the person to switch to the free but much better VirtualBox anyways. So, this is not a loss.
Many thanks for the quick fix. It's really a feat that without a Mac handy, you could come up a working patch! Hats off to you!
Best,
Let me make a supplementary post for the convenience of my fellow UNIX/Linux users who are forced to use this odd OS X.
In case you are (again) forced to use this nice looking but broken VMWare Fusion, there is one way to capture its vmnet1 and vmnet8 traffic. Use this (horror)
You can pipe this monster's output to etherape for example.
Grrr…. why anyone wants to use OS X is beyond me :(