You need to hit return after entering search text for it to trigger, which is not at all intuitive. And when you do a search, it just seems to highlight the matching text in the output. The release notes speak of "filters", which I had assumed might actually let one filter based on TCP/IP parameters however, these "filters" appear to just be this Search box. Not in this case I had to manually select and delete the actual text "Search" before entering my search. Normally, when one clicks in a Search box, the initial placeholder "Search" text goes away. Also, the port numbers are not listed for these ports, and the port names do not all match the port names in the output (those being ones generated by tcpdump doing a service name lookup.) You also cannot specify source or destination ports, which the help does not mention tcpdump supports these options, but this program just uses the option that lets either the source or destination port match. The release notes mention filtering however, you can only filter by port, and you're limited to the small number of included ports there's no way to specify them on your own. I also noted multiple dead tcpdump processes. I experienced some weird behavior, including beachballing, as well as not seeing any output until I stopped the program. This is potentially quite cumbersome if one wants to tweak options and run many tcpdumps.
#GUI FOR PACKET PEEPER PASSWORD#
If I stop and restart the monitor, I'm asked for my password again. On first enabling the monitor, I'm asked for my password. Even so, performance is still extremely slow (especially while initially capturing.) I suspect that the program is doing a read from tcpdump such that enough data has to be queued up before it's sent over the pipe. Root 6198 0.0 0.1 2440168 4816 ? S 4:48PM 0:00.10 /usr/sbin/tcpdump -i en1 -vĬalling tcpdump in this fashion forces all addresses to be resolved, and that make tcpdump stall while waiting for anything to be resolved. Part of this I traced back by looking at the tcpdump command being called: (A little globe to start, an "x" to stop which makes sense, and what appears to be a fish to clear the buffer.) Once I did start the monitor, performance was EXTREMELY slow. My first impression on opening this program is confusion with the UI you have to hover over the buttons at the top to see the help text and figure out what they do.
#GUI FOR PACKET PEEPER MAC#
(Other commercial Mac networking tools, which include wrappers for tcpdump as well as other network tools, cost more than twice what PacketStream does.) I hope you'll give it a try.
On the other hand, PacketStream has come a long way since its earliest design (when all it did was "spit out the output of tcpdump into a window"), and it offers a lot of power in an inexpensive package. If you want every tcpdump option in the GUI, try WireShark (a powerful but ugly Gtk application that isn't the least bit Mac-like). If you are a command-line power user who wants to be able to toggle every flag/switch in tcpdump's output, PacketStream isn't for you. Regarding what PacketStream is and isn't: it's designed to be an easy-to-use wrapper of tcpdump's functionality, exposing a good deal of tcpdump's functionality, in a way that is simple, elegant, and Mac-like. Finally, with support for AppleScript (you can call PacketStream with an AppleScript) and the Services menu, PacketStream now offers a greater degree of Mac system integration/inter-application communication than before. It also exposes more of tcpdump's options to the user, specifically the ability to display actual packet data in the main interface. This new release of PacketStream addresses many of the issues raised in previous reviews, including Keychain integration to avoid prompting the user repeatedly for a password when running a network scan.
0 kommentar(er)
