ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] About transport name resolution with the new services file

From: Ulf Lamping <ulf.lamping@xxxxxx>
Date: Thu, 23 Aug 2007 19:29:49 +0200
Francois-Xavier Le Bail schrieb:
--- Richard van der Hoff <richardv@xxxxxxxxxxxxx>
wrote:
Perhaps it should just be more intelligent, and if
one port is < 1024 and the other isn't, just resolve the one less than
1024?

On the other hand that doesn't solve the problem in
the general case. I guess it would be nice to make a decision based on where the SYN comes from.

Why not the first solution for UDP and the second one
for TCP, even if that does not cover all the cases ?
Hi!

As the implementor of this change ...

First of all, I agree that the current implementation is not optimal, as lot's of ports are missinterpreted now. However, my very first target was to have these value to name resolvings available *at all*, as the former mechanism was pretty limited (depending on the platform used) and - also very annoying IMHO - leading to different results on different platforms.

Now we have the port resolving data available - but the problem of randomly chosen ports arises.

Your suggestion outlined above has two problems: it's hard to implement and it's also hard to understand: - It's hard to implement as the whole current name resolution implementation doesn't know anything about source or destination ports - and it will be hard to do the required changes. - It's also hard to understand as there are many assumptions/exceptions. I hate occasional misleading information even more than permanent one

Unless we have a way to *reliably* distinguish between randomly chosen and "assigned" ports - and I don't see a good way - I would just say: Keep It Simple!

I tend to simply add a Preference option to set the maximum port number to be resolved (independant of the protocol, to keep it simple). I'm not sure of the default value, will be a tradeoff between very conservative and modern values: 1023, 16383, 32767 or even 49151 might be reasonable (I don't really now) - we'll need to find a value here that helps the most of us.

Regards, ULFL

P.S: I'm wondering why this problem wasn't there already before. As reported, openSUSE 10.2 uses a more or less fresh version of port-numbers (the same we use now) for the /etc/services file, I was expecting that the getservbyport() function uses this file -> Wireshark on openSUSE 10.2 should had the exact same result before as we have now. Maybe getservbyport() also has a max port limit that it won't resolve any port number above X?!? Could someone with an openSUSE machine and some knowledge where to look can check against this assumption?