On Sun, Jan 19, 2003 at 12:11:32PM +0200, Yaniv Kaul wrote:
> My question is, should we futher 'parse' this value (2, in this case),
> with the above description?
> In packet-isakmp.c, for example, almost any value is parsed. For
> example, instead of showing "Next payload: 3", it shows: "Next payload:
> Transform (3)".
The difference between packet-ftp.c and packet-isakmp.c, in this case,
is that in ISAKMP, that field is binary, so you can directly put the
value into the protocol tree as a registered field (in which case the
interpretation of the value is done automatically if the field has a
value_string table) or can directly pass it to "val_to_str()" if there
isn't a registered field for it, while in FTP, it's text, and the FTP
dissector currently just reports the command/response and argument as
text, and we'd have to add code to parse the number.
I.e., there's no philosophical reason why the FTP dissector doesn't
interpret it, it's just a question of what the dissector writer has
bothered doing.
It could be done in packet-ftp.c - you'd have to check the value of the
request command and, if it's EPSV, parse the value of the request
argument and:
if it's a valid number, use "val_to_str()" to get the
description and perhaps report it as
Address Family: 2 (IPv6)
or something such as that;
if it's not a valid number, report it as
Address Family: kdfkjalsjf (invalid)
or something such as that.