gmane.network.wireshark.devel

Re: [Wireshark-commits] rev 49425: /trunk/ /trunk/: manuf services

Gerald Combs — 2013-05-20T03:50:31

make-services.pl won't update the services file if its modification time
is more recent than IANA's version (which was the case here). I'll try
another run.

On 5/19/13 8:25 PM, Evan Huus wrote:

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: [Wireshark-commits] rev 49425: /trunk/ /trunk/: manuf services

Evan Huus — 2013-05-20T03:25:58

Okay, I just saw the commits. The other branches don't seem to have gotten
an updated services file though?


On Sun, May 19, 2013 at 11:21 PM, Gerald Combs <gerald-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org> wrote:

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: [Wireshark-commits] rev 49425: /trunk/ /trunk/: manuf services

Gerald Combs — 2013-05-20T03:21:45

I mananged to introduce a bug after adding updates for usb.c. It's
hopefully fixed now.

On 5/19/13 6:53 PM, Evan Huus wrote:

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: [Wireshark-commits] rev 49425: /trunk/ /trunk/:manuf services

Evan Huus — 2013-05-20T01:53:05

Gerald, is the server responsible for this having problems?


On Sun, May 19, 2013 at 9:51 PM, <eapache-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org> wrote:

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: COTP dissector problems

2013-05-19T16:01:48

#3 appears to be bug 7393 (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7393) in bugzilla.  If you feel the others are bugs (or enhancements), add them to bugzilla (https://bugs.wireshark.org/bugzilla/) so the issues don't get lost.  Of course, patches with fixes for those bugs/enhancements are welcome too ;)

Michael 

-----Original Message-----
From: Daniele Pala <pala.daniele-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>
To: wireshark-dev <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Sent: Sun, May 19, 2013 11:35 am
Subject: [Wireshark-dev] COTP dissector problems

Hello, I've written a simple RFC 1006 implementation (https://github.com/danielePala/tosi) and used Wireshark to monitor the generated traffic. I'm seeing some problems, I attach a capture file to illustrate them, generated by the test cases of my implementation:

1. A lot of packets are marked as malformed, with reference to the T.125 protocol (which I never intended to implement). See, for example, packet number 4 of the capture file.

2. It seems that the ER (error) TPDU is not recognized, see packet number 26 for example.

3. RFC 1006 defines a non-standard TPDU to support expedited data (see page 14 of the standard, http://tools.ietf.org/html/rfc1006), but this is not recognized, see packet number 132 for example. 

Of course, the attached capture file can be also generated by re-running the tests of my package. 

NOTE: I'm using Wireshark 1.8.2 shipped with Debian Wheezy, however, in the changelogs of the more recent versions I haven't found mentions to these issues, so I suppose they are still there.

Best regards,
Daniele Pala 

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

COTP dissector problems

Daniele Pala — 2013-05-19T12:38:04

Hello, I've written a simple RFC 1006 implementation (
https://github.com/danielePala/tosi) and used Wireshark to monitor the
generated traffic. I'm seeing some problems, I attach a capture file to
illustrate them, generated by the test cases of my implementation:

1. A lot of packets are marked as malformed, with reference to the T.125
protocol (which I never intended to implement). See, for example, packet
number 4 of the capture file.

2. It seems that the ER (error) TPDU is not recognized, see packet number
26 for example.

3. RFC 1006 defines a non-standard TPDU to support expedited data (see page
14 of the standard, http://tools.ietf.org/html/rfc1006), but this is not
recognized, see packet number 132 for example.

Of course, the attached capture file can be also generated by re-running
the tests of my package.

NOTE: I'm using Wireshark 1.8.2 shipped with Debian Wheezy, however, in the
changelogs of the more recent versions I haven't found mentions to these
issues, so I suppose they are still there.

Best regards,
Daniele Pala
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

GSOC Project:Process information

kunal bansal — 2013-05-19T13:36:54

based on post
http://www.wireshark.org/lists/wireshark-dev/201305/msg00039.html
&
http://www.wireshark.org/lists/wireshark-dev/201305/msg00118.html

i got to know that the implementation has already been done in linux but we
have to devise a UI via wireshark for the same

Besides For *Windows*:
honeevent can also be implemented using  winpcap
though using netshdump (which works via ETW, a good realtime support)works
great to create a log file but it doesn't seems an option because it uses
higher administrative rights.
So if we really want to realtime access we need to make a script using ETW
on windows.

hone_notify can work as it is
.

FOR* Mac OSX*

As mentioned in my proposal,using dtrace scripts is a nice option.

conntrack DTrace script for Solaris and Opensolaris to monitor all outgoing
TCP and UDP connections by process, user and port.

It has some filtering capabilities allowing to filter traffic by port,
process or user.


https://github.com/kunalbansal16/demo/blob/master/wiresharkdemo/mac%20os/dtrace/conntrack.d

Regards,
Kunal Bansal
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: [Wireshark-commits] rev 49380: /trunk-1.8/ /trunk-1.8/epan/dissectors/: packet-amr.c packet-tcp.c /trunk-1.8/docbook/: release-notes.xml /trunk-1.8/epan/: tvbuff.c

Jeff Morriss — 2013-05-17T17:31:39

Oops, yeah, that's a good point.  But, you're also right that it 
certainly won't hurt.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: [Wireshark-commits] rev 49380: /trunk-1.8/ /trunk-1.8/epan/dissectors/: packet-amr.c packet-tcp.c /trunk-1.8/docbook/: release-notes.xml /trunk-1.8/epan/: tvbuff.c

Evan Huus — 2013-05-17T16:37:29


I don't think this one was necessary in 1.8, since it doesn't have Jakub's
work on shrinking the ep scope that I remember, but it won't hurt.

Evan
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Wireshark 1.6.7 Memory Corruption

gobejishvili — 2013-05-17T12:01:54

Hello,

 I'm Security Researcher, found memory corruption vulnerability in
Wireshark 1.6.7 version 64BIT, vulnerability detect to kubuntu x64. Drag
and drop can to make memory corruption.
After running it in GDB.

Program received signal SIGSEGV, Segmentation fault.
0x000055555568527f in dnd_open_file_cmd ()
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: Info for Sharkfest'13

Ahmed Elshaer — 2013-05-17T12:03:09

ya me too , i'm from egypt and cant attend i hope it would be online
sessions


On Fri, May 17, 2013 at 1:38 PM, Edwin Abraham <edwin.abraham12-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>wrote:

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Info for Sharkfest'13

Edwin Abraham — 2013-05-17T11:38:57

Is there any session that will be held in a online sense.
I am interested in attending. But I won't be able to come due to the
distance.

Re: Sharkfset '13 - Hackfest

Ahmed Elshaer — 2013-05-17T11:38:19

i have a question how to make the GUI fast to render the data and never
hand or give u not responding ?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Sharkfset '13 - Hackfest

Anders Broman — 2013-05-17T11:00:05

Hi,
If anyone is participating in the Hackfest it might be a good idea to start discussion on topics of interest in case preparations are needed.

-          Bug fixing.

-          New features ( How to implement, not I would like to have this developed by someone else ( well that's OK too but don't expect it to actually happen :) ).

-          Dissector development.

-          Knowledge sharing, how to .... ( debug, profile ...)

-          Qt

-          High speed capturing on standard servers.

-          Scripting data collection.

-          Managing proprietary Wireshark extensions.

-          ?

People new to Wireshark development should try to have their build environments set up before arriving, ask here if you have problems.

Regards
Anders
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: Tapping Behaviour [Was: Export PDU:s]

Evan Huus — 2013-05-16T18:59:03



So it looks like we already basically do what I was suggesting. The bug was
a special case of inter-tap dependencies. Using a frame-end routine might
make for a simpler fix than all the manual try-catch blocks though.

Evan
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: Tapping Behaviour [Was: Export PDU:s]

Jeff Morriss — 2013-05-16T18:45:33

[Without having read either bug recently and without having ever really 
looked at tapping--so beware of glaring ignorance on my part...]

Would it make any sense to do call the tap in a frame-end routine 
(register_frame_end_routine())?  That's another way to handle exceptions 
without having to catch them.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Code sharing between TLS and DTLS

Hauke Mehrtens — 2013-05-15T15:02:24

The DTLS rfc6347 describes just the differences to tls (ssl) and these
two protocols are very similar. Currently the wireshark dissectors for
tls and dtls are not sharing much code, just at little in ssl-utils.c.

I did some improvements for the DTLS dissector and much of this was
copying the code from tls and doing some small modifications to it. I
would like to place more code like the parsing of a some handshake
messages to ssl-utils.c, so the code is shared between the dissectors.
At first I want to copy dissect_ssl3_hnd_cert_req() to ssl-utils.c and
use it also in dtls. What is the best way to do this? Are there any
examples? I saw that a similar thing was done with the x509 certificates
in the tls handshake.

Hauke
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: New icon as seen over rdesktop

Jeff Morriss — 2013-05-16T13:57:20

Yep, you're right.  Following the instructions here:

http://blog.dhampir.no/content/remote-desktop-does-not-support-colour-depth-24-falling-back-to-16

Gave me 24-bit color and now the jagged edge is gone.


Yeah, as I said, just wanted to mention it...

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: recent fuzz failures

Evan Huus — 2013-05-16T02:02:56

I have also been unable to reproduce any but the out-of-memory issues.

Evan

On Wed, May 15, 2013 at 9:43 PM, Jeff Morriss <jeff.morriss.ws-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

recent fuzz failures

Jeff Morriss — 2013-05-16T01:43:04

Hi Gerald,

The fuzz bot has been failing every single build recently.  The failures 
related to source capture 10749-test.pcapng.gz make sense to me: I can 
reproduce the out-of-memory condition which is reported in bug 6898. 
But I can't reproduce any of the others and yet the buildbot is 
consistently reporting seg-faults.

Can any problems with those captures be reproduced on the buildbot 
itself?  Can anyone else find a problem with these fuzz'd captures?

Regards,
-Jeff
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe

Re: filter packets

Guy Harris — 2013-05-15T22:54:37

On May 15, 2013, at 3:19 PM, Ahmed Elshaer <a.n.elshaer-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote:


Unfortunately, the filtering that can be done with BPF (which is what tcpdump and Wireshark use for capture filtering) is limited in what it can do (by design - it's done by running an interpreted or JIT-compiled program in the kernel, and, to prevent infinite loops being run in the kernel, loops are not allowed, and there is no "search for a string" instruction).

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request-IZ8446WsY0/dtAWm4Da02A< at >public.gmane.org?subject=unsubscribe