This is a static archive of our old Q&A Site. Please post any new questions and answers at

Wireshark for Macintosh 64 bit vs. 32 bit install problems


I THINK this may be something obvious but I am missing what it is.

This is the current 1.4.1 Macintosh version, both the 64 bit and 32 bit versions.

I have 4 iMacs, INTELS, all running Mac OS 10.6.4. Most have 8 gigs RAM and that info is being indicated in this one problematic iMac as well.

These iMacs are standard 10.6.4 installs, done by myself previously, now with all updates done except for two most recent security updates but not relevant, just historical.

Today, I installed X11 on all 4 from the DVD that came with each iMac which is about a year old model.

I then installed Wireshark v1.4.1 64 bit version on all 4 machines and on 3 of them, it worked without any problems. On one machine, it would only bounce once and then stop.

Same behavior if app was on desktop or in Apps folder. Fixed permissions just in case but no help.

I then had the idea to see what would happen if I installed the 32 bit version on the "problematic" iMac and that worked as expected.

These are pretty standard configured computers for DTP use, so no fancy user or CLI changes, no restart into 64 bit Finder - just basic vanilla clean installs on each one that have been working without problems for over a year.

So, what does this result indicate if anything? Why does only the 32 bit version work on that one machine? What I did not do was check Activity Monitor to see if the machine had access to the 8 gigs wondering if this means there is an architectural problem on one of them but how could that be anyway?

This is sort of academic but if this all sounds too familiar, I would be interested.


asked 02 Nov '10, 15:30

pmf's gravatar image

accept rate: 0%

edited 28 Feb '12, 20:00

cmaynard's gravatar image

cmaynard ♦♦

2 Answers:


My first guess would be that the "fourth" iMac is not equipped with a 64-bit CPU. Could you post the CPU type in a comment? And does the activity monitor show any other 64-bit applications running?

answered 02 Nov '10, 16:34

SYN-bit's gravatar image

SYN-bit ♦♦
accept rate: 20%

Well, it is the same model as at least 2 of the 3 other machines, it is a INTEL machine so if the chip is not a 64bit CPU, it means Apple put the wrong chip in the machine. I will try to get the actual Profiler CPU info from my client but think getting him to send me Activity Monitor info may be a problem. :-)

They do have CS5 on that machine though.


(02 Nov '10, 16:52) pmf

Updated info: The iMac does indicate in Profiler to have an INTEL chip and I think it is 64 bit.

Hardware Overview: Model Name: iMac Model Identifier: iMac10,1 Processor Name: Intel Core 2 Duo Processor Speed: 3.06 GHz Number Of Processors: 1 Total Number Of Cores: 2 L2 Cache: 3 MB Memory: 8 GB Bus Speed: 1.07 GHz Boot ROM Version: IM101.00CC.B00 SMC Version (system): 1.53f13


in Activity Monitor there are a number of 64 bit apps running including FINDER and other OS components.


(03 Nov '10, 06:36) pmf


Mac's usually ship with both a 32 bit and 64 bit kernel. The 32 bit kernel has some magic added to handle larger address spaces, and it can handle 64 bit apps just fine. Kernel extensions, however have to be matched to the kernel. I'm betting that the berkeley packet filter has to be implemented as a kext, and that it isn't matched to the kernel you are using.

Run wireshark from the command line. On my box it is

bash-3.2# /Applications/

Also try running kextstat on various machines and see if there is a different set of extensions loaded. Running kextstat on a machine that has wireshark running and comparing to before you start wireshark may tell you if wireshark is loading a kext.

answered 13 Feb '11, 08:17

SGBotsford's gravatar image

accept rate: 0%

BPF is in /mach_kernel, not in a kext. There is one bug in BPF that causes problems with 64-bit user code on a 32-bit kernel, but, in most versions of 10.6, libpcap works around it, and in the ones where it doesn't, Wireshark works around it.

(13 Feb '11, 13:08) Guy Harris ♦♦