Wireshark-dev: Re: [Wireshark-dev] About transport name resolution with the new services file
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?
