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? _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
