On 09/16/13 16:49, Guy Harris wrote:
On Sep 16, 2013, at 1:39 PM, Jeff Morriss wrote:
On 09/16/13 16:04, Guy Harris wrote:
On Sep 16, 2013, at 12:44 PM, Anders Broman wrote:
If we decide to have it default off perhaps we shouldn't default to write
User Datagram Protocol, Src Port: 6
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 typica
On Sep 16, 2013, at 1: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 thi
On 09/16/13 16:04, Guy Harris wrote:
On Sep 16, 2013, at 12:44 PM, Anders Broman 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:
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
On Sep 16, 2013, at 1:39 PM, Jeff Morriss wrote:
> On 09/16/13 16:04, Guy Harris wrote:
>>
>> On Sep 16, 2013, at 12:44 PM, Anders Broman 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: 1386
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 typica
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
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
On Sep 16, 2013, at 12:44 PM, Anders Broman 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?
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
> > wrote:
> >
> >> In serv_name_lookup() we call getservbyport() for ports not resolved in
> >> the IANA port list the function
> >> Seems quit
On 09/16/13 14:57, Guy Harris wrote:
On Sep 16, 2013, at 7:20 AM, Anders Broman 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*X
On Sep 16, 2013, at 7:20 AM, Anders Broman 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 m
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:Wi
Guy Harris 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
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 th
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
On Mon, 23 Apr 2012 11:56:52 -0600 Gerald Combs wrote
>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'
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 li
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 no
19 matches
Mail list logo
