VisualSniff can be found on the App Store!
Known Issues/Troubleshooting
I’m running Snow Leopard and the application just crashes!
This crash is, unfortunately, entirely our fault. The 1.02 version that was pushed up to the App Store for review on December 13 resolves this issue. We had inadvertently left a Lion constraint requirement enabled while compiling the 1.01 version.I’ve upgraded to version 1.01 and I can’t select an interface anymore!
After doing a significant amount of research we have determined that the new Mac App Store requirement to use entitlements as of March 2012 is incompatible with VisualSniff in its currents state. As of Tuesday, December 13 we have pushed a new version (1.02) up to the App Store to remove the entitlements configuration. This should restore VisualSniff to working order for live data capture.
The 1.02 version also supports a requested feature: Host decay. Via a slider available from the Preferences panel you can control how long hosts will remain in the display after they have gone silent. The decay value can be set to a value between 5 and 500 seconds. The default setting is 35 seconds.
There are no interfaces available/I can’t select the live capture Start button!
If you are experiencing a problem where no interfaces show up in the drop-down box, please refer to this video and associated script to resolve the issue.
Features In Development
- Color code local host in live capture
- Allow the user to restart a packet replay
- Statistics sidebar tracking information on hosts, protocols, sizes, etc.
- Statistics view to support “top talkers” and “top protocols”
- Ability to toggle rotation on/off
- Ability to control rotational speed
- Metaphor to more easily differentiate remote hosts versus local hosts
- User configurable host and conversation decay (completed)
- Inactive hosts to decay from the map (completed)
What Am I Seeing??
As you may know,, when your computer tries to talk to other computers it uses networking protocols to do so. More specifically, pretty much everything these days relies on some form of TCP/IP. You may occasionally find networks where other higher level protocols are running, but this has become somewhat rare.
Within VisualSniff, the TCP/IP protocol suite is represented by the outer red ring. Any time VisualSniff identifies a new TCP/IP host, a circle with a label will appear to indicate this. One of the hosts in that ring will be your own host. If you'd like to identify which one is you, the simplest way to do this is to open the network control panel and check the address assigned to whichever interface you're currently using. You can then locate that host in the ring. I do have plans to color-code that host so that you don't need to go to this effort.
The inner blue ring represents Ethernet hosts. While TCP/IP is the inter-networking protocol that we use today (and has become the base protocol for the Internet over the last thirty-five years or so), a "link layer" protocol like Ethernet is what's used on a LAN. Why? The simplest reason is that the IP addresses can be used to get you into the neighborhood (which LAN is a host on) but within the LAN itself, the physical adapter addresses (on most networks, Ethernet addresses) are what are really used between the hosts. Don't get me wrong, the IP addresses are still used, but each host on the LAN maintains a mapping of Ethernet (or MAC addresses) to IP addresses for all of the local hosts that it talks to. Any time a new Ethernet host is detected, it will be added to the blue ring. In fact, every TCP/IP packet that is sent from your host rides along inside of an Ethernet packet.
Between the individual hosts (both Ethernet and IP) you will see lines appear, grow, shrink, disappear, etc. Every network packet will have a source host and a destination host. For example, if I try to connect to Google, a series of packets will be exchanged between my host and Google. At a deeper level, though, here's what's really happening, all of which can be seen represented in VisualSniff:
My computer first wishes to perform a DNS lookup. To do so, it begins by sending an Ethernet Broadcast packet to locate either the DNS server itself (if it's local) or the default gateway (router). (an ARP WHO-HAS packet)
Either the DNS server or the default gateway will send an Ethernet response to my host, giving it the Ethernet -> IP mapping. (an ARP IS-AT packet).
The DNS query is now sent to the DNS server.
The DNS server sends back a response.
My computer now attempts to connect to Google with a TCP SYN packet. This may require an ARP lookup, it may not. This will depend on whether or not my host already knows the Ethernet address of the router.
Google responds (hopefully!) with a TCP SYN-ACK packet.
etc.
Whenever a packet is sent between two hosts, there will always be Ethernet source and destination addresses. Based on these, VisualSniff will begin to track that conversation and uses the thickness of the line to indicate the number of packets passing by. The thicker the line, the more packets that are flowing. If you look carefully, you will sometimes see that it's not actually a line but a triangle. The thicker base of the triangle indicates the source for the packets. It is entirely possible to have a host sending more packets and the receiver sending back fewer packets.
The diameter of the host will also expand based on the number and frequency of packets being sent. The more there are, the bigger the host grows.
The lines between the TCP/IP hosts represent exactly the same thing as the lines between the Ethernet hosts, simply for the IP protocol rather than the link layer.