There was a discussion on this on tcpdump-workers about a
year ago; the worry was changing the output format in an
incompatible way for e.g. scripts that ran "tcpdump -n" and
matched against e.g. /(\d+\.\d+\.\d+\.\d+)\.(\d+) >
(\d+\.\d+\.\d+\.\d+)\.(\d+)/ .
One option is to reverse the meanings, i.e. "-n" stays the
same and "-nn" means "resolve ports but not IP addresses"
(or "do any lookups that don't take any time", which may be
a nice semantic but may not be possible to know, e.g.
tcpdump may not know if ether_ntohost() is going to just
look in /etc/ethers or is going to look in NIS.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Administrators of the "tcpdump" SourceForge project have superseded this tracker item (formerly artifact 573130, now patch 5) with issue 162 of the "tcpdump" GitHub project.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=109593
There was a discussion on this on tcpdump-workers about a
year ago; the worry was changing the output format in an
incompatible way for e.g. scripts that ran "tcpdump -n" and
matched against e.g. /(\d+\.\d+\.\d+\.\d+)\.(\d+) >
(\d+\.\d+\.\d+\.\d+)\.(\d+)/ .
One option is to reverse the meanings, i.e. "-n" stays the
same and "-nn" means "resolve ports but not IP addresses"
(or "do any lookups that don't take any time", which may be
a nice semantic but may not be possible to know, e.g.
tcpdump may not know if ether_ntohost() is going to just
look in /etc/ethers or is going to look in NIS.)
Administrators of the "tcpdump" SourceForge project have superseded this tracker item (formerly artifact 573130, now patch 5) with issue 162 of the "tcpdump" GitHub project.