usr.bin/netstat: -n should not print symbolic names

[allanjude]

Summary

in numeric mode, the default route is printed as "default" rather than 0.0.0.0/0 or ::/0

From the man page:
"-n: Show network addresses and ports as numbers.
Normally netstat attempts to resolve addresses and ports, and display them symbolically.
if the -n option is specified, the address is printed numerically, according to the address family.
For more information regarding the Internet IPv4 ``dot format'', refer to inet(3).
Unspecified, or `wildcard'', addresses and ports appear as `*''."

Reported By: rgrimes

[ngie]

Ping (shouldn't this be committed)?

[rgrimes]

In my review of other systems the printing of "default" for this is common and has a long history, changing it at this point in the game would probably be a POLA and possibly break some scripts. I have worked around the issue that caused me to notice this in another way.

We may want to change this into a man page fix that adds the fact that 0.0.0.0/0 is printed as "default" even with the -n option.

[ngie]

In D10320#239021, @rgrimes wrote:

In my review of other systems the printing of "default" for this is common and has a long history, changing it at this point in the game would probably be a POLA and possibly break some scripts. I have worked around the issue that caused me to notice this in another way.

We may want to change this into a man page fix that adds the fact that 0.0.0.0/0 is printed as "default" even with the -n option.

• Fedora Linux 22 does the conversion when -n isn't specified and doesn't do the conversion when it's specified.
• NetBSD 7.x has the same bug as FreeBSD.

I think for the sake of correctness we should do what this CR suggests and follow Linux's lead.

[emaste]

I agree with @ngie.

Also, definitely needs release notes.

[seanc]

Please! Symbolic names are a PITA to handle. Are we going to grow a -H flag that we also need to pass in to get numbers only? What's next: env ALWAYS_ASSUME_YES=1 netstat -n --please-always-yes-numbers=go-force-harder ?

[rgrimes]

I still find this as a gratuitous difference in FreeBSD that does not exist in NetBSD or OpenBSD, and appears to be BSD behavior back into the 80's, anyone that HAS already scripted to deal with symbolic names well be broken if this change is made.

[seanc]

In D10320#295718, @rgrimes wrote:

I still find this as a gratuitous difference in FreeBSD that does not exist in NetBSD or OpenBSD, and appears to be BSD behavior back into the 80's, anyone that HAS already scripted to deal with symbolic names well be broken if this change is made.

Heh. I've been on the other side of this change and wished it were an actual CIDR format. There's demonstrable cost to being different and not breaking from the past.

Regardless, this is all the more the reason userland utilities with bespoke outputs should not be considered the API into the state of the kernel.

[dteske]

Thoughtfully...

There are three vantage points:

1. Backward compatibility

Keep "default" even with -n

2. POLA - Principle Of Least Astonishment

Arguable

3. Forward compatibility

For IPv4 you'd display "0.0.0.0/0" instead of "default"
For IPv6 you'd display "::/0" instead of "default"
There has been rumors of an IPv9 out of China.
Who's to say that "default" isn't the best choice because...
"default" means no change for the IP version.

I say that keeping "default" is arguably an approach that satisfies all three vantage points:

1. Backward compatibility
2. POLA
3. Forward compatibility

[dteske]

In D10320#239021, @rgrimes wrote:

In my review of other systems the printing of "default" for this is common and has a long history, changing it at this point in the game would probably be a POLA and possibly break some scripts. I have worked around the issue that caused me to notice this in another way.

We may want to change this into a man page fix that adds the fact that 0.0.0.0/0 is printed as "default" even with the -n option.

I am a fan of the man page fix approach.

However, the change that I would make to the manual is thus. Instead of:

Show network addresses and ports as numbers. Normally
netstat attempts to resolve addresses and ports, and dis-
play them symbolically.

Perhaps the following:

Don't attempt to resolve addresses (using name services)
and ports (using service(5)).

This not only explains what is prohibited by "-n" but how the resolution services are performed.

This also clarifies why default is not affected, because "default" is an alias to a common concept (0.0.0.0/0 for IPv4, ::/0 for IPv6, and something else for something future, e.g., IPv9), which is neither a name services translation nor a services(5) translation for a port.

[emaste]

I still believe this change should go in, although if we really believe it's a backwards compatibility issue perhaps avoid default only with -n -n or -nn?

[rgrimes]

Well, I am still on the fence with this one, seems someone has already done it to the route get -n command.

[allanjude]

In D10320#351215, @emaste wrote:

I still believe this change should go in, although if we really believe it's a backwards compatibility issue perhaps avoid default only with -n -n or -nn?

-nn might be the right compromise. Although if route get has been changed already...

[ngie]

Should this change be committed?

[gallatin]

I'd very much like for this to be backed out. I feel like users will be chasing the breakage caused by this for years. It broke some tests, iocage, and nstat that I know of in the 5 minutes I've been aware of the commit.

[glebius]

We are already seeing some outrage by FreeBSD CURRENT users and there are already reports of broken scripting. Similar discussions on other media. IMO, this shall not go into 15.0-RELEASE. I'm preparing a review that will enable this only with -nn.

[glebius]

https://reviews.freebsd.org/D48729

[allanjude]

In D10320#1111754, @glebius wrote:

https://reviews.freebsd.org/D48729

Thanks for taking care of this Gleb. I agree that too many things seem to depend on that specific keyword to change it by default.