[Wireshark-dev] Get follwing Packets in a protocol dissector
Hi! I am currently working on a protocol dissector for a protocol, which is based on XML. The protocol is spoken inside a TCP stream. I am using the libxml to parse single requests and responses. I choose libxml because i want to check, if the XML is valid and because i need to parse the protocol quite deep. this works very well for normal requests and responses which are usually only one packet long (so the XML is valid and i can parse it). if there is for example a very long request it is splitted into different packets and the xml in the first packet is invalid (because all the closing tags are missing). in the following packets i can't even regognize that this is my protocol because they don't start with my header. I searched the documentation and some other dissectors, if there is a mechanism to request the following packets of a tcp stream from wireshark to be able to parse the whole request. I was not able to find something on this topic (request/response tracking is not quite what i want) so i'd like to ask here now. I would be happy about some suggestions how i could solve this problem or shouldn't i do something like this? with kind regards Jan-Niklas Meier ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] RTP Muxing with compressed header
Hi Anders,
Its not there in the makefile.
For RTP muxing with compressed header. I have made some changes to
packet-nb_rtpmux.c as shown:
Change 1. (In dissect_nb_rtpmux.c)
if (rtpcompressdissector)
{
next_tvb = tvb_new_subset(tvb, offset+5,
MIN(tvb_length(tvb)-5-offset, length), length);
call_dissector(rtpcompressdissector, next_tvb, pinfo,
nb_rtpmux_tree);
}
else
{
proto_tree_add_item(nb_rtpmux_tree,
hf_nb_rtpmux_data, tvb, offset+5, length == 0 ?
-1:length, FALSE);
}
*
Change 2.
void
proto_reg_handoff_nb_rtpmux(void)
{
static gboolean inited = FALSE;
if (!inited) {
dissector_handle_t nb_rtpmux_handle;
/* Use new_create_dissector_handle() to indicate that dissect_nb_rtpmux()
* returns the number of bytes it dissected (or 0 if it thinks the packet
* does not belong to PROTONAME).
*/
nb_rtpmux_handle = new_create_dissector_handle(dissect_nb_rtpmux,
proto_nb_rtpmux);
dissector_add_handle("udp.port", nb_rtpmux_handle);
rtpcompressdissector = find_dissector("compress_rtp");
inited = TRUE;
}
}
And also written a new dissector function for RTP packets with compresssed
headers as shown below:
static int
dissect_compress_rtp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
/* Set up structures needed to add the protocol subtree and manage it */
proto_item *ti;
proto_tree *compress_rtp_tree;
/*Need to add some checks here.(Heuristics)*/
/* Make entries in Protocol column and info column on summary display */
col_set_str(pinfo->cinfo,COL_PROTOCOL,"Compress_RTP");
if(tree) {
unsigned int offset = 0;
/* Create displays subtree for the protocol */
//while()
guint16 timestamp, sequence_no;
ti =
proto_tree_add_item(tree,proto_compress_rtp,tvb,offset,-1,FALSE);
compress_rtp_tree = proto_item_add_subtree(ti,ett_compress_rtp);
proto_tree_add_item(compress_rtp_tree,hf_compress_rtp_sequence_no,tvb,offset,1,FALSE);
timestamp = tvb_get_ntohs(tvb,offset);
proto_tree_add_uint(compress_rtp_tree,hf_compress_rtp_timestamp,tvb,offset+1,2,FALSE);
proto_tree_add_item(compress_rtp_tree,hf_compress_rtp_data,tvb,offset+3,-1,FALSE);
return tvb_length(tvb);
}
Any feedback for the same.
Thanks
Sourabh Rathor
On Wed, Feb 10, 2010 at 4:58 PM, Anders Broman
wrote:
> Hi,
> ??? It's in the makefile, in my SVN tree, on the server...
> Are youi doing svn co http://anonsvn.wireshark.org/wireshark/trunk/wireshark ?
>
> /Anders
>
> --
> *From:* wireshark-dev-boun...@wireshark.org [mailto:
> wireshark-dev-boun...@wireshark.org] *On Behalf Of *Sourabh Rathor
> *Sent:* den 10 februari 2010 09:22
> *To:* Developer support list for Wireshark
> *Subject:* Re: [Wireshark-dev] RTP Muxing with compressed header
>
> Hi Anders,
>
> Thanks for your input. This file is not visible now in the latest trunks
> and in the trunks before. Is it removed ?
> Does it support the compression or just the muxing functionality ?
>
> Thanks In advance
> Sourabh Rathor
>
> On Wed, Feb 10, 2010 at 10:56 AM, Anders Broman wrote:
>
>> Hi,
>>
>> There is a basic dissector to expand on, packet-nb_rtpmux.c.
>>
>> Regards
>>
>> Anders
>>
>>
>> --
>>
>> *Från:* wireshark-dev-boun...@wireshark.org [mailto:
>> wireshark-dev-boun...@wireshark.org] *För *Sourabh Rathor
>> *Skickat:* den 10 februari 2010 05:43
>> *Till:* wireshark-dev@wireshark.org
>> *Ämne:* [Wireshark-dev] RTP Muxing with compressed header
>>
>>
>>
>>
>> Hi
>>
>> I am actually looking or designing a new dissector function for decoding
>> RTP MUXed streams with compressed headers. This is compliant to 3GPP TS
>> 29.414. Need some inputs to start working on the same. Please reply if any
>> body has any pointers for it.
>>
>>
>> Thanks
>> Sourabh Rathor
>>
>>
>> ___
>> Sent via:Wireshark-dev mailing list
>> Archives:http://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>> mailto:wireshark-dev-requ...@wireshark.org
>> ?subject=unsubscribe
>>
>
>
>
> --
> Sourabh Rathor
> Institute Of Informatics & Communication
> South Campus, Delhi University
>
> ___
> Sent via:Wireshark-dev mailing list
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
>
--
Sourabh Rathor
Institute Of Informatics & Communication
South Campus, Delhi University
___
Sent via:Wireshark-dev mailing list
Archive
Re: [Wireshark-dev] enum or #define?
Hi,
That would probably be #1.
This option makes verification against a protocol spec / RFC easiest,
also such values don't have to be sequential.
Thanks,
Jaap
Send from my iPhone
On 14 feb 2010, at 22:21, Kaul wrote:
> Which one is better?
> option 1:
> #define SSL_HND_HELLO_REQUEST 0
> #define SSL_HND_CLIENT_HELLO 1
> ...
>
> or perhaps, option 2:
> enum {
> SSL_HND_HELLO_REQUEST,
> SSL_HND_CLIENT_HELLO,
> };
> ...
>
> and then (in both cases):
>
> const value_string ssl_31_handshake_type[] = {
> { SSL_HND_HELLO_REQUEST, "Hello Request" },
> { SSL_HND_CLIENT_HELLO, "Client Hello" },
>
>
> ?
>
> TIA,
> Y.
>
> ___
> Sent via:Wireshark-dev mailing list
> Archives:http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [Wireshark-commits] rev31832: /trunk/epan/dissectors/ /trunk/epan/dissectors/:packet-sflow.c
On Wed, Feb 10, 2010 at 11:37:51PM +0100, Anders Broman wrote: > Well stating your doubts and position didn't take that long did it :-) > Still do you propose to revert the checkin I don't mind either way... > I thought the current version had merit over the old one, if not it should > be reverted. Well, the patch has its good and weak aspects - all in all with the bugfixing that already went into the new dissector we should leave it in - it seems to contain more improvements than regressions. ciao Joerg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] enum or #define?
Which one is better?
option 1:
#define SSL_HND_HELLO_REQUEST 0
#define SSL_HND_CLIENT_HELLO 1
...
or perhaps, option 2:
enum {
SSL_HND_HELLO_REQUEST,
SSL_HND_CLIENT_HELLO,
};
...
and then (in both cases):
const value_string ssl_31_handshake_type[] = {
{ SSL_HND_HELLO_REQUEST, "Hello Request" },
{ SSL_HND_CLIENT_HELLO, "Client Hello" },
?
TIA,
Y.
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark 1.2 on OSX-10.5-PowerPC
The Buildbot has detected a new failure of OSX-10.5-PowerPC on Wireshark 1.2. Full details are available at: http://buildbot.wireshark.org/trunk-1.2/builders/OSX-10.5-PowerPC/builds/40 Buildbot URL: http://buildbot.wireshark.org/trunk-1.2/ Buildslave for this Build: osx-10.5-ppc Build Reason: Build Source Stamp: 31879 Blamelist: gerald BUILD FAILED: failed rsync sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark 1.0 on OSX-10.5-ppc
The Buildbot has detected a new failure of OSX-10.5-ppc on Wireshark 1.0. Full details are available at: http://buildbot.wireshark.org/trunk-1.0/builders/OSX-10.5-ppc/builds/14 Buildbot URL: http://buildbot.wireshark.org/trunk-1.0/ Buildslave for this Build: osx-10.5-ppc Build Reason: Build Source Stamp: 31878 Blamelist: gerald BUILD FAILED: failed rsync sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark (development) on OSX-10.5-PowerPC
The Buildbot has detected a new failure of OSX-10.5-PowerPC on Wireshark (development). Full details are available at: http://buildbot.wireshark.org/trunk/builders/OSX-10.5-PowerPC/builds/1122 Buildbot URL: http://buildbot.wireshark.org/trunk/ Buildslave for this Build: osx-10.5-ppc Build Reason: Build Source Stamp: 31877 Blamelist: gerald BUILD FAILED: failed rsync sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] buildbot failure in Wireshark 1.0 on Windows-XP-x86
The Buildbot has detected a new failure of Windows-XP-x86 on Wireshark 1.0. Full details are available at: http://buildbot.wireshark.org/trunk-1.0/builders/Windows-XP-x86/builds/14 Buildbot URL: http://buildbot.wireshark.org/trunk-1.0/ Buildslave for this Build: windows-xp-x86 Build Reason: Build Source Stamp: 31878 Blamelist: gerald BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
