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

[Andrew Hood <ajhood@xxxxxxxxx>]

Richard van der Hoff wrote:
> On Sat, 18 Aug 2007, Francois-Xavier Le Bail wrote:
> 
> 
>>Hi List,
>>
>>In version 0.99.6 we have, by example :
>>Source   Destination   Protocol Info
>>10.0.0.2 62.210.65.158 TCP      3946 > http [ACK] ...
>>
>>In version 0.99.7-SVN-22549 we have :
>>Source   Destination   Protocol Info
>>10.0.0.2 62.210.65.158 TCP      backupedge > http
>>[ACK] ...
>>
>>The resolution from the new services file from IANA is
>>not relevant in such cases with random source port.
>>Perhaps this new resolution scheme should be optional.
> 
> 
> 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.

It it wasn't for Windows' broken behaviour in letting any port be
ephemeral, that might make some sense.

I have been forced to set registry values to make Windows behave more
like *nix. Reserve all ports below 32768. Make ephemerals be 32768-49151.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"ReservedPorts"=hex(7):31,00,2d,00,33,00,32,00,37,00,36,00,37,00,00,00,00,00
"MaxUserPort"=dword:0000bfff

Even that doesn't protect all "REGISTERED PORT NUMBERS". That would
require setting "ReservedPorts" to be 1-49151, and "MaxUserPort" to
something like 57344 (8192 available ephemerals) or 61440 (12288
available ephemerals).

-- 
There's no point in being grown up if you can't be childish sometimes.
                -- Dr. Who