Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 6153] Wireshark plugin for CSG2 R6 interface.

Date: Mon, 14 Nov 2011 00:26:38 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6153

--- Comment #23 from Asmita <adeenesh@xxxxxxxxx> 2011-11-14 00:26:37 PST ---
(In reply to comment #21)
> > It seems I'm missing a proper conversion from plugin dissector to builtin
> > dissector conversion. I tried to find the guidelines for built-in dissector on
> > wireshark.org but there is coding guidelines given for plugin dissector but I
> > failed to find any detailed guide steps for built-in dissector. Can you please
> > share any document guide for coding of built-in dissector. 
> 
> There is no difference in how to code the dissection code between a built in
> dissector and a plugin, see README.developer for advice on how to code and look
> at other dissectors.
> 
> > I'm still unable to understand this comments "use the dissector table for CDR:s
> > in packet-gtp.c". Please share some guidelines for builtin dissector, it will
> > help me to understand the format. 
> > 
> > Thanks
> 
> I'm assuming that Cisco implements the GTP part according to 3GPP Specification
> 3GPP TS 29.060 and as there allready exists a GTP dissctor (packet-gtp.c) there
> s no need to duplicate that part. Using the trace included in
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5972
> selecting packet 305 and doing "decode as" GTP the packet dissects as
> 
> No.     Time                       Source                Destination          
> Protocol Info
>     305 2011-05-20 04:49:09.275221 10.0.43.18            10.0.43.182          
> GTP      Data record transfer request
> 
> Frame 305: 437 bytes on wire (3496 bits), 437 bytes captured (3496 bits)
> Ethernet II, Src: Cisco_4d:97:ec (00:23:33:4d:97:ec), Dst: D-Link_a7:95:c3
> (00:1e:58:a7:95:c3)
> Internet Protocol Version 4, Src: 10.0.43.18 (10.0.43.18), Dst: 10.0.43.182
> (10.0.43.182)
> User Datagram Protocol, Src Port: 6000 (6000), Dst Port: 6666 (6666)
> GPRS Tunneling Protocol
>     Flags: 0x0f
>     Message Type: Data record transfer request (0xf0)
>     Length: 389
>     Sequence number: 0x04e3
>     Packet transfer command: Send data record packet (1)
>     Data record packet
>         Length: 384
>         Number of data records: 4
>         Data record format: 49 Proprietary or un documented format
> 
> Which looks ok.
> 
> Packet-gtp.c register
> register_dissector_table("gtp.cdr_fmt", "GTP DATA RECORD TYPE", FT_UINT16,
> BASE_DEC);
> 
> You coud register in this table for data record type 49(which could be a
> preference) by doing
> dissector_add_uint("gtp.cdr_fmt", 49, proto_hsndle_foo);
> proto_habdle_foo beeing the handle of your dissector.
> 
> Hmm looking at the GTP code that might currently not work but should be fixed
> in the GTP dissector.
> Regards
> Anders

Hi Anders,

I agree for the use of packet-gtp.c to decode gtp protocol but I cannot decode
some Cisco specific tlvs with this way. That is the only reason of packet-csg
code. As this code is to decode specific tlvs so I did complete protocol and
tlv decoding in separate file (packet-csg.c), though it was decoding the gtp
protocol. I think it will not be reasonable to add specific tlvs to
(packet-gtp.c) standard code. Here I want your input, how can I add this
specific tlv decoding code to wireshark source code ? as built-in dissector or
plugin dissector?

Thanks
Asmita

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.