ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] dissector newbie needs some guidence..

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Kelly Byrd" <kbyrd-ethereal@xxxxxxxxxx>
Date: Wed, 11 Aug 2004 08:21:46 -0700 (PDT)
> Kelly Byrd said:
>> DAAP uses HTTP as a transport (on port 3689), the body of the
>> requests and repsonses are not plain text, but a simple tagged
>> format: 4 char tagname, followed by a 4 bytes length, then "length"
>> bytes of data. Some tags are containers, whose data portion is other
>> tags of the same format. DAAP messages will span segments, and
>> responses are often gzip encoded. There's a few specs around, and I'm
>> comfortable with code that deals with the format.
>>
>> How should I register my dissector? I looked at packet-ipp, which
>> registers as a sub-dissector of http. I also looked at packet-text-media
>> which appears to  be a system of registering dissectors as mime types,
>> like packet-gif (the content-type header for DAAP is application
>> /x-dmap-tagged).
>
> packet-text-media.c *uses* the system for registering dissectors as media

> It looks as if DAAP should register by port number rather than media type,
> as it doesn't use a standard HTTP port number, but *does* have a port
> number it uses, and doesn't use anything other than HTTP as a transport.

Thanks for the advice.

I've now got it coded up as http sub-dissector registered by port
(using packet-ipp as an example), so far so good. A few more questions:

- It looks as though the requests aren't identified as DAAP (I change
the protocol column, early in the dissection), on the responses. Could
this be because there isn't any data in the request body to pass to my
dissector? or something else?

- Are there (even ad-hoc) style guidelines on how the dissector should
output it's text? DAAP is a list of tags, some of which are containers
containing more tags. In practice, the recursion doesn't seem to go
more than a couple of levels. It feels like a subtree for each tag is
the right display. My concern is that a given response will
contain a lot of subtrees, is there any reason not to do this?

- Another subtee question. Is there any way to change the
text display based on whether or not a subtree is expanded?

Example:

Unexpanded tree:

+ Tag: asar (size:16, data: [Some Random Band])

expanded tree:
-Tag: asar
|-Size: 16
|-Data: Some Random Band