Wireshark-users: Re: [Wireshark-users] Wireshark-users Digest, Vol 59, Issue 12
From: Barry Constantine <Barry.Constantine@xxxxxxxx>
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@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] On Behalf Of wireshark-users-request@xxxxxxxxxxxxx Sent: Thursday, April 14, 2011 3:00 PM To: wireshark-users@xxxxxxxxxxxxx Subject: Wireshark-users Digest, Vol 59, Issue 12 Send Wireshark-users mailing list submissions to wireshark-users@xxxxxxxxxxxxx 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@xxxxxxxxxxxxx You can reach the person managing the list at wireshark-users-owner@xxxxxxxxxxxxx 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@xxxxxxxxx> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx> Subject: Re: [Wireshark-users] VoIP RTP Analysis, Lost Packet Analysis Message-ID: <BANLkTin1fUt7TzvB8oSM_qegfdM+qXL8Tw@xxxxxxxxxxxxxx> Content-Type: text/plain; charset="windows-1252" On Sat, Apr 9, 2011 at 9:20 PM, Jake Peavy <djstunks@xxxxxxxxx> wrote: > On Sat, Apr 9, 2011 at 8:23 AM, Barry Constantine < > Barry.Constantine@xxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxx> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx> Subject: [Wireshark-users] packets with capture length in Wireshark larger than configured MTU Message-ID: <BANLkTimuYPsbbiUpoq+uqwcNFGRcBhuqeg@xxxxxxxxxxxxxx> 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@xxxxxxxxx> To: Andrej van der Zee <andrejvanderzee@xxxxxxxxx> Cc: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx> Subject: Re: [Wireshark-users] packets with capture length in Wireshark larger than configured MTU Message-ID: <60C99A08-47AB-424F-8569-5B6903F6BE83@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx> Subject: Re: [Wireshark-users] VoIP RTP Analysis, Lost Packet Analysis Message-ID: <23C6087F32FB3A43941E25922F87538E21E55BB6AB@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] 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@xxxxxxxxx> wrote: On Sat, Apr 9, 2011 at 8:23 AM, Barry Constantine <Barry.Constantine@xxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxx> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx> Subject: [Wireshark-users] How to simultaneous capture packets from two different NIC on the same server Message-ID: <BANLkTinsRFcHMx+437d=Fv-OR+D6iDqCSA@xxxxxxxxxxxxxx> 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@xxxxxxxxx> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx [wireshark-users-bounces@xxxxxxxxxxxxx] on behalf of Boaz Galil [boaz20@xxxxxxxxx] 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@xxxxxxx> To: wireshark-users@xxxxxxxxxxxxx Subject: Re: [Wireshark-users] LDAP dissector reports malformed filter in seach requests (v1.4.4) Message-ID: <loom.20110414T151030-812@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxx> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx> Subject: Re: [Wireshark-users] How to simultaneous capture packets from two different NIC on the same server Message-ID: <20110414154848.GB15828@xxxxxxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> To: Community support list for Wireshark <wireshark-users@xxxxxxxxxxxxx> Subject: Re: [Wireshark-users] LDAP dissector reports malformed filter in seach requests (v1.4.4) Message-ID: <4DA72DEB.4080709@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> > Archives: http://www.wireshark.org/lists/wireshark-users > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users > mailto:wireshark-users-request@xxxxxxxxxxxxx?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@xxxxxxxxxxxxx https://wireshark.org/mailman/listinfo/wireshark-users End of Wireshark-users Digest, Vol 59, Issue 12 ***********************************************
- Prev by Date: Re: [Wireshark-users] LDAP dissector reports malformed filter in seach requests (v1.4.4)
- Next by Date: [Wireshark-users] Broadcom BCM4312 supports mode monitor
- Previous by thread: Re: [Wireshark-users] LDAP dissector reports malformed filter in seach requests (v1.4.4)
- Next by thread: [Wireshark-users] Broadcom BCM4312 supports mode monitor
- Index(es):