Wireshark-dev: Re: [Wireshark-dev] About transport name resolution with the new services file
From: Ulf Lamping <[email protected]>
Date: Thu, 23 Aug 2007 19:29:49 +0200
Francois-Xavier Le Bail schrieb:
--- Richard van der Hoff <[email protected]>
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?