ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Vines dissectors

From: Joerg Mayer <jmayer@xxxxxxxxx>
Date: Sat, 22 Sep 2012 08:56:38 +0200
[Cc-ing wireshark-dev]

Hello Michael,

On Fri, Sep 21, 2012 at 10:55:22AM -0400, mmann78@xxxxxxxxxxxx wrote:
> I want to remove some of the APIs from to_str.h to encourage (force) more itemized filters. I'm starting with decode_boolean_bitfield(), and packet-vines.c seem to have large number of them.  They are fixed in the attached patch, but I wanted you're okay before committing it.

Sure. I won't be much help any more, as I created these patches in something
like December 1998 and they were released by Gerald in January 1999. I left
the company where we used Vines in 2000 and I can't even find any old traces.
The only traces I have are copyrighted files from the trace collection of
sniffer pro.

> I also noticed a few things while working on the dissector:
> 1. The second instance of hf_vines_ip_length (under is_broadcast) doesn't seem like it should be there.  Is that a bug?
> 2. Why are VINES_ADDR_LEN and tvb_vines_addr_to_str() public?  Shouldn't they be limited to packet-vines.c?  Are there proprietary dissectors not included in the Wireshark distribution that use it?  Otherwise I think they should just be rolled into packet-vines.c

I looked at the code several months ago (when we talked about _item-izing) and
it looked very strange to me. So strange that I decided it wasn't worth my time
reworking code from the bronze-age of Ethereal.
I have no idea why tvb_vines_addr_to_str etc are public. Either I did this
copying the mechanisms of ipx or appletalk, or it was (most probably) Guy who
created a consistent API to do the address handling for all the different
networking protocols. As nobody ever felt the need to dissect any Vines payload
there never was any need to access this stuff from another file.

Just go ahead with your work of bringing Vines into the modern times ;-)

Thanks
    Jörg

-- 
Joerg Mayer                                           <jmayer@xxxxxxxxx>
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.