Previous 1 2 Next 16 Replies Latest reply: Jan 21, 2007 7:44 PM by Karl Zimmerman
Simon Ginsburg Level 1 (140 points)

after trying to install the Unix source code version of wireshark and havin mastered Fink, CVS and all those makefiles, but am still ending with successful compilation without any useful program, I wonder if someone already has been thinking on creating a Mac OS X version of Wireshark.

Any info is greatly appreciated!


G4 Dual 1.4GHz; MacBook Pro, Mac OS X (10.4.7)
  • Karl Zimmerman Level 4 (2,065 points)
    I am surprised that Wireshark built from fink doesn't work; Ethereal (Wireshark's predecessor) worked fine for me.

    I doubt anyone will do an Aqua port of Wireshark as long as X11 is available for OS X. Given that, I think we should focus on getting fink/Wireshark to work for you...

    You say that the build completes successfully, but "without any useful program". What do you mean by that? What happens when you try to run it?
  • Bill Scott Level 6 (11,445 points)
    I had to run ethereal with sudo. Perhaps it is the same with wireshark? I'm installing fink's now so hopefully I can offer something more intelligent...
  • Bill Scott Level 6 (11,445 points)
    Well, I compiled it using fink, started it with

    sudo wireshark

    and then chose my airport card (en1) and it works just like ethereal (which is to say, it works fine).
  • Karl Zimmerman Level 4 (2,065 points)
    Yes, if you want to use Wireshark or Ethereal to actually capture the network traffic, you must run it with sudo. The capture program must talk directly to the interface driver (unlike normal TCP/IP applications), and it needs root priveleges to do so.

    If you use 'sudo tcpdump etc.' to capture packets to a file, you can then use Ethereal without sudo to parse the file. I presume the same is true for Wireshark. However, filter set-up is a lot easier with Ethereal than with tcpdump!
  • Simon Ginsburg Level 1 (140 points)
    Hello Karl,

    sorry for the delay in answering.

    In the mean time I deleted all sourcefiles regarding wireshark and restarted fink. Now the compiling/building takes several minutes and finally is considered Done.

    But when starting sudo wireshark I get the following response:

    (wireshark:1009): Gtk-WARNING **: cannot open display:

    What's (still) wrong with my installation?

    Thanks for your help in advance!

  • Simon Ginsburg Level 1 (140 points)
    Stupid Me!

    After compiling I started wireshark using the terminal under bash script. OKOKOK! Please don't hit the blind....

    Starting X11 and entering sudo /sw/bin/wireshark

    It RUNS!

    Thanks alot!

  • Karl Zimmerman Level 4 (2,065 points)
    Ah! See this thread!

    You must be running X11, and your DISPLAY variable must be set properly in the environment from which you invoke Wireshark. Exactly how to do this isn't yet known. Assuming you are using an admin account, my first suggestion would be:

    1. start X11

    2. from the xterm, do 'sudo wireshark'

    If that doesn't work, my next suggestion would be (from any account):

    1. start X11

    2. from the xterm, do 'ssh -Y admin_user@localhost'

    3. echo $DISPLAY

    4. sudo 'DISPLAY=result of last command wireshark'

    Fallback positions:

    1. Use tcpdump to capture packets, copy them back to your user area, and run wireshark without the sudo to view the packets.

    2. Enable the root user, log in as root and use it there.

    Let us know what you find out!

    Powerbook G4 1GHz   Mac OS X (10.3.9)  
  • Simon Ginsburg Level 1 (140 points)
    Hi Karl,

    setting the DISPLAY variable was not even necessary, All I did was rebooting after the compilation and obviously all settings were OK.

  • Gary Kerbaugh Level 6 (18,040 points)
    Hi Karl,
       First, thanks to all for the heads up on Wireshark. This is the first I've heard of it but I love Ethereal so it's exciting to learn of such new developments.

       You made the comment on the other thread that "Running an X11 server as user 'A' does not make it available to user 'B'." I assume that X11 can only create windows in one of "screens", or whatever they're called, used in Fast User Switching. However, that's hardly normal for UNIX in general. The permissions on the socket are srwxrwxrwx, so anyone has access. Simon is using "su" to change user in the terminal only, which is no problem at all; I tested it. No matter who starts X11, any user can use X11 in the absence of Fast User Swithing as long as the DISPLAY environment variable is set appropriately in that user's environment.
       It's better to burn out than it is to rust.
  • Karl Zimmerman Level 4 (2,065 points)
    OK. I'm surprised, but happy for you!
    Thank you very much for the star!
  • Karl Zimmerman Level 4 (2,065 points)
    Well, that makes sense. I have Fast User Switching enabled all the time, so I only speak for that environment. With FUS enabled, I've brought up X11 in two different user accounts; both xterms have DISPLAY set to .0, yet the X11 displays are independent. So, FUS must be messing with how "DISPLAY" numbers are mapped to sockets...

    -- Karl
  • Gary Kerbaugh Level 6 (18,040 points)
    Hi Karl,

    > ... both xterms have DISPLAY set to .0, yet the X11
    displays are independent.

       That's incredible! Are you sure? Maybe Apple did it differently in Panther but it's hard to imagine that writes to a socket can be "pipelined" to correct "screen" according to username. Can your users write to each other's X11 display with sudo? That would seem rather unlikely to be considered a satisfactory implementation.

       It would seem more likely that your sockets behave in a rather unPOSIX manner with respect to Mach namespaces. (as described in Technical Note TN2083: Daemons and Agents) It would be possible to use the socket independently in different per-session namespaces. The socket would act like a number of sockets, one for each per-session bootstrap namespace.

       It's done rather differently in Tiger, if my system is generic in that regard. The display is different for each different Xsession. With both me and my testuser, kerby, (the virtual crash-test dummy) running X11, I get the following outputs in the main user's shell:

    % ls -lhAF /tmp/.X*
    -r--r--r-- 1 kerbaugh wheel 11B Dec 5 04:20 /tmp/.X0-lock
    -r--r--r-- 1 kerby wheel 11B Dec 5 04:20 /tmp/.X1-lock

    total 0
    srwxrwxrwx 1 kerbaugh wheel 0B Dec 5 04:20 X0=
    srwxrwxrwx 1 kerby wheel 0B Dec 5 04:20 X1=
    % export DISPLAY=:1.0
    % xeyes
    Xlib: connection to ":1.0" refused by server
    Xlib: Invalid MIT-MAGIC-COOKIE-1 key
    Error: Can't open display: :1.0
    % sudo -u kerby xeyes
    Xlib: connection to ":1.0" refused by server
    Xlib: No protocol specified

    Error: Can't open display: :1.0

    Thus, the main user cannot access the socket of the testuser but both can see both sockets. Out of curiosity, what do you get when you execute:

    ls -lhAF /tmp/.X*

    Maybe your other user's shell startup script sets the DISPLAY variable to a static value. (like mine, unfortunately) However, my poor testuser has no shell environment. (I love a good crash) Thus, the DISPLAY variable was set correctly in the xterm window.
       Never put off till tomorrow what you can avoid all together.
  • Karl Zimmerman Level 4 (2,065 points)
    > ... both xterms have
    DISPLAY set to .0, yet the X11
    displays are independent.

       That's incredible! Are you sure?

    Well, I thought I was, but I was wrong. As you describe, the two different X sessions have different DISPLAY values. Sorry it took so long to actually check this out!
  • Bill Scott Level 6 (11,445 points)
    That shouldn't be the case. automatically sets the correct DISPLAY for multiple simultaneous users, so xterm for example can launch other xapps. However, you might have a startup script that over-rides this.

    I wrote a script (zsh syntax) to find the correct DISPLAY variable for each of the simultaneous sessions, as usual, with much help from Gary and others here.

    # X11 and $DISPLAY control #

    # Now set the DISPLAY variable, if needed. If is running,
    # we deduce and construct the DISPLAY value from the process. If
    # this doesn't work (no running), we give up and dumbly set the
    # value to .0. Users who want to avoid the small ps overhead can
    # comment out the "disp_no" line. This will simply set DISPLAY=:0.0

    if [[ -z $DISPLAY && -z $SSH_CONNECTION ]]; then

    disp_no=($( ps -wwx | grep -F | awk '{print $NF}' | grep -e ":[0-9]" ))

    if [[ -n $disp_no ]];then
    export DISPLAY=${disp_no}.0
    # Colorful output tells us that the smart method has worked
    print "\e[1mDISPLAY\e[0m \e[36mhas been set to\e[0m \e[1m$DISPLAY \e[0m"
    # FAILSAFE: dumb setting of DISPLAY gives a monochromatic message
    export DISPLAY=:0.0
    print "DISPLAY has been set to $DISPLAY"

    elif [[ -n $DISPLAY && -z $SSH_CONNECTION ]]; then

    # Inform that we have inherited the DISPLAY (as with an xterm)
    print "\e[36minheriting\e[0m \e[1mDISPLAY\e[0m set to \e[1m$DISPLAY\e[0m"

Previous 1 2 Next