launch hang MacOS 10.11.6 El Cap “Finding local interfaces”

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

cwinte
1 ●2 ●3

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

Jaap

13730 ●687 ●115

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]

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 ( 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 ( 2018-12-15 14:01:32 +0000 )edit

First, note:

a program that just "chooses to give up" by exiting won't produce a crash report;
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 ( 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 ( 2018-12-16 15:32:14 +0000 )edit

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

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

see more comments

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

Guy Harris
19890 ●3 ●634 ●207

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

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 ( 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 ( 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 ( 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 ( 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 ( 2018-12-18 09:05:56 +0000 )edit

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?

No, it means they run that part of the task as root. The installer uses a GUI equivalent of sudo to run a subprogram as root. If you're an admin user, that mechanism asks you for your password, so it knows (as best it can) that you're the admin user in question; if you're not an admin user, it asks you for an admin user's name and password, so it knows (as best it can) that said admin user trusts you enough to give you the power to log in as them.

However, starting WS via the UI as that installing UI user I get a hang unable ...

(more)

Guy Harris ( 2018-12-18 09:29:32 +0000 )edit

As my non admin shell user I can indeed issue tcpdump -i en0 and see packets captured. It was a bit reluctant to quit, seemingly ignoring ^C but ^Z worked and showed packet summary lines. I then checked jobs and issued kill %1.
Issuing /Applications/Wireshark.app/Contents/MacOS/Wireshark at the same user shell I have operational wireshark with just 1 warn: Capture Warn sync_pipe_wait_for_child: waitpid returned EINTR. retrying.

If I go to the Application in the UI and click it IS now running so something has changed and I have no idea what when or how!

Not sure what you meant by "Scroll down to section 3." - of what?? Sounds like something good to read!

cwinte ( 2018-12-18 10:29:13 +0000 )edit

last syslog entry re non running Wireshark I can see at present was 18hours ago, my suspicion is that the child capture process dump cap is now running (I can see it reading /dev/bpf3 etc) but was not before?

com.apple.xpc.launchd[1] (org.wireshark.Wireshark.1245152[18594]): Service exited due to signal: Terminated: 15

Unfortunately I have been too busy in the last month with other tracing etc to run my normal process and thread logging so I do not think I can check into that.

cwinte ( 2018-12-18 10:34:07 +0000 )edit

Both Wireshark and dumpcap are running under UID 502, the non admin installer UI user...

cwinte ( 2018-12-18 10:39:25 +0000 )edit

The File Open navigation dialog seems nonMac code (I normally have default Folder tied in too) and I cannot see how to access any external drives just / (with no Volumes or much else) and my user area. Maybe there are mount point workarounds but I never noticed this with the old version (may be I was looking elsewhere!) Is this a known feature or something to raise in a new issue - I assume we are close to closing this one at last!!! (I really NEED some captures). I was trying to open the 333MB capture that was made at the time Wireshark (previous version) ceased running as there might be events of interest. Is that a good idea? What to look for? (it was 15 times larger than expected for the period)

cwinte ( 2018-12-18 10:45:23 +0000 )edit

I have copied that crash period capture to my Ramdrive (which mounts in my user directory) to work around the Open dialog. The capture did still seem to be running on from previous day when I logged in to UI and looked at emails, I can see the normal TCP traffic I was expecting. WS crashed after finishing writing the capture file I am looking at and then did not run until 30mins ago despite the update etc. Ohh, 80+% bulk of the data is explained by a friends album download from band camp using TCP traffic 6pm on 14th. Was wondering if this were some sort of attack, big packets very fast... Everything else looks OK too, as far as I can spot.

cwinte ( 2018-12-18 11:32:44 +0000 )edit

I am running a capture (!!! YAY - HOORAY!!!) Thank you so much!!!! To summarise: No idea why it would not run, no idea why it ran 3 days later AND ...

I AM HAPPY ANYWAY

cwinte ( 2018-12-18 11:50:21 +0000 )edit

add a comment

Your Answer

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

launch hang MacOS 10.11.6 El Cap “Finding local interfaces”

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

launch hang MacOS 10.11.6 El Cap “Finding local interfaces” edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

launch hang MacOS 10.11.6 El Cap “Finding local interfaces”