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

Graph Filter limitations

0

I've been experimenting with different ways to display certain traffic. First I display traffic trough the IO Graph tool, next I try to add a second line (Red to mark it as unwanted) and add a Filter. The problem however is that the Graph tool does not support as long a filter as regular display filters.

Is this normal behavior? Is there anyway around this? Perhaps any suggestions how to better show all network traffic and highlight certain (unwanted) traffic in graphs?

asked 08 Jul '13, 01:27

JoepMeloen86's gravatar image

JoepMeloen86
266611
accept rate: 50%

The problem however is that the Graph tool does not support as long a filter as regular display filters.

  • What is your Wireshark version?
  • how long are those filters?
(08 Jul '13, 01:53) Kurt Knochner ♦

Version 1.10, Filter = 588 characters (including a lot of spaces and brackets) lets say 16 conditions.

(08 Jul '13, 02:05) JoepMeloen86

2 Answers:

1

I have not looked at the source code to see how long the filter strings can be in each GUI element. But you might want to use "Display Filter Macro's". Go to "Analyze -> Display Filter Macros" and then add a macro with your filter.

I just tried it with your filter in a macro called "excluded" and then I used the filter ${excluded} in the IO graph filter box. That worked, but I'm not sure how long filter macros may be though :-)

answered 08 Jul '13, 03:07

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Hi, just tested it, and it seems to work. (first test I did showed just as high red spikes as black, as if the filtered traffic was exact the same as non-filtered traffic. Second test showed definite change). Thanks so far. I have a workable solution (or workaround if you will).

(08 Jul '13, 03:43) JoepMeloen86

1

Perhaps any suggestions how to better show all network traffic and highlight certain (unwanted) traffic in graphs?

it depends on your intentions. What is 'unwanted' traffic in your scenario. If the 'wanted' traffic is easier to describe, build a reverse filter. Draw everything that is not wanted traffic, which would then be unwanted traffic.

Like this:

Graph 1 (wanted): tcp.port eq 1234 or tcp.port eq 8090
Graph 2 (unwanted): not (tcp.port eq 1234 or tcp.port eq 8090)

Maybe you need to pre-filter (Display Filter) and export (File -> Export Specified Packets) the whole file to remove anything you don't want in the IO graphs. This will also reduce the time to create the graph, if you can eliminate a larger part of the traffic in this step.

Regards
Kurt

answered 08 Jul '13, 01:59

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 08 Jul '13, 04:11

Ok, thanks for the tip. I will try this. However, the question still remains: Is this normal behavior? Is there anyway around this?

(08 Jul '13, 02:06) JoepMeloen86

Is this normal behavior? Is there anyway around this?

There are character limits for a display filter, but they are all much larger than 588 chars (as far as I remember). So, either you found a bug, or your filter is wrong. Is it possible to post the filter here?

(08 Jul '13, 02:17) Kurt Knochner ♦

Had to change a lot of data of course, length of every definition should be the same though. With this I filter all wanted traffic, and get left with all unwanted traffic. Until now I have been exporting all the remaining (and thus unwanted) traffic and build a graph out of that (as you suggested already). Would be nice if I could build a graph of all traffic, and create a second red line using the filter below. It cuts me off in the definition after WPAD, when I try to either paste or select this in the Graph filter.

(http or ssl) && !(ip.addr == 100.10.100.1/25) && !(ip.addr == 100.10.100.1/24) && !(ip.addr == 10.100.10.100) && !(http.host contains "WKS1234567") && !(http.request.uri contains "abcdefg") && !(http.request.uri contains "wpad") && !(http.content_type contains "proxy-autoconfig") && !(ip.dst == 100.100.100.100) && !(http.proxy_connect_host contains "abcdefg") && !(http.response.code == 200) && !ipv6 && !(http.proxy_connect_host contains "abcdefghijklmn") && !(http.host contains "abcdefghijklmn") && !(http.request.uri contains "abc45678") && !(http.request.uri contains "abcdef78")

(08 Jul '13, 03:00) JoepMeloen86
1

O.K. there seems to be a limit of 256 characters in that field.

My position: Display should have to same limits everywhere in the GUI. As there is a limit for the length of the display filter here, I would consider this as a bug. Please file a bug report at https://bugs.wireshark.org

As @SYN-bit mentioned, marcos may (or may not) work, depending on where the restriction is in this case. Please try it with a macro and report the results here for the benefit of others :-)

(08 Jul '13, 03:34) Kurt Knochner ♦
1

UPDATE: I did a short test myself with your display filter. It works as a macro. So the limitation is just the input length of that field.

(08 Jul '13, 03:43) Kurt Knochner ♦

So what would be a more reasonable limit? 1000? 5000? 10000? More?

(08 Jul '13, 20:07) cmaynard ♦♦

In order to deliver a consistent experience to the users, I would suggest the same limit as the one for the Display filter in the "main menu", whatever that may be.

(09 Jul '13, 02:54) Kurt Knochner ♦

Currently, there is no limit imposed.

(09 Jul '13, 05:03) cmaynard ♦♦
showing 5 of 8 show 3 more comments