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

Searching for content inside packets ?

0
1

Hello,

I want to find packets that have a specific string inside. Is this possible ? for example : find packets which have a "Content-type:audio/mpeg".

asked 08 Oct '13, 15:35

ychaouche's gravatar image

ychaouche
315610
accept rate: 100%

1

Hi. I'd just like to add that the Find dialog box can be easily mis-understood if you don't pay attention to the radio buttons that are selected by default. By default, the Find dialog box searches the Display Filter for the string you type in (personally, I'd like to see the options reversed so that String is selected by default). Anyway given your example, you want to to search for a String so you need to select that radio button and type in the search string.

Now that you have selected the String radio button, you need to pay attention to the Search In radio buttons. By default, the Find dialog box works searches for the string in the window containing the list of packets. But this ins't where your string is going to be found - you want to search inside the actual TCP data bytes inside the packet. So to search there, you need to select the Packet Bytes radio button. Again, personally, I'd like to see this option selected as the default.

The rest of the options are pretty self-expanatory. HTH - took me a while to figure out this dialog box.

(09 Oct '13, 07:32) smp
1

EDIT - I just realized my description of the Find dialog box and it's use of the Display Filter is incorrect. It appears to be similar to typing in a display filter, the difference being that the Find dialog box will select packets individually, while the display filter will display all matching packets. Learned something...

(09 Oct '13, 07:44) smp

3 Answers:

5

While the other answers are correct and do provide generic methods for finding arbitrary strings within a frame, it seems that in this case, the following filter is what was desired:

http.content_type == "audio/mpeg"

answered 09 Oct '13, 10:12

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142
accept rate: 20%

I wonder why sometimes it doesn't work, see this screenshot : http://i.imgur.com/HzrloMA.png

(22 Oct '13, 13:17) ychaouche

@ychaouche, can you share a capture file on cloudshark or elsewhere?

(22 Oct '13, 14:04) cmaynard ♦♦

maybe due to whitespaces. Did you try

http.content_type contains "audio/mpeg"

or the HTTP connection used a port that was not in the list of 'known HTTP ports', and thus the HTTP dissector was unable to detect it as HTTP (Edit -> Preferences -> Protocols -> HTTP -> TCP Ports)

(22 Oct '13, 14:06) Kurt Knochner ♦

I uploaded the file here : http://cloudshark.org/captures/471105b38cc1

Note that when doing live capture I couldn't display-filter on http.content_type but when stoping the capture and loadin the file it worked.

(22 Oct '13, 14:59) ychaouche
1

Well, that's strange and I don't have an answer for you, only more questions. First off, what version of Wireshark are you using, and have you tried the latest development version, 1.11.0 to see if there's any difference?

(22 Oct '13, 19:17) cmaynard ♦♦

Ok I compiled and installed wireshark 1.10.2, now the display filter works as soon as the whole file is received. I was using 1.4.15.

(23 Oct '13, 08:25) ychaouche

Please see this again @cmaynard @KurtKnochner http://www.cloudshark.org/captures/d9916e96065a. If you follow the tcp stream 0 you'll find that http.content_type is audio/mpeg but if you use the display filter http.content_type contains "audio" it doesn't show any packet.

(05 Jan '14, 17:08) ychaouche

This looks to be some sort of TCP reassembly bug, one which may or may not have been reported already (would need to search the open bug list to find out). If you disable the TCP preference to "Allow subdissector to reassemble TCP streams", then packet #6 will match your http.content_type contains "audio" filter.

(06 Jan '14, 08:15) cmaynard ♦♦
showing 5 of 8 show 3 more comments

2

You can use the following display filter:

frame contains "Content-Type:audio/mpeg"

or

frame matches <regexp>

Regards
Kurt

answered 08 Oct '13, 15:45

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 09 Oct '13, 13:32

1

Or assuming this is http traffic:

http.content_type == "audio/mpeg"
(09 Oct '13, 08:28) cmaynard ♦♦

If you put that as an answer I'd probably validate it.

(09 Oct '13, 09:59) ychaouche

1

This is late reply to an interesting question. I think the problem is because the HTTP transaction didn't complete. According to the HTTP response header, the content length should be 7257219, but the body is only 7180879, so it's not complete.

I carved out the data as a mpeg file and it sounds pretty good :-)
Here is the link to this beautiful song: https://www.dropbox.com/s/j3vts8zshjp99wk/tmp.mpeg?dl=0

answered 28 May '15, 21:15

pktUser1001's gravatar image

pktUser1001
201495054
accept rate: 12%

Natalie Walker -- No One Else

(26 Dec '16, 04:54) ychaouche