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

Mavericks - can not capture from iPhone using RVI

2
1

After updating my macbook to Mavericks, Wireshark can still capture data from my iPhone using RVI(remote virtual interface). But it cannot analyze and show packets right. it only tells about packets that they are "User encapsulation not handled: DLT=149, check your Preferences->Protocols->DLT_USER".

This problem only occurs when capturing lively. If I capture and save using tcpdump, Wireshark analyzes them right. I tried to test using stable version and night builds. but the results were same.

Can anyone tell me how to solve this? Thanks in advance.

asked 29 Oct '13, 11:13

gish's gravatar image

gish
41125
accept rate: 0%

edited 12 Nov '13, 23:56

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196

Has anybody had any success on this yet. I am still not able to capture and analyse packets directly in Wireshark.

(05 Feb '14, 02:49) Anil Giri

I've filed a bug on this with Apple, but they haven't responded.

I haven't had time to dive into the Mavericks source and determine what the header looks like.

(05 Feb '14, 02:53) Guy Harris ♦♦

4 Answers:

2

Can anyone tell me how to solve this?

Solve this by complaining to Apple, ideally by filing a bug at http://bugreport.apple.com/, asking them not to use DLT_USER2 for their own purposes, and asking them instead to request an official DLT_ value from [email protected], citing the page at http://www.tcpdump.org/linktypes.html. The more dups, the better.

answered 29 Oct '13, 11:51

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Oh, and please attach Mavericks remote virtual interface captures to bug 9358; that will make it possible to test changes to Wireshark to dissect those packets natively (and develop changes to libpcap and tcpdump to fix this, so that I can yell at Apple to update their libpcap and tcpdump).

(05 Feb '14, 12:12) Guy Harris ♦♦

2

A better method is to use header size = 108 and payload protocol = eth.

answered 17 Nov '13, 23:14

bennettp123's gravatar image

bennettp123
415
accept rate: 0%

This solution works much better for me

(18 Nov '13, 10:35) sboisson

2

As others mentioned, the workaround is to enable the DLT_USER protocol #149 in Wireshark.

From my experience the actual header and protocol is different depending wether your device is connected using wifi or radio:

  • when connected with radio (3G): set header length to 112, and protocol to ip
  • when connected with wifi: set header length to 108, and protocol to eth

answered 05 Feb '14, 03:06

sboisson's gravatar image

sboisson
4114
accept rate: 0%

This is just to confirm that the above approach (set header length to 108, and protocol to eth) works for me. I can capture live and see all the info about my SIP packets during capture.

(19 Feb '14, 01:46) Anil Giri

1

A way to get data directly:

Go into Preferences/Protocols/DLT_USER and add an entry for user2, which is DLT=149. Set the header length to 112, and the protocol value to IP. This is less robust than #1, because there's plenty of info in that 112 byte header that's being ignored, but it should work for IP traffic.

answered 30 Oct '13, 22:06

kjbrock's gravatar image

kjbrock
263
accept rate: 0%

edited 30 Oct '13, 22:10

Thank you, kjbrock. Now I can enjoy live capture :)

(30 Oct '13, 23:20) gish

This does not help me capture and analyse my SIP message. Is there a better way to get it working as it was prior to mavericks?

(31 Oct '13, 00:15) Anil Giri
1

Have you tried the "capture with tcpdump and open in WS" solution? That seems to show me all the packets, not just the IP packets.

To get general capture working in WS you'd probably need to write something that parses the header and determines the protocol type from that. So for the truly masochistic, get Apple's tcpdump sources, look at how they're parsing it and integrate that into WS.

I think that Guy Harris is absolutely correct that Apple shouldn't be doing this with User2, so longer term we've got to hope that they'll fix this on their end.

(31 Oct '13, 08:12) kjbrock

Sorry for replying late.

The capture with tcpdump approach works fine. I can capture and write to a file. Then I am able to analyse the packets in Wireshark.

But this adds an additional step to my workflow. I would definitely want to file a bug with Apple if it is so. Can you please explain to me what exactly it is that appears to be broken on their part. I am not entirely familiar with the whole User2 thing.

(12 Nov '13, 23:11) Anil Giri
1

I had to use header length 122 to get this to work for me. And for clarification, you need to have payload protocol set to "ip" (as opposed to header protocol or other).

(16 Nov '13, 13:07) sadkinson