Ask Your Question
0

launch hang MacOS 10.11.6 El Cap “Finding local interfaces”

asked 2018-12-15 13:31:25 +0000

cwinte gravatar image

updated 2018-12-15 21:54:58 +0000

Jaap gravatar image

Hi, first visit. I had some odd crashes during last night, older Wireshark was running at the time (not sure how to determine version if needed, is there an installations log) I'd guess v2.x. WS has been running most of recent week, normally 20Mb/day but last night 333Mb logged, I saved the capture OK but it then hung. All 3 crashes seemed not to produce logs in /Library/Logs/DiagnosticReports/ -even more odd

(The other 2 apps to crash were lnav and Thunderbird. TB is the target of my research at present.) Force quit and restart (the old version WS) hung in progress bar something like "loading module preferences" but I could not find any candidate prefs file!

I'm reluctant to reboot I must add; I have a ramdisk with a great deal of complex permissions and ACLs so though the data is backed regularly & should survive I want to avoid a rebuild...

I have also been running tcpdump during most of this last week. I have stopped it while rerunning some attempts at running WS, no difference. Tcpdump runs fine...

I went to get new WS 2.6.5, installed and ran that. 4 hangs no full runs, same if I tried to open old cap files. Runs to 85% progress and hangs at “Finding local interfaces” (Progress bar at window bottom says Please wait while initialising…), take a sample force quit. Rerun, same a .hang spin dump was also generated looks like it is just waiting some child… Syslog:

12:44:13 ··· com.apple.xpc.launchd[1] (org.wireshark.Wireshark.1245152[81449]): Service exited due to signal: Terminated:

15 Dec 15 12:44:24 ··· spindump[1310]: Saved hang Wireshark v(2.6.5) to /Library/Logs/DiagnosticReports/Wireshark_2018-12-15-124424_

from the system crash dumps:

Heaviest stack for the main thread of the target process:

  16  start + 52 (Wireshark + 39284) [0x10f005974]
  16  main + 5420 (Wireshark + 46332) [0x10f0074fc]
  16  ??? (<94810710-91FA-308D-B210-3166F83FCA81> + 2338535) [0x11434dee7]
  16  ??? (<94810710-91FA-308D-B210-3166F83FCA81> + 2324909) [0x11434a9ad]
  16  ??? (<11698C69-9848-3320-B311-B5F9CF22C1FE> + 128484) [0x114ac95e4]
  16  -[NSApplication run] + 682 (AppKit + 249216) [0x7fff8e143d80]
  16  -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 454 (AppKit + 295462) [0x7fff8e14f226]
  16  _DPSNextEvent + 1067 (AppKit + 298486) [0x7fff8e14fdf6]
  16  ReceiveNextEventCommon + 432 (HIToolbox + 198511) [0x7fff9768f76f]
  16  RunCurrentEventLoopInMode + 235 (HIToolbox + 198965) [0x7fff9768f935]
  16  CFRunLoopRunSpecific + 296 (CoreFoundation + 560680) [0x7fff90085e28]
  16  __CFRunLoopRun + 927 (CoreFoundation + 562223) [0x7fff9008642f]
  16  __CFRunLoopDoSources0 + 556 (CoreFoundation + 565004) [0x7fff90086f0c]
  16  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 (CoreFoundation + 698337) [0x7fff900a77e1]
  16  ??? (<11698C69-9848-3320-B311-B5F9CF22C1FE> + 125013) [0x114ac8855]
  16  ??? (<94810710-91FA-308D-B210-3166F83FCA81> + 2691478) [0x1143a4196]
  16  ??? (<94810710-91FA-308D-B210-3166F83FCA81> + 2337074) [0x11434d932]
  16  ??? (<878A2FA0-18EB-3632-AC77-0F295CF0E7F3> + 195259) [0x10f9ecabb]
  16  ??? (<878A2FA0-18EB-3632-AC77-0F295CF0E7F3> + 184316) [0x10f9e9ffc]
  16  ??? (<94810710-91FA-308D-B210-3166F83FCA81> + 2521507) [0x11437a9a3]
  16  ??? (<94810710-91FA-308D-B210-3166F83FCA81> + 2550639) [0x114381b6f]
  16  InterfaceTree::updateStatistics() + 44 (Wireshark + 964668) [0x10f0e783c]
  16  capture_stat_start + 40 (Wireshark + 3687880) [0x10f3805c8]
  16  sync_interface_stats_open + 579 (Wireshark + 3804579) [0x10f39cda3]
  16  __wait4 + 10 (libsystem_kernel.dylib + 95618) [0x7fff9048b582]
 *16  ??? (kernel + 5988080) [0xffffff80007b5ef0]
edit retag flag offensive close merge delete

Comments

OP further note: I want Wireshark as its detail analysis of TCP packet timings was showing highlighted retransmissions that I simply was not able to spot in the stream from tcpdump. Also the filtering options at both capture and then display give me an extra set of useful options. I read something about running tcpdump with -I (cap i) but is this a change recently? I was fine capturing what I needed for over a week before last night!

cwinte gravatar imagecwinte ( 2018-12-15 13:48:16 +0000 )edit

Further: all 3 apps that crashed/hung were working together. Wireshark monitoring my wifi traffic, TB creating the traffic plus creating MOZ_LOG file of IMAP traffic and lastly LNAV collating all logging data

cwinte gravatar imagecwinte ( 2018-12-15 14:01:32 +0000 )edit

First, note:

  1. a program that just "chooses to give up" by exiting won't produce a crash report;
  2. logs may also appear in ~/Library/Logs/DiagnosticReports;

so the lack of logs in /Library/Logs/DiagnosticReports may have a simple explanation.

Tcpdump runs fine...

Does it run if you just run it without sudo, or do you have to run it with sudo?

And what does ls -l /dev/bpf0 print?

Force quit and restart (the old version WS) hung in progress bar something like "loading module preferences" but I could not find any candidate prefs file!

~/.config/wireshark/preferences? ~/.wireshark/preferences?

Guy Harris gravatar imageGuy Harris ( 2018-12-16 04:15:56 +0000 )edit

Thanks Guy:

2 of the 3 asked if I wanted to send crash reports. I said yes to Thunderbird and no to LNAV. tcpdump has always been run under sudo, my UI login is not admin but in terminal I su -l to an admin enabled pid.

ls -l /dev/bpf0

crw-rw---- 1 root access_bpf 23, 0 27 Oct 19:29 /dev/bpf0

Thanks for the clue on WS prefs. recent & recent_common files are old and look like from earlier versions and now unused, the files etc they ref are from Aug though I have done much more since then...

-rw-r--r-- 1 noadminuser staff 575 8 Dec 09:20 filters

-rw-r--r-- 1 noadminuser staff 180 8 Dec 10:15 language

-rw-r--r-- 1 noadminuser staff 183007 8 Dec 10:15 preferences

drwxr-xr-x 2 noadminuser staff 68 15 Dec 12:37 profiles

-rw-r--r-- 1 noadminuser staff 2049 16 Aug 11:24 ...

(more)
cwinte gravatar imagecwinte ( 2018-12-16 15:32:14 +0000 )edit

There is also an empty directory at /Users/myadminuser/.config/wireshark/profiles

cwinte gravatar imagecwinte ( 2018-12-16 15:49:01 +0000 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2018-12-17 21:22:53 +0000

Guy Harris gravatar image

In macOS, permission to capture on individual network interfaces means permission to open a /dev/bpf device for reading.

The "ChmodBPF" script Wireshark installs changes the permissions on the BPF devices to be rw-rw---- and the group owner of the BPF devices to be the "access_bpf" group.

This means that any process with "access_bpf" as its primary group or in its secondary group set can do capturing.

Wireshark also puts the user who installs Wireshark into the "access_bpf" group, but it doesn't put any other user into that group. If the user who installs Wireshark isn't an admin user, that means that 1) the user who installs Wireshark has permission to capture and 2) whatever account is the admin user doesn't have permission to capture.

Yes, it means that there is at least one thing that at least one non-admin user can do and that at least one admin user can't do. "An admin user has a superset of the privileges that a non-admin user has" is not guaranteed to be true.

So either:

  • run Wireshark from the account that installed it;
  • add the "access_bpf" group to the secondary group set of any other account from which you want to run Wireshark;

or both.

As for the hang, that might have the same cause as bug 14284, in which case making sure that all accounts under which you run Wireshark are in the "access_bpf" group should fix that.

edit flag offensive delete link more

Comments

That is very useful information, thank you. A few questions arise for me though... The installers often ask for admin account details to do their task, so does this mean they run as admin to do the install? The evidence would indicate not: I started the WS install as non admin user, and it is that (non admin) user enrolled in access_bpf group.

However, starting WS via the UI as that installing UI user I get a hang unable to open the capture device (I assume). This is where I started. I was able to run the old version of WS until a crash and then neither that old version or the newly installed version. I am 99.9% sure that UI user IS uid 502, the non-admin installer of WS and in the access_bpf group.

The admin user (not in access_bpf) does seem to be able to run WS ...(more)

cwinte gravatar imagecwinte ( 2018-12-18 00:33:35 +0000 )edit

If I am in admin shell and issue

sudo /path/wireshark

it shows 10 capture devices and runs fine.... well just 3 warnings :

00:40:47.754  Capture Warn sync_pipe_wait_for_child: waitpid returned EINTR. retrying.
00:40:47.784  Capture Warn sync_pipe_wait_for_child: waitpid returned EINTR. retrying.
00:41:10.492  Capture Warn sync_pipe_wait_for_child: waitpid returned EINTR. retrying.
cwinte gravatar imagecwinte ( 2018-12-18 00:43:03 +0000 )edit

Further noticed, my admin user UID is 501 and this is the value shown for access_bpf in id listing for the non admin user 502. Is that as it should be??? 501(access_bpf),

cwinte gravatar imagecwinte ( 2018-12-18 01:14:21 +0000 )edit

/dev/bpf* runs from 0 to 255, that seems way too much. i.e. Is that normal & OK? i.e. first few lines of output

$ l /dev/bpf*
/dev/bpf0   /dev/bpf127 /dev/bpf156 /dev/bpf185 /dev/bpf213 /dev/bpf242 /dev/bpf41  /dev/bpf70
/dev/bpf1   /dev/bpf128 /dev/bpf157 /dev/bpf186 /dev/bpf214 /dev/bpf243 /dev/bpf42  /dev/bpf71
cwinte gravatar imagecwinte ( 2018-12-18 08:57:25 +0000 )edit

Looking at the ChmodBPF script I see it does intend to run through & create all 256 devices, this seems to be to avoid any new ones arising on demand with other settings.

cwinte gravatar imagecwinte ( 2018-12-18 09:05:56 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2018-12-15 13:31:25 +0000

Seen: 136 times

Last updated: Dec 17 '18