https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4579
Summary: dissector for GigE-vision Control Protocol
Product: Wireshark
Version: SVN
Platform: All
OS/Version: All
Status: NEW
Severity: Enhancement
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: adrian@xxxxxxxxxxxxxx
Created an attachment (id=4398)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4398)
new GVCP dissector source file, to go alongside the others in epan/dissectors/
Build Information:
wireshark 1.3.4 (SVN Rev 32181 from /trunk)
Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.18.7, with GLib 2.22.4, with libpcap 1.0.0, with libz
1.2.3.4, with POSIX capabilities (Linux), without libpcre, with SMI 0.4.8, with
c-ares 1.7.0, with Lua 5.1, without Python, with GnuTLS 2.8.5, with Gcrypt
1.4.5, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Sep 1
2009), without AirPcap, with new_packet_list.
Running on Linux 2.6.32-trunk-686, with libpcap version 1.0.0, GnuTLS 2.8.5,
Gcrypt 1.4.5.
Built using gcc 4.4.3.
--
I have written a crude dissector of GigE-vision Control Protocol packets.
GVCP is part of the GigE-Vision interface (a closed standard) to so-called
industrial cameras which deliver uncompressed video (but are more or less just
expensive web-cams :-P).
see also: http://en.wikipedia.org/wiki/GigE_vision
The dissector was written as part of the opengigevision project:
http://gitorious.org/opengigevision
(where example libcap logs of GVCP conversations can be downloaded)
The dissector is based on traffic analysis alone, as the description of the
GVCP is accessible only to members of the Automated Imaging Association. The
resulting packet description is therefore certainly incomplete and/or
inaccurate.
It is in fact a bit preliminary to submit this dissector for inclusion into
wireshark, because I have neither re-read the submission guidelines to prop the
code up to wireshark's standards, nor tested it with random packets (I attach
the file nevertheless for the curious). I mainly wanted to know beforehand
whether there is any interest in such a dissector, knowing that in the present
state its packet analysis is just a wild guess, incomplete at best, and is
likely to remain that way (unless someone with access to the secret standard
helps out). I am willing to spend a little more time doing a few tests and
code-checking, but if the policy is not to include reverse-engineered protocol
exegesis anyway then I will spare my time - it works fine for me as it is.
In any case I would like to thank the wireshark developers for their fine job
not only with respect to the tool itself, but especially the documentation and
code for dissectors. I have never come across a project of this size where
adding an extension was such a pleasant experience: well written documentation,
simple template and hooks, helper functions, bits of sample code, everything to
get a dissector running in minutes and concentrate on the packet analysis
itself. Thank you!
Thanks in advance for any response,
regards,
Adrian Daerr
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
