It is just that in my organization, we have certain custom protocols whose
UDP port numbers are much more easily recognizeable in hex rather than in
decimal because the designer decided to be cute when choosing the port
numbers. But, I certainly understand that this may not be something that
applies or would be useful to the general community, as Micheal says,
because you can always read the hex from the original packet bytes.
- Chris
-----Original Message-----
From: ethereal-dev-bounces@xxxxxxxxxxxx
[mailto:ethereal-dev-bounces@xxxxxxxxxxxx] On Behalf Of Ulf Lamping
Sent: Friday, June 25, 2004 4:16 PM
To: Ethereal development
Subject: Re: [Ethereal-dev] UDP port display
Maynard, Chris wrote:
>If a given udp port does not have a name associated with it,
>epan/resolve.c:get_udp_port() simply returns a string containing the
decimal
>value of the port number. However, in that case, the udp dissector ends up
>displaying the decimal port value twice, as in "decimalport (decimalport)",
>in both the udp summary tree and the individual "Source port:" and
>"Destination port:" fields.
>
>Does anyone else like the idea of displaying something like
>"decimalport (hexport)" instead, or perhaps to make things simpler, it
could
>display "decimalport (decimalport/hexport)", so that even if the port names
>are displayed, you'll still get both decimal & hex displayed?
>
>
No, I don't like that idea.
TCP/UDP ports are commonly represented as a decimal value in programs
and documentation. Adding a hex value will make things confusing IMHO.
As Micheal noted, you can get the hex value from the "Packet Bytes" if
you need it.
Regards, ULFL
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
-----------------------------------------
This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. Also, email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof.
