On Aug 9, 2012, at 2:46 AM, mman...@netscape.net wrote:
Fixed in r44370
Thanks!
Best regards
Michael
-Original Message-
From: Michael Tuexen michael.tue...@lurchi.franken.de
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Wed, Aug 8, 2012 5:47 pm
Subject:
Hi everybody,
there is a project at GitHub,
uncovering the protocol structure of Skype.
Currently only UDP is documented (there is also
a TCP component somehow).
https://github.com/matthiasbock/OpenSkype/wiki/Skype's-UDP-Format
Documentation is not completed, but quite far
and dissecting (and
Le jeudi 9 août 2012, Kumar, Chandan (Chandan) a écrit :
My request as follows:
Could you, please help me to make change in Wireshark so that I would be able
to select IE by means of filter like others element?
I want to make IE’s as a filterable field instead of displaying frame [start
Hi Matthias,
I'll admit that project sounds pretty cool - and I don't want to discourage
you from working on it; but I suspect that implementing that sort of
functionality in Wireshark might open a giant can of worms, legally.
(Especially since MS now own Skype's developers). ;)
Anyway, for
Hallo Matthias,
On Thu, Aug 09, 2012 at 10:47:56AM +0200, Matthias Bock wrote:
there is a project at GitHub,
uncovering the protocol structure of Skype.
Currently only UDP is documented (there is also
a TCP component somehow).
Joerg Mayer wrote:
Hallo Matthias,
On Thu, Aug 09, 2012 at 10:47:56AM +0200, Matthias Bock wrote:
there is a project at GitHub,
uncovering the protocol structure of Skype.
Currently only UDP is documented (there is also
a TCP component somehow).
On Thu, Aug 09, 2012 at 04:42:31PM +, etx...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=44384
From Jacob Nordgren and Rishie Sharma:
FP: fixed so hsdsch type 1 also uses communication context id
Added experimental conditional decryption
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Joerg Mayer
Sent: den 9 augusti 2012 21:33
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Kasumi code (Was: rev 44384: ... kasumi.h ...)
On Thu, Aug 09,
mm...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=44380
User: mmann
Date: 2012/08/09 06:59 AM
Log:
Make emem_tree_*32_array functions non-destructive.
With this change Valgrind issues many, many warnings as Wireshark starts:
==10126== Conditional
Does this patch help? If not, I would consider blaming guids_add_guid for not
initializing the key member of the emem_tree_key_t structure. Even though I
think either would be caught by the DISSECTOR_ASSERT_NOT_REACHED macro. Also,
are there warning for emem_tree_lookup32_array() as well?
Attached is a patch that iterates over the key data instead of using
recursion. Valgrind is happier with it but I'm not yet sure it functions
correctly.
On 8/9/12 1:33 PM, mman...@netscape.net wrote:
Does this patch help? If not, I would consider blaming guids_add_guid
for not initializing the
On Thu, Aug 09, 2012 at 09:49:31PM +0200, Jacob Nordgren wrote:
The reason the code isnt included is because it seems like the actual
algorithm is patented by Mitsubishi.
This was our source for this:
http://www.etsi.org/WebSite/OurServices/Algorithms/3gppalgorithms.aspx
I only see claims
On Thu, Aug 09, 2012 at 09:53:48PM +0200, Anders Broman wrote:
Sorry I'm not sure what you are trying to say here:
What would cause problems would be using (and for all practical purposes)
the distribution of an *executable*
that uses the compiled code.
That would be Wireshark if the code
On Fri, Aug 10, 2012 at 12:26:04AM +0200, Joerg Mayer wrote:
No, as long as it is only included in source form, there should be no problem
(at least the Intel lawyers didn't see a problem with putting patentencumbered
source code into Mesa) as long as this feature is not compiled in by default
14 matches
Mail list logo
