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

Error: Unhandled Exception (group=1, code=6)

0

hi, when i use tshark to sniffer, it always appear error:Unhandled Exception (group=1, code=6)

My cmd is "tshark -nn -i eth1 -t ad -R '(tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.dst<192.168.0.0 or ip.dst>192.168.255.255)'"

Firstly, i thought maybe the memory isn`t enough, but after i freed memory,i found it still error and now the free memory have 4G,

Can you tell me how to solve?

Thank you.

asked 17 May '12, 01:00

mastertu's gravatar image

mastertu
1●1●1●2
accept rate: 0%

  1. what is your OS
  2. what is the version of tshark
  3. do you run the command as root

Regards
Kurt

(17 May '12, 01:14) Kurt Knochner ♦
  1. my os is centos 6.2
  2. the version of tshark is TShark 1.2.15
  3. yes, i run the command as root.
(17 May '12, 01:17) mastertu
[[email protected] ~]# tshark -v
TShark 1.2.15

Copyright 1998-2011 Gerald Combs <[email protected]wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Compiled (32-bit) with GLib 2.22.5, with libpcap 1.0.0, with libz 1.2.3, without
POSIX capabilities, with libpcre 7.8, with SMI 0.4.8, without c-ares, without
ADNS, without Lua, with GnuTLS 2.8.5, with Gcrypt 1.4.5, with MIT Kerberos,
without GeoIP.


Running on Linux 2.6.32-220.7.1.el6.i686, with libpcap version 1.0.0, GnuTLS
2.8.5, Gcrypt 1.4.5.


Built using gcc 4.4.6 20110731 (Red Hat 4.4.6-3).
(17 May ‘12, 01:20) mastertu

my sniffer data is very much, wheather it caused this errror?

(17 May ‘12, 01:32) mastertu

maybe. When does the error occur. Right at the beginning?

BTW: before we are looking for possible errors in an older version of tshark, can you please upgrade to tshark 1.6? As CentOS 6.2 only provides wireshark 1.2, I suggest to look for a 1.6 rpm elsewhere or compile it yourself.

(17 May ‘12, 01:37) Kurt Knochner ♦

not right at the beginning, it after six or seven minutes.

Ok, i will upgrade it and try again

(17 May ‘12, 02:19) mastertu
showing 5 of 6 show 1 more comments

One Answer:

3

This may very well be caused by running out-of-memory. Especially since you say you are on a high bandwidth network and using display filters instead of capture filters.

Tshark is a statefull analyzer which means it does keep state of all kinds of sessions. It also does reassembly of higher layer protocols. All of this will increase its memory footprint while capturing. So it is best to present tshark as little data as possible to reduce the memory footprint while capturing. This can be done by using capture filters.

The equivalent capture filter for your display filter would be:

tcp[13]&18=2 and not (dst net 192.168.0.0 mask 255.255.0.0)

(tcp[13] points to the TCP flags in the TCP header, the SYN bit has value 2, he ACK bit has value 16, so to only select SYN packets without SYN/ACK packets anding with 16+2 should result in 2. Then your not interested in TCP SYN's to systems in 192.168.0.0/16, so exclude those destinations with the "dst net" filter)

So you could use the command:

tshark -nn -i eth1 -t ad -f "tcp[13]&18=2 and not (dst net 192.168.0.0 mask 255.255.0.0)"

Which should make it possible to run tshark for much longer periods than with your previous command. However, it will not run forever.

Please also note that using display filters in recent versions of tshark is not possible anymore while capturing as the capture engine has been moved to a separate process for privilege separation.

answered 17 May '12, 02:49

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k●9●57●245
accept rate: 20%

edited 17 May '12, 06:19

Yes, he's running out of memory. Unfortunately tshark didn't catch the OutOfMemory exception until r39798. (After that rev tshark will tell you what the problem is rather than just failing to catch the exception.)

(17 May '12, 05:54) JeffMorriss ♦

when i use "tshark -nn -i eth1 -t ad -f "tcp[13]&18=2 and not (dst net 192.168.0.0 mask 255.255.0.0)""
I found a lot of packets didn`t caught

(18 May '12, 02:33) mastertu

What do you mean by "caught"? This capture filter does the same as your display filter. The output on screen should be the same (which I just verified myself with some test traffic).

Which traffic do you suspect is not caught?

(18 May '12, 02:50) SYN-bit ♦♦

Sorry,please forgive my english. I mean that when i use cmd"tshark -nn -i eth1 -t ad -R '(tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.dst<192.168.0.0 or ip.dst>192.168.255.255)'" The sniffer result is right. But when i use cmd"tshark -nn -i eth1 -t ad -f "tcp[13]&18=2 and not (dst net 192.168.0.0 mask 255.255.0.0)" I found the result is very less. I found the reson maybe caused by this capture "tcp[13]&18=2", can you tell me why? Thany you.

(18 May '12, 03:01) mastertu

As the filters should work the same (and they seem to do on my system), I'm very curious to see how the output differs. Can you start both commands and send me the some output that is missing from my command? Please also supply the exact commands that you used in the test.

(18 May '12, 03:12) SYN-bit ♦♦
[[email protected] data]# tshark -nn -i eth1 -t ad -R '(tcp.flags.syn == 1 and tcp.flags.ack == 0 and ip.dst<192.168.0.0 or ip.dst>192.168.255.255)'
Running as user "root" and group "root". This could be dangerous.
Capturing on eth1
2012-05-18 18:15:59.024477 192.168.50.111 -> 1.2.3.4      TCP 28728 > 82 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 TSV=3171436 TSER=0
2012-05-18 18:15:59.090329 192.168.15.15 -> 119.147.113.43 TCP 57546 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:15:59.123530 192.168.0.141 -> 74.125.71.157 TCP 52304 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186171229 TSER=0
2012-05-18 18:15:59.125058 192.168.0.112 -> 220.181.112.34 TCP 61277 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460
2012-05-18 18:15:59.125632 192.168.0.112 -> 220.181.112.34 TCP 61278 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460
2012-05-18 18:15:59.377753 192.168.0.141 -> 74.125.71.157 TCP 52305 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186171485 TSER=0
2012-05-18 18:15:59.474241 192.168.0.141 -> 23.21.171.71 TCP 52306 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186171576 TSER=0
2012-05-18 18:15:59.483072 192.168.0.141 -> 107.22.194.172 TCP 52307 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186171584 TSER=0
2012-05-18 18:15:59.529752 192.168.13.111 -> 119.147.113.117 TCP 54843 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
2012-05-18 18:15:59.531222 192.168.0.170 -> 218.30.111.182 TCP 38563 > 25 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:15:59.601367 192.168.50.118 -> 1.2.3.4      TCP 49536 > 82 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=2
2012-05-18 18:15:59.640381 192.168.13.137 -> 119.147.113.98 TCP 51584 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
2012-05-18 18:15:59.661852 192.168.0.186 -> 125.64.93.204 TCP 50175 > 65532 [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=3053589858 TSER=0 WS=6
2012-05-18 18:15:59.779664 192.168.15.140 -> 119.147.113.105 TCP 59062 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:15:59.785710 192.168.11.22 -> 1.2.3.4      TCP 55089 > 82 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:15:59.869167 192.168.50.111 -> 119.147.113.104 TCP 28729 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2 TSV=3171520 TSER=0
2012-05-18 18:16:00.004662 192.168.50.119 -> 119.147.113.104 TCP 2729 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=0
2012-05-18 18:16:00.095211 192.168.18.12 -> 119.147.113.98 TCP 62265 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
2012-05-18 18:16:00.148128 192.168.0.141 -> 58.83.170.244 TCP 52308 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186172241 TSER=0
2012-05-18 18:16:00.152433 192.168.0.141 -> 58.83.170.244 TCP 52309 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186172245 TSER=0
2012-05-18 18:16:00.323979 192.168.15.15 -> 119.147.113.43 TCP 57547 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:16:00.375384 192.168.12.103 -> 183.60.136.64 TCP 52733 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:16:00.490977 192.168.50.124 -> 183.60.9.160 TCP 56100 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:16:00.508177 192.168.90.18 -> 58.58.58.58  TCP 2020 > 1604 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2012-05-18 18:16:00.618612 192.168.0.141 -> 63.141.192.120 TCP 52310 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186172698 TSER=0
2012-05-18 18:16:00.631318 192.168.0.141 -> 63.141.192.120 TCP 52311 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186172707 TSER=0
2012-05-18 18:16:00.650815 192.168.0.141 -> 63.141.192.120 TCP 52312 > 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=4 TSV=186172726 TSER=0
2012-05-18 18:16:00.770647 192.168.0.232 -> 121.14.110.44 TCP 47859 > 80 [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=890135769 TSER=0 WS=6
2012-05-18 18:16:00.782544 192.168.18.14 -> 119.147.113.25 TCP 57899 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
2012-05-18 18:16:00.824439 192.168.30.142 -> 220.181.111.148 TCP 60162 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:16:00.852977 192.168.15.15 -> 119.147.113.43 TCP 57548 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:16:00.883222 192.168.12.113 -> 183.60.58.88 TCP 56490 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
2012-05-18 18:16:00.883225 192.168.12.113 -> 183.60.58.88 TCP 56489 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2
2012-05-18 18:16:00.933774 192.168.0.78 -> 221.123.176.120 TCP 4984 > 80 [SYN] Seq=0 Win=16384 Len=0 MSS=1460
2012-05-18 18:16:00.962308 192.168.15.15 -> 119.147.113.43 TCP 57549 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8
2012-05-18 18:16:00.982045 192.168.50.124 -> 220.181.181.223 TCP 56101 > 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=2

[[email protected] data]# tshark -nn -i eth1 -t ad -f "tcp[13]&18=2 and not (dst net 192.168.0.0 mask 255.255.0.0)"
Running as user "root" and group "root". This could be dangerous.
Capturing on eth1
2012-05-18 18:17:16.180467 192.168.90.18 -> 58.58.58.58  TCP 2024 > 1604 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2012-05-18 18:17:17.649489 192.168.90.14 -> 58.58.58.58  TCP 1073 > 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2012-05-18 18:17:19.148456 192.168.90.18 -> 58.58.58.58  TCP 2024 > 1604 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2012-05-18 18:17:20.554775 192.168.90.14 -> 58.58.58.58  TCP 1073 > 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2012-05-18 18:17:25.164211 192.168.90.18 -> 58.58.58.58  TCP 2024 > 1604 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2012-05-18 18:17:26.570437 192.168.90.14 -> 58.58.58.58  TCP 1073 > 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2012-05-18 18:17:37.399896 192.168.90.18 -> 58.58.58.58  TCP 2025 > 1604 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
2012-05-18 18:17:40.257794 192.168.90.18 -> 58.58.58.58  TCP 2025 > 1604 [SYN] Seq=0 Win=64240 Len=0 MSS=1460
(18 May ‘12, 03:18) mastertu

sorry,the format hasnt tab, can you give your email? I will send to your email,thans.</p></div><div id="comment-11135-info" class="comment-info"><span class="comment-age">(18 May '12, 03:20)</span> <span class="comment-user userinfo">mastertu</span></div></div><span id="11136"></span><div id="comment-11136" class="comment not_top_scorer"><div id="post-11136-score" class="comment-score"></div><div class="comment-text"><p>I just updated the format, no worries :-)</p><p>I think I know the problem, are there any vlan tagged frames? The capture filter only shows non-tagged frames. To include vlan-tagged frames, you can use:</p><pre><code>tshark -nn -i eth1 -t ad -f &quot;(tcp[13]&amp;18=2 and not (dst net 192.168.0.0 mask 255.255.0.0)) or (vlan and (tcp[13]&amp;18=2 and not (dst net 192.168.0.0 mask 255.255.0.0)))&quot;</code></pre></div><div id="comment-11136-info" class="comment-info"><span class="comment-age">(18 May '12, 03:25)</span> <span class="comment-user userinfo">SYN-bit ♦♦</span></div></div><span id="11138"></span><div id="comment-11138" class="comment not_top_scorer"><div id="post-11138-score" class="comment-score"></div><div class="comment-text"><p>yes, i have solve my question, thank you very much</p></div><div id="comment-11138-info" class="comment-info"><span class="comment-age">(18 May '12, 10:11)</span> <span class="comment-user userinfo">mastertu</span></div></div><span id="11143"></span><div id="comment-11143" class="comment not_top_scorer"><div id="post-11143-score" class="comment-score"></div><div class="comment-text"><p>hi，this time， the tshark crashed agfer 18 hours. whether the memory innst enough? my host has 8G memory

(19 May ‘12, 11:26) mastertu

Running out of memory is inevitable as tshark accumulates information on each packet. You should instead be using dumpcap for long-running captures…

(19 May ‘12, 15:03) helloworld

…as described in the OutOfMemory wiki:

Other tools


If Wireshark is running out of memory, that probably means that you’re letting it run for a very long time or you’re analyzing very large capture files. You may find that another tool does what you want better than Wireshark. Use dumpcap for long term capturing, it’s intended for this purpose, or see Tools for other tools which may be more suitable for the task.

(19 May ‘12, 15:04) helloworld

hi,i found another question, Please see the data,between 58.58.58.58 and TCP,there is two space But between the other dstip and TCP only has one space. I want make all of them one space, can you help me? Thank you.

(20 May ‘12, 20:30) mastertu

i delete the space by tr -s ' ‘

(20 May ‘12, 21:07) mastertu
showing 5 of 14 show 9 more comments