[Wireshark-users] Summary View Info Column
When a TCP session is initialised or closed, the TCP SYN FIN handshakes shows the port numbers at the start of the Info column in the Summary view within Wireshark. This always used to take the format (in the case of a SYN) of the unresolved source port followed by the destination resolved port. So you might see something like:- 4000 http [SYN] In recent versions of Wireshark this behaviour seems to have changed, in that it tries to resolve the source port of the SYN as well. The name it resolves it to (on my PC anyway) is often misleading:- qsnet-trans http [SYN] I have looked in the preferences, but cannot find anywhere to force the info column to display this port unresolved (i.e. just it's port number). Is there a way to do this? Keith French.___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] Summary View Info Column
Keith French wrote: When a TCP session is initialised or closed, the TCP SYN FIN handshakes shows the port numbers at the start of the Info column in the Summary view within Wireshark. This always used to take the format (in the case of a SYN) of the unresolved source port followed by the destination resolved port. So you might see something like:- 4000 http [SYN] In recent versions of Wireshark this behaviour seems to have changed, in that it tries to resolve the source port of the SYN as well. The name it resolves it to (on my PC anyway) is often misleading:- qsnet-trans http [SYN] I have looked in the preferences, but cannot find anywhere to force the info column to display this port unresolved (i.e. just it's port number). Is there a way to do this? I know you use Windows. Assuming a recent enough version of Wireshark, there is a file called C:\Program Files\Wireshark\services Delete the lines for port numbers other than those services in which you are interested. Personally, I edit the registry and add these keys and values, so that Windows behaves more like Unix, and then no well-known ports get used as ephemerals.: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters] MaxUserPort=dword:bfff ReservedPorts=hex(7):31,00,34,00,33,00,33,00,2d,00,31,00,34,00,33,00,34,00,\ 00,00,31,00,30,00,32,00,35,00,2d,00,33,00,32,00,37,00,36,00,37,00,00,00,00,\ 00 In human readable form: MaxUserPort Type:REG_DWORD Data: bfff(hex) 49151(decimal) ReservedPorts Type: REG_MULTI_SZ Data: 1433-1434enter1025-32767 but that could be simplified to: ReservedPorts Type: REG_MULTI_SZ Data: 1025-32767 -- There's no point in being grown up if you can't be childish sometimes. -- Dr. Who ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
Re: [Wireshark-users] Summary View Info Column
Stephen Fisher wrote: On Fri, Mar 28, 2008 at 11:06:25AM -, Keith French wrote: In recent versions of Wireshark this behaviour seems to have changed, in that it tries to resolve the source port of the SYN as well. The name it resolves it to (on my PC anyway) is often misleading:- qsnet-trans http [SYN] This is because we now ship Wireshark with a full services file (port to name mapping) from the IANA. Windows has one built-in, but it is much shorter than the one we now use. ...and, if Microsoft were to decide to add more entries to their services file, you'd have exactly the same problem. Furthermore, people on at least some UN*Xes already have this problem, regardless of *what* version of Wireshark they run: $ egrep qsnet-trans /etc/services qsnet-trans 4354/udp# QSNet Transmitter qsnet-trans 4354/tcp# QSNet Transmitter and there's no good reason why this is only an issue for Windows users. This means that not shipping the new services file is *not* a correct solution to the problem: 1) it doesn't protect you against Microsoft adding those entries; 2) it doesn't do anything for UN*X users. Not unless you want to turn off port name lookups hroughout Wireshark, which can be done in the Name Resolution preferences (transport name resolution). If this is a serious problem, perhaps we could either supply two services files, or flag entries in services files, so we could distinguish between common and uncommon well-known port numbers - or just distinguish between well-known ports (0-1023) and registered ports (1024-49151) - and have an option to resolve only common or well-known ports or to resolve uncommon or registered ports along with those. ___ Wireshark-users mailing list Wireshark-users@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-users
