Stephen Fisher wrote:
On Fri, Mar 28, 2008 at 11:06:25AM -0000, Keith French wrote:
In recent versions of Wireshark this behaviour seems to have changed,
in that it tries to resolve the source port of the SYN as well. The
name it resolves it to (on my PC anyway) is often misleading:-
qsnet-trans > http [SYN]
This is because we now ship Wireshark with a full services file (port to
name mapping) from the IANA. Windows has one built-in, but it is much
shorter than the one we now use.
...and, if Microsoft were to decide to add more entries to their
services file, you'd have exactly the same problem.
Furthermore, people on at least some UN*Xes already have this problem,
regardless of *what* version of Wireshark they run:
$ egrep qsnet-trans /etc/services
qsnet-trans 4354/udp # QSNet Transmitter
qsnet-trans 4354/tcp # QSNet Transmitter
and there's no good reason why this is only an issue for Windows users.
This means that not shipping the new services file is *not* a correct
solution to the problem:
1) it doesn't protect you against Microsoft adding those entries;
2) it doesn't do anything for UN*X users.
Not unless you want to turn off port name lookups hroughout Wireshark,
which can be done in the Name Resolution preferences (transport name
resolution).
If this is a serious problem, perhaps we could either supply two
services files, or flag entries in services files, so we could
distinguish between "common" and "uncommon" well-known port numbers - or
just distinguish between "well-known" ports (0-1023) and "registered"
ports (1024-49151) - and have an option to resolve only "common" or
"well-known" ports or to resolve "uncommon" or "registered" ports along
with those.