Wireshark for Mac OS X

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?

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...

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).

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!

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)

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.
--
Gary
~~~~
It's better to burn out than it is to rust.

OK. I'm surprised, but happy for you!
Thank you very much for the star!

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

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

/tmp/.X11-unix:
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
Password:
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.
--
Gary
~~~~
Never put off till tomorrow what you can avoid all together.

> ... 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!

That shouldn't be the case. X11.app 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.

<pre>
###########################################
# X11 and $DISPLAY control #
###########################################

# Now set the DISPLAY variable, if needed. If X11.app is running,
# we deduce and construct the DISPLAY value from the process. If
# this doesn't work (no X11.app 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 X11.app | 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"
else
# FAILSAFE: dumb setting of DISPLAY gives a monochromatic message
export DISPLAY=:0.0
print "DISPLAY has been set to $DISPLAY"
fi

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"
fi


</pre>

Hi Karl,

> Sorry it took so long to actually check this out!

Not a problem; I just thought that you took the signature joke in my last post seriously. I wasn't trying to suggest a way of life; it was just a joke. 🙂

Seriously, thanks for the excuse to read about my experiment again; I'd forgotten about that.
--
Gary
~~~~
You learn to write as if to someone else because
"NEXT YEAR YOU WILL BE SOMEONE ELSE."