Wireshark mailing list archives
Re: Wireshark-users Digest, Vol 59, Issue 12
From: Barry Constantine <Barry.Constantine () jdsu com>
Date: Fri, 15 Apr 2011 07:05:38 -0700
Hi jp, Any thoughts on the graphing / playback of the trace file I sent to the list? I can analyze with Wireshark UI, but the graphs appear to be empty. Thanks, Barry -----Original Message----- From: wireshark-users-bounces () wireshark org [mailto:wireshark-users-bounces () wireshark org] On Behalf Of wireshark-users-request () wireshark org Sent: Thursday, April 14, 2011 3:00 PM To: wireshark-users () wireshark org Subject: Wireshark-users Digest, Vol 59, Issue 12 Send Wireshark-users mailing list submissions to wireshark-users () wireshark org To subscribe or unsubscribe via the World Wide Web, visit https://wireshark.org/mailman/listinfo/wireshark-users or, via email, send a message with subject or body 'help' to wireshark-users-request () wireshark org You can reach the person managing the list at wireshark-users-owner () wireshark org When replying, please edit your Subject line so it is more specific than "Re: Contents of Wireshark-users digest..." Today's Topics: 1. Re: VoIP RTP Analysis, Lost Packet Analysis (Jake Peavy) 2. packets with capture length in Wireshark larger than configured MTU (Andrej van der Zee) 3. Re: packets with capture length in Wireshark larger than configured MTU (Andrej van der Zee) 4. Re: VoIP RTP Analysis, Lost Packet Analysis (RUOFF, LARS (LARS)** CTR **) 5. How to simultaneous capture packets from two different NIC on the same server (Boaz Galil) 6. Re: How to simultaneous capture packets from two different NIC on the same server (Lior Zarfati) 7. Re: LDAP dissector reports malformed filter in seach requests (v1.4.4) (Sladys) 8. Re: How to simultaneous capture packets from two different NIC on the same server (Stephen Fisher) 9. Re: LDAP dissector reports malformed filter in seach requests (v1.4.4) (Gerald Combs) ---------------------------------------------------------------------- Message: 1 Date: Wed, 13 Apr 2011 16:41:40 -0400 From: Jake Peavy <djstunks () gmail com> To: Community support list for Wireshark <wireshark-users () wireshark org> Subject: Re: [Wireshark-users] VoIP RTP Analysis, Lost Packet Analysis Message-ID: <BANLkTin1fUt7TzvB8oSM_qegfdM+qXL8Tw () mail gmail com> Content-Type: text/plain; charset="windows-1252" On Sat, Apr 9, 2011 at 9:20 PM, Jake Peavy <djstunks () gmail com> wrote:
On Sat, Apr 9, 2011 at 8:23 AM, Barry Constantine < Barry.Constantine () jdsu com> wrote:Hi, I am analyzing VoIP capture files in Wireshark 1.4 and am confused about the RTP analysis results. The jitter results match what I expect, but the packet loss results do not. I know for a fact that the file contains no packet loss and yet the RTP analysis screen reports all packets as lost ?negatively? (and gives an odd -100% value). Any ideas?Can you post a sample capture? <http://deepthoughtsbyjackhandey.com>
It looks ok to me, Barry. I'm not on the same version as you, but mine is
older.
You have to decode your stream as RTP, perhaps that's the missing step? At
least on my version the heuristics did not identify your stream as RTP.
$ tshark -v
TShark 1.2.1 (SVN Rev 29141)
Copyright 1998-2009 Gerald Combs <gerald () 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 with GLib 2.20.3, with WinPcap (version unknown), with libz 1.2.3,
without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8, with c-ares
1.6.0,
with Lua 5.1, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT Kerberos, with
GeoIP.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1
beta5
(packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS
2.8.1,
Gcrypt 1.4.4.
Built using Microsoft Visual C++ 9.0 build 30729
$ tshark -r VoIP_Communicator_Snippet.pcap -d"udp.port==50056,rtp" -qz
rtp,streams
========================= RTP Streams ========================
Src IP addr Port Dest IP addr Port SSRC Payload
Pkts Lost Max Delta(ms) Max Jitter(ms) Mean Jitter(ms) Problems?
102.1.145.163 50056 244.55.112.179 50048 0xABBCE50F Unknown(118)
1 0 (0.0%) 0.00 0.00 0.00
244.55.112.179 50048 102.1.145.163 50056 0x726E7E61 Unknown(118)
40 0 (0.0%) 0.00 0.00 0.00
==============================================================
--
-jp
Do you know what happens when you slice a golf ball in half? Someone gets
mad at you. I found this out the hard way.
deepthoughtsbyjackhandey.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.wireshark.org/lists/wireshark-users/attachments/20110413/2187d10b/attachment.html>
------------------------------
Message: 2
Date: Thu, 14 Apr 2011 09:38:39 +0900
From: Andrej van der Zee <andrejvanderzee () gmail com>
To: Community support list for Wireshark
<wireshark-users () wireshark org>
Subject: [Wireshark-users] packets with capture length in Wireshark
larger than configured MTU
Message-ID: <BANLkTimuYPsbbiUpoq+uqwcNFGRcBhuqeg () mail gmail com>
Content-Type: text/plain; charset=ISO-8859-1
Hi,
I am using Ubuntu Maverick (kernel 2.6.35-25) with the following
config for eth0:
eth0 Link encap:Ethernet HWaddr b8:ac:6f:99:6d:be
inet addr:85.17.148.22 Bcast:85.17.148.255 Mask:255.255.255.0
inet6 addr: fe80::baac:6fff:fe99:6dbe/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:126634506 errors:0 dropped:0 overruns:0 frame:0
TX packets:100914149 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88690663907 (88.6 GB) TX bytes:66274092073 (66.2 GB)
Interrupt:16 Memory:da000000-da012800
It sais MTU of 1500. When I capture in Wireshark I see packets which
are much larger than the 1500 (see below). I am wondering how this is
possible.
Thank you,
Andrej
No. Time Source Destination
Protocol Info
61 09:19:15.599088 85.17.148.22 175.105.93.20
HTTP HTTP/1.1 200 OK (application/x-amf)
Frame 61 (8478 bytes on wire, 8478 bytes captured)
Arrival Time: Apr 14, 2011 09:19:15.599088000
[Time delta from previous captured frame: 0.030731000 seconds]
[Time delta from previous displayed frame: 0.030731000 seconds]
[Time since reference or first frame: 14.020010000 seconds]
Frame Number: 61
Frame Length: 8478 bytes
Capture Length: 8478 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:http:media]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 ||
mstp.checksum_bad==1]
Ethernet II, Src: Dell_99:6d:be (b8:ac:6f:99:6d:be), Dst:
All-HSRP-routers_12 (00:00:0c:07:ac:12)
Destination: All-HSRP-routers_12 (00:00:0c:07:ac:12)
Address: All-HSRP-routers_12 (00:00:0c:07:ac:12)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
Source: Dell_99:6d:be (b8:ac:6f:99:6d:be)
Address: Dell_99:6d:be (b8:ac:6f:99:6d:be)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 85.17.148.22 (85.17.148.22), Dst:
175.105.93.20 (175.105.93.20)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 8464
Identification: 0xd304 (54020)
Flags: 0x02 (Don't Fragment)
0.. = Reserved bit: Not Set
.1. = Don't fragment: Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0x513e [correct]
[Good: True]
[Bad : False]
Source: 85.17.148.22 (85.17.148.22)
Destination: 175.105.93.20 (175.105.93.20)
Transmission Control Protocol, Src Port: http (80), Dst Port: 52787
(52787), Seq: 2671789300, Ack: 2723574492, Len: 8412
Source port: http (80)
Destination port: 52787 (52787)
[Stream index: 3]
Sequence number: 2671789300
[Next sequence number: 2671797712]
Acknowledgement number: 2723574492
Header length: 32 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 116
Checksum: 0x16a8 [incorrect, should be 0xbea6 (maybe caused by
"TCP checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[Expert Info (Error/Checksum): Bad checksum]
[Message: Bad checksum]
[Severity level: Error]
[Group: Checksum]
Options: (12 bytes)
NOP
NOP
Timestamps: TSval 474870612, TSecr 789164
[SEQ/ACK analysis]
[Number of bytes in flight: 8412]
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[Message: HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Response Code: 200
Date: Thu, 14 Apr 2011 00:19:15 GMT\r\n
Server: Apache/2.2.16 (Ubuntu)\r\n
Cache-Control: no-cache\r\n
Expires: Sat, 25 Dec 1999 00:00:00 GMT\r\n
Pragma: no-cache\r\n
Content-Length: 13087\r\n
[Content length: 13087]
Keep-Alive: timeout=15, max=97\r\n
Connection: Keep-Alive\r\n
Content-Type: application/x-amf\r\n
\r\n
Media Type
Media Type: application/x-amf (8129 bytes)
------------------------------
Message: 3
Date: Thu, 14 Apr 2011 14:29:39 +0900
From: Andrej van der Zee <andrejvanderzee () gmail com>
To: Andrej van der Zee <andrejvanderzee () gmail com>
Cc: Community support list for Wireshark
<wireshark-users () wireshark org>
Subject: Re: [Wireshark-users] packets with capture length in
Wireshark larger than configured MTU
Message-ID: <60C99A08-47AB-424F-8569-5B6903F6BE83 () gmail com>
Content-Type: text/plain; charset=us-ascii
Hi,
To answer my own question, and for others facing the same issue, this looks like large/generic receive offload to the
NIC and can be switched off with ethtool, although this will most likely result in higher CPU utilisation.
In my case it messes with my algorithm for reassembling TCP streams which relies on TCP seq and ack numbers, it seems.
Best regards,
Andrej
On 2011/04/14, at 9:38, Andrej van der Zee <andrejvanderzee () gmail com> wrote:
Hi,
I am using Ubuntu Maverick (kernel 2.6.35-25) with the following
config for eth0:
eth0 Link encap:Ethernet HWaddr b8:ac:6f:99:6d:be
inet addr:85.17.148.22 Bcast:85.17.148.255 Mask:255.255.255.0
inet6 addr: fe80::baac:6fff:fe99:6dbe/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:126634506 errors:0 dropped:0 overruns:0 frame:0
TX packets:100914149 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:88690663907 (88.6 GB) TX bytes:66274092073 (66.2 GB)
Interrupt:16 Memory:da000000-da012800
It sais MTU of 1500. When I capture in Wireshark I see packets which
are much larger than the 1500 (see below). I am wondering how this is
possible.
Thank you,
Andrej
No. Time Source Destination
Protocol Info
61 09:19:15.599088 85.17.148.22 175.105.93.20
HTTP HTTP/1.1 200 OK (application/x-amf)
Frame 61 (8478 bytes on wire, 8478 bytes captured)
Arrival Time: Apr 14, 2011 09:19:15.599088000
[Time delta from previous captured frame: 0.030731000 seconds]
[Time delta from previous displayed frame: 0.030731000 seconds]
[Time since reference or first frame: 14.020010000 seconds]
Frame Number: 61
Frame Length: 8478 bytes
Capture Length: 8478 bytes
[Frame is marked: False]
[Protocols in frame: eth:ip:tcp:http:media]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1
|| ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 ||
mstp.checksum_bad==1]
Ethernet II, Src: Dell_99:6d:be (b8:ac:6f:99:6d:be), Dst:
All-HSRP-routers_12 (00:00:0c:07:ac:12)
Destination: All-HSRP-routers_12 (00:00:0c:07:ac:12)
Address: All-HSRP-routers_12 (00:00:0c:07:ac:12)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
Source: Dell_99:6d:be (b8:ac:6f:99:6d:be)
Address: Dell_99:6d:be (b8:ac:6f:99:6d:be)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique
address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 85.17.148.22 (85.17.148.22), Dst:
175.105.93.20 (175.105.93.20)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 8464
Identification: 0xd304 (54020)
Flags: 0x02 (Don't Fragment)
0.. = Reserved bit: Not Set
.1. = Don't fragment: Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 64
Protocol: TCP (0x06)
Header checksum: 0x513e [correct]
[Good: True]
[Bad : False]
Source: 85.17.148.22 (85.17.148.22)
Destination: 175.105.93.20 (175.105.93.20)
Transmission Control Protocol, Src Port: http (80), Dst Port: 52787
(52787), Seq: 2671789300, Ack: 2723574492, Len: 8412
Source port: http (80)
Destination port: 52787 (52787)
[Stream index: 3]
Sequence number: 2671789300
[Next sequence number: 2671797712]
Acknowledgement number: 2723574492
Header length: 32 bytes
Flags: 0x10 (ACK)
0... .... = Congestion Window Reduced (CWR): Not set
.0.. .... = ECN-Echo: Not set
..0. .... = Urgent: Not set
...1 .... = Acknowledgement: Set
.... 0... = Push: Not set
.... .0.. = Reset: Not set
.... ..0. = Syn: Not set
.... ...0 = Fin: Not set
Window size: 116
Checksum: 0x16a8 [incorrect, should be 0xbea6 (maybe caused by
"TCP checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
[Expert Info (Error/Checksum): Bad checksum]
[Message: Bad checksum]
[Severity level: Error]
[Group: Checksum]
Options: (12 bytes)
NOP
NOP
Timestamps: TSval 474870612, TSecr 789164
[SEQ/ACK analysis]
[Number of bytes in flight: 8412]
Hypertext Transfer Protocol
HTTP/1.1 200 OK\r\n
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
[Message: HTTP/1.1 200 OK\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Version: HTTP/1.1
Response Code: 200
Date: Thu, 14 Apr 2011 00:19:15 GMT\r\n
Server: Apache/2.2.16 (Ubuntu)\r\n
Cache-Control: no-cache\r\n
Expires: Sat, 25 Dec 1999 00:00:00 GMT\r\n
Pragma: no-cache\r\n
Content-Length: 13087\r\n
[Content length: 13087]
Keep-Alive: timeout=15, max=97\r\n
Connection: Keep-Alive\r\n
Content-Type: application/x-amf\r\n
\r\n
Media Type
Media Type: application/x-amf (8129 bytes)
------------------------------
Message: 4
Date: Thu, 14 Apr 2011 09:24:59 +0200
From: "RUOFF, LARS (LARS)** CTR **" <lars.ruoff () alcatel-lucent com>
To: Community support list for Wireshark
<wireshark-users () wireshark org>
Subject: Re: [Wireshark-users] VoIP RTP Analysis, Lost Packet Analysis
Message-ID:
<23C6087F32FB3A43941E25922F87538E21E55BB6AB () FRMRSSXCHMBSA2 dc-m alcatel-lucent com>
Content-Type: text/plain; charset="us-ascii"
There's an issue indeed. Why is delta=0 for all packets in analysis?
Sorry, I don't have the time to look at the code right now.
Lars
________________________________
From: wireshark-users-bounces () wireshark org [mailto:wireshark-users-bounces () wireshark org] On Behalf Of Jake Peavy
Sent: mercredi 13 avril 2011 22:42
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] VoIP RTP Analysis, Lost Packet Analysis
On Sat, Apr 9, 2011 at 9:20 PM, Jake Peavy <djstunks () gmail com> wrote:
On Sat, Apr 9, 2011 at 8:23 AM, Barry Constantine <Barry.Constantine () jdsu com> wrote:
Hi,
I am analyzing VoIP capture files in Wireshark 1.4 and am confused about the RTP analysis results.
The jitter results match what I expect, but the packet loss results do not.
I know for a fact that the file contains no packet loss and yet the RTP analysis screen reports all
packets as lost "negatively" (and gives an odd -100% value).
Any ideas?
Can you post a sample capture? <http://deepthoughtsbyjackhandey.com>
It looks ok to me, Barry. I'm not on the same version as you, but mine is older.
You have to decode your stream as RTP, perhaps that's the missing step? At least on my version the heuristics did not
identify your stream as RTP.
$ tshark -v
TShark 1.2.1 (SVN Rev 29141)
Copyright 1998-2009 Gerald Combs <gerald () 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 with GLib 2.20.3, with WinPcap (version unknown), with libz 1.2.3,
without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8, with c-ares 1.6.0,
with Lua 5.1, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT Kerberos, with
GeoIP.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1 beta5
(packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS 2.8.1,
Gcrypt 1.4.4.
Built using Microsoft Visual C++ 9.0 build 30729
$ tshark -r VoIP_Communicator_Snippet.pcap -d"udp.port==50056,rtp" -qz rtp,streams
========================= RTP Streams ========================
Src IP addr Port Dest IP addr Port SSRC Payload Pkts Lost Max Delta(ms) Max
Jitter(ms) Mean Jitter(ms) Problems?
102.1.145.163 50056 244.55.112.179 50048 0xABBCE50F Unknown(118) 1 0 (0.0%) 0.00
0.00 0.00
244.55.112.179 50048 102.1.145.163 50056 0x726E7E61 Unknown(118) 40 0 (0.0%) 0.00
0.00 0.00
==============================================================
--
-jp
Do you know what happens when you slice a golf ball in half? Someone gets mad at you. I found this out the hard way.
deepthoughtsbyjackhandey.com
------------------------------
Message: 5
Date: Thu, 14 Apr 2011 15:39:54 +0300
From: Boaz Galil <boaz20 () gmail com>
To: Community support list for Wireshark
<wireshark-users () wireshark org>
Subject: [Wireshark-users] How to simultaneous capture packets from
two different NIC on the same server
Message-ID: <BANLkTinsRFcHMx+437d=Fv-OR+D6iDqCSA () mail gmail com>
Content-Type: text/plain; charset="iso-8859-1"
Dear experts,
On Windows server 2003 SP2, Is it possible to simultaneous capture packets
from two different NIC on the same server and if yes how? (Wire shark latest
version).
Thanks in advance,
Boaz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.wireshark.org/lists/wireshark-users/attachments/20110414/e94d8d86/attachment.html>
------------------------------
Message: 6
Date: Thu, 14 Apr 2011 12:49:52 +0000
From: Lior Zarfati <lior () g-s co il>
To: Community support list for Wireshark
<wireshark-users () wireshark org>
Subject: Re: [Wireshark-users] How to simultaneous capture packets
from two different NIC on the same server
Message-ID:
<913D21FA4B32674D93A4E6D16409E9287DDC1397@Regeneration.goffice.local>
Content-Type: text/plain; charset="us-ascii"
If you don't mind having a seperate log for each NIC, just run WireShark twice. Once for each NIC.
Lior.
________________________________
From: wireshark-users-bounces () wireshark org [wireshark-users-bounces () wireshark org] on behalf of Boaz Galil
[boaz20 () gmail com]
Sent: 14 April 2011 15:39
To: Community support list for Wireshark
Subject: [Wireshark-users] How to simultaneous capture packets from two different NIC on the same server
Dear experts,
On Windows server 2003 SP2, Is it possible to simultaneous capture packets from two different NIC on the same server
and if yes how? (Wire shark latest version).
Thanks in advance,
Boaz.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.wireshark.org/lists/wireshark-users/attachments/20110414/2f252b34/attachment.html>
------------------------------
Message: 7
Date: Thu, 14 Apr 2011 13:12:12 +0000 (UTC)
From: Sladys <sl4dy () gmx com>
To: wireshark-users () wireshark org
Subject: Re: [Wireshark-users] LDAP dissector reports malformed filter
in seach requests (v1.4.4)
Message-ID: <loom.20110414T151030-812 () post gmane org>
Content-Type: text/plain; charset=utf-8
I have experienced same issue on Wireshark 1.4.4. However 1.4.3 works fine.
<john_dale@...> writes:
Wireshark 1.4.4, reports malformed packet parsing filter in LDAP searchRequest.. ?Is this a bug, or something
------------------------------
Message: 8
Date: Thu, 14 Apr 2011 09:48:48 -0600
From: Stephen Fisher <steve () stephen-fisher com>
To: Community support list for Wireshark
<wireshark-users () wireshark org>
Subject: Re: [Wireshark-users] How to simultaneous capture packets
from two different NIC on the same server
Message-ID: <20110414154848.GB15828 () shadow stephen-fisher com>
Content-Type: text/plain; charset=us-ascii
On Thu, Apr 14, 2011 at 12:49:52PM +0000, Lior Zarfati wrote:
If you don't mind having a seperate log for each NIC, just run WireShark twice. Once for each NIC.
... or use dumpcap, which does nothing but capture and save to a file.
Then open each file separately to analyze it with Wireshark (or combine
them with mergecap)
------------------------------
Message: 9
Date: Thu, 14 Apr 2011 10:24:59 -0700
From: Gerald Combs <gerald () wireshark org>
To: Community support list for Wireshark
<wireshark-users () wireshark org>
Subject: Re: [Wireshark-users] LDAP dissector reports malformed filter
in seach requests (v1.4.4)
Message-ID: <4DA72DEB.4080709 () wireshark org>
Content-Type: text/plain; charset=UTF-8
This should be fixed in 1.4.5.
On 4/14/11 6:12 AM, Sladys wrote:
I have experienced same issue on Wireshark 1.4.4. However 1.4.3 works fine. <john_dale@...> writes:Wireshark 1.4.4, reports malformed packet parsing filter in LDAP searchRequest.. Is this a bug, or something___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
-- Join us for Sharkfest ?11! ? Wireshark? Developer and User Conference Stanford University, June 13-16 ? http://sharkfest.wireshark.org ------------------------------ _______________________________________________ Wireshark-users mailing list Wireshark-users () wireshark org https://wireshark.org/mailman/listinfo/wireshark-users End of Wireshark-users Digest, Vol 59, Issue 12 *********************************************** ___________________________________________________________________________ Sent via: Wireshark-users mailing list <wireshark-users () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-users Unsubscribe: https://wireshark.org/mailman/options/wireshark-users mailto:wireshark-users-request () wireshark org?subject=unsubscribe
Current thread:
- Re: Wireshark-users Digest, Vol 59, Issue 12 Barry Constantine (Apr 15)