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

Wireshark-dev: Re: [Wireshark-dev] Indicate [Generated] field on Display Filter Reference page

From: chuck c <bubbasnmp@xxxxxxxxx>
Date: Sat, 14 Nov 2020 17:59:28 -0600
Yes - that is a good example with tftp and makes sense.
But then, not to pick on tftp, are two filename fields needed?
There is no file rename in the protocol so it's the same file on both ends.
Looking at the Wiki samples (https://gitlab.com/wireshark/wireshark/-/wikis/SampleCaptures#tftp) the read example has both a source and destination file.
The write example only has a destination file.

Tangent question:
The numeric tftp opcode has "name resolution" done to a string description: 
  (tftp.opcode)     Opcode: Read Request (1)
SMTP does the same thing: 
  (smtp.response.code)  Response code: Requested mail action okay, completed (250)

But http breaks it into two fields:
  (http.response.code)   Status Code: 302
  (http.response.code.desc)  [Status Code Description: Found]

Is this a "it depends" where sometimes it's "shall" and other it's "should"?

If I add tftp.opcode as a column in the GUI, the text translation is displayed.
Query with tshark and it's the numeric value:
Downloads$ tshark -r ./tftp_wrq.pcap -T fields -e tftp.opcode | head -5
2
4
3
4
3

People (myself at the top of the list) are good at opening issues if it's a problem but I learn a lot from these style discussions.

Thanks!
chuckc



On Sat, Nov 14, 2020 at 4:43 PM John Thacker <johnthacker@xxxxxxxxx> wrote:
On Sat, Nov 14, 2020, 4:14 PM Guy Harris <gharris@xxxxxxxxx> wrote:

I.e., "generated" is a property of an instance of a field, not of a field; that's why the code sample you showed has a separate call to proto_item_set_generated().

That may not be the case for *all* fields that have generated instances, but there might be some fields that have both generated and non-generated instances.

For an example, take a look at packet-tftp.c

TFTP packets with the read request and write request opcodes contain a source or destination filename, respectively, and in those packets the corresponding fields are added without set_generated()

For packets with other opcodes, conversation tracking is used to add the source or destination filename, as appropriate, for the ongoing transfer, and there set_generated() is used because it's not actually in those packets.

John Thacker
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe