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