Re: [Wireshark-dev] Transport name resolution
On 09/16/13 16:49, Guy Harris wrote:
On Sep 16, 2013, at 1:39 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
On 09/16/13 16:04, Guy Harris wrote:
On Sep 16, 2013, at 12:44 PM, Anders Broman a.bro...@bredband.net wrote:
If we decide to have it default off perhaps we shouldn't default to write
User Datagram Protocol, Src Port: 6 (6), Dst Port: 13868 (13868) but
rather
User Datagram Protocol, Src Port: 6 , Dst Port: 13868
Yes, and the same applies for network addresses, if we're not already doing
that.
Defaulted to off (i.e., a preference) or off by code?
I was thinking off by code, i.e. stay away from the Department of Redundancy
Department.
If we have a preference (for services or network addresses) I think keeping the
same format:
User Datagram Protocol, Src Port: 6 (6), Dst Port: 13868 (13868)
is actually a good thing because then tshark output parsers don't have to worry
about whether or not the preference is set.
TShark output parsers not made of neurons should probably be parsing -T
{psml,pdml,fields} output. (TShark output parsers made of neurons generally handle
ambiguities and format differences a lot better than TShark output parsers made of code.)
Yes, I that's true.
But I can, without thinking, write up a quick script that pulls the
things I need out of the normal tshark -V output. The times (or
time?) I tried to extract data from a *ml format I spent hours trying
to figure out how and where to *start*. Eventually I gave up.
I think others have had the same problem which is why every
tshark-output-reading script I personally know of parses the -V output.
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Transport name resolution
Hi, In serv_name_lookup() we call getservbyport() for ports not resolved in the IANA port list the function Seems quite expensive so my question is does it add any value or can I remove it? Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
On 09/16/13 14:57, Guy Harris wrote: On Sep 16, 2013, at 7:20 AM, Anders Broman anders.bro...@ericsson.com wrote: In serv_name_lookup() we call getservbyport() for ports not resolved in the IANA port list the function Seems quite expensive so my question is does it add any value or can I remove it? At least on UN*Xes, getservbyport() does one or more of: 1) look in /etc/services, which is probably based on a (possibly-out-of-date) version of, err, umm, the IANA port list; 2) query some network service to do a lookup - and that service is probably using its own database, based on a (possibly-out-of-date) version of, err, umm, the IANA port list. ... possibly with some modifications for local use. But I imagine the number of people who actually go through the trouble to run a customized service database to be sufficiently few that it's not worth slowing everyone else down for. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
On Mon, Sep 16, 2013 at 03:17:54PM -0400, Jeff Morriss wrote: On 09/16/13 14:57, Guy Harris wrote: On Sep 16, 2013, at 7:20 AM, Anders Broman anders.bro...@ericsson.com wrote: In serv_name_lookup() we call getservbyport() for ports not resolved in the IANA port list the function Seems quite expensive so my question is does it add any value or can I remove it? At least on UN*Xes, getservbyport() does one or more of: 1) look in /etc/services, which is probably based on a (possibly-out-of-date) version of, err, umm, the IANA port list; 2) query some network service to do a lookup - and that service is probably using its own database, based on a (possibly-out-of-date) version of, err, umm, the IANA port list. ... possibly with some modifications for local use. But I imagine the number of people who actually go through the trouble to run a customized service database to be sufficiently few that it's not worth slowing everyone else down for. It sounds for me as a good Preference option. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
On Sep 16, 2013, at 12:44 PM, Anders Broman a.bro...@bredband.net wrote: I got rid of getservbyport() and added reading of the local services file perhaps the read should be removed again? Local services file as in /etc/services on UN*X and its equivalent on Windows (C:\winnt\system32\drivers\etc\services?), or local services file as in the services file that's distributed as part of Wireshark? We should continue to use the latter; the aforementioned modifications for local use could be made to that file as well. I'm also wondering if service name resolution should be defaulted to off, I'm not convinced it's that useful. Using the IANA port list is the reason why we get people asking why, for example, they're seeing dssiapi traffic on their network, just because something happens to be using port 1265. (I picked that example somewhat at random, but we *do* get that asked at times.) Should we, instead, look the port number up in the tcp.port or udp.port (or sctp.port) dissector table and, if it finds a dissector handle, look up the short name of the protocol for that dissector handle and use that? That means that: 1) we're using the name Wireshark uses elsewhere for the protocol (e.g., DNS rather than domain); 2) if we don't have a dissector registered for that port, we don't show a protocol name (which is arguably a feature rather than a bug, as the traffic isn't necessarily for the protocol linked with the port number given in the IANA list, and this means that if we're not going to dissect the traffic as that protocol we're probably not going to claim it's that protocol, which I see as a Good Thing). If we decide to have it default off perhaps we shouldn't default to write User Datagram Protocol, Src Port: 6 (6), Dst Port: 13868 (13868) but rather User Datagram Protocol, Src Port: 6 , Dst Port: 13868 Yes, and the same applies for network addresses, if we're not already doing that. (Also, should it be User Datagram Protocol, Src Port: 6, Dst Port: DNS (53) rather than User Datagram Protocol, Src Port: 6, Dst Port: 53 (DNS) I could see arguments in both directions.) ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
Jeff Morriss skrev 2013-09-16 21:17: On 09/16/13 14:57, Guy Harris wrote: On Sep 16, 2013, at 7:20 AM, Anders Broman anders.bro...@ericsson.com wrote: In serv_name_lookup() we call getservbyport() for ports not resolved in the IANA port list the function Seems quite expensive so my question is does it add any value or can I remove it? At least on UN*Xes, getservbyport() does one or more of: 1) look in /etc/services, which is probably based on a (possibly-out-of-date) version of, err, umm, the IANA port list; 2) query some network service to do a lookup - and that service is probably using its own database, based on a (possibly-out-of-date) version of, err, umm, the IANA port list. ... possibly with some modifications for local use. But I imagine the number of people who actually go through the trouble to run a customized service database to be sufficiently few that it's not worth slowing everyone else down for. I got rid of getservbyport() and added reading of the local services file perhaps the read should be removed again? I'm also wondering if service name resolution should be defaulted to off, I'm not convinced it's that useful. If we decide to have it default off perhaps we shouldn't default to write User Datagram Protocol, Src Port: 6 (6), Dst Port: 13868 (13868) but rather User Datagram Protocol, Src Port: 6 , Dst Port: 13868 Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
Should we, instead, look the port number up in the tcp.port or udp.port (or sctp.port) dissector table and, if it finds a dissector handle, look up the short name of the protocol for that dissector handle and use that? I think this is more useful, since the dissector short name is typically used as the filter prefix. It is just confusing if slightly different strings are shown, because they come from some other list/database. -- --- Dirk Jagdmann http://cubic.org/~doj - http://llg.cubic.org ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
On Sep 16, 2013, at 1:39 PM, Jeff Morriss jeff.morriss...@gmail.com wrote:
On 09/16/13 16:04, Guy Harris wrote:
On Sep 16, 2013, at 12:44 PM, Anders Broman a.bro...@bredband.net wrote:
If we decide to have it default off perhaps we shouldn't default to write
User Datagram Protocol, Src Port: 6 (6), Dst Port: 13868 (13868)
but rather
User Datagram Protocol, Src Port: 6 , Dst Port: 13868
Yes, and the same applies for network addresses, if we're not already doing
that.
Defaulted to off (i.e., a preference) or off by code?
I was thinking off by code, i.e. stay away from the Department of Redundancy
Department.
If we have a preference (for services or network addresses) I think keeping
the same format:
User Datagram Protocol, Src Port: 6 (6), Dst Port: 13868 (13868)
is actually a good thing because then tshark output parsers don't have to
worry about whether or not the preference is set.
TShark output parsers not made of neurons should probably be parsing -T
{psml,pdml,fields} output. (TShark output parsers made of neurons generally
handle ambiguities and format differences a lot better than TShark output
parsers made of code.)
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
On 9/16/2013 4:15 PM, Dirk Jagdmann wrote: Should we, instead, look the port number up in the tcp.port or udp.port (or sctp.port) dissector table and, if it finds a dissector handle, look up the short name of the protocol for that dissector handle and use that? I think this is more useful, since the dissector short name is typically used as the filter prefix. It is just confusing if slightly different strings are shown, because they come from some other list/database. +1 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
On 09/16/13 16:04, Guy Harris wrote: On Sep 16, 2013, at 12:44 PM, Anders Broman a.bro...@bredband.net wrote: I got rid of getservbyport() and added reading of the local services file perhaps the read should be removed again? Local services file as in /etc/services on UN*X and its equivalent on Windows (C:\winnt\system32\drivers\etc\services?), or local services file as in the services file that's distributed as part of Wireshark? We should continue to use the latter; the aforementioned modifications for local use could be made to that file as well. I'm also wondering if service name resolution should be defaulted to off, I'm not convinced it's that useful. Using the IANA port list is the reason why we get people asking why, for example, they're seeing dssiapi traffic on their network, just because something happens to be using port 1265. (I picked that example somewhat at random, but we *do* get that asked at times.) Should we, instead, look the port number up in the tcp.port or udp.port (or sctp.port) dissector table and, if it finds a dissector handle, look up the short name of the protocol for that dissector handle and use that? That means that: 1) we're using the name Wireshark uses elsewhere for the protocol (e.g., DNS rather than domain); 2) if we don't have a dissector registered for that port, we don't show a protocol name (which is arguably a feature rather than a bug, as the traffic isn't necessarily for the protocol linked with the port number given in the IANA list, and this means that if we're not going to dissect the traffic as that protocol we're probably not going to claim it's that protocol, which I see as a Good Thing). If we decide to have it default off perhaps we shouldn't default to write User Datagram Protocol, Src Port: 6 (6), Dst Port: 13868 (13868) but rather User Datagram Protocol, Src Port: 6 , Dst Port: 13868 Yes, and the same applies for network addresses, if we're not already doing that. Defaulted to off (i.e., a preference) or off by code? If we have a preference (for services or network addresses) I think keeping the same format: User Datagram Protocol, Src Port: 6 (6), Dst Port: 13868 (13868) is actually a good thing because then tshark output parsers don't have to worry about whether or not the preference is set. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution
Should we, instead, look the port number up in the tcp.port or udp.port (or sctp.port) dissector table and, if it finds a dissector handle, look up the short name of the protocol for that dissector handle and use that? I think this is more useful, since the dissector short name is typically used as the filter prefix. It is just confusing if slightly different strings are shown, because they come from some other list/database. Actually, the dissector *filter* name is typically used as the filter prefix - for example, for DNS, there's: name - Domain Name Service short name - DNS filter name - dns Are you recommending using the filter name instead of the short name? yes, I prefer the filter name, because if I want to dig into a problem I'll likely use filters. I think for most dissectors short and filter name just differ in capitalization and my brain typically wouldn't notice any difference, so it may not make any big difference. Side note: it may be worthwhile to add a recommendation to the check-api program that short name and filter name should case insensitive compare equal. -- --- Dirk Jagdmann http://cubic.org/~doj - http://llg.cubic.org ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Transport name resolution considered harmful?
Wireshark has transport name resolution enabled by default. Unfortunately protocol numbers often get mapped to the wrong name, which can lead to confusion: https://ask.wireshark.org/questions/10380/what-is-commplex-main It seems like the services file has effectively become a list of things not running on the network. This is especially true for OSes that use the old-style (1024 - 4999) ephemeral port range. Is there any reason we shouldn't disable transport name resolution by default for the 1.8 release? -- Join us for Sharkfest ’12! · Wireshark® Developer and User Conference Berkeley, CA, June 24-27 · sharkfest.wireshark.org ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution considered harmful?
On Apr 23, 2012, at 10:56 AM, Gerald Combs wrote: Wireshark has transport name resolution enabled by default. Unfortunately protocol numbers often get mapped to the wrong name, which can lead to confusion: https://ask.wireshark.org/questions/10380/what-is-commplex-main It seems like the services file has effectively become a list of things not running on the network. As in a list of obscure old protocols that nobody remembers any more. :-) This is especially true for OSes that use the old-style (1024 - 4999) ephemeral port range. Is there any reason we shouldn't disable transport name resolution by default for the 1.8 release? Sounds good to me. It'd be interesting to see how many dissectors for stuff running atop TCP or UDP are old-fashioned dissectors registering for hardwired port numbers and how many either 1) have a port number/numbers preference; 2) are new-style dissectors that can say this might be for the port that's nominally mine, but it's not me; 3) are heuristic dissectors; and how often Decode As... is used to override whatever decision Wireshark makes. In the early days of TCP/IP, port numbers might have been useful protocol indicators; over time they've become less useful. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution considered harmful?
On Apr 23, 2012, at 11:11 AM, Stephen Fisher wrote: It still has useful matches including, but not limited to: ssh (22) domain (53) http (80) microsoft-ds (445) router (520) - (I know, scary RIP...) Note that we have dissectors for all of those (and that the names aren't the protocol names, e.g. domain rather than DNS, microsoft-ds rather than SMB, router rather than RIP). The issues are probably mostly with the protocols not used enough to have Wireshark dissectors. Perhaps we should, instead, have our own table of port numbers-protocol names. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution considered harmful?
On Mon, Apr 23, 2012 at 11:24:02AM -0700, Guy Harris wrote: Note that we have dissectors for all of those (and that the names aren't the protocol names, e.g. domain rather than DNS, microsoft-ds rather than SMB, router rather than RIP). The issues are probably mostly with the protocols not used enough to have Wireshark dissectors. Perhaps we should, instead, have our own table of port numbers-protocol names. A little off-topic: We could implement it as value_string and finally fix bug #594 o/ ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Transport name resolution considered harmful?
Guy Harris guy@... writes: Perhaps we should, instead, have our own table of port numbers-protocol names. In that case, would it make sense to add a preference to allow the user to choose either the current services file for the mapping or to use the Wireshark table? To help support proprietary/custom port mappings, it would be nice if it were possible for the user to edit that table. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
