Bug 237391

Summary: route get returns no result for network addresses (netmask portion of address is zero)
Product: Base System Reporter: bugs.freebsd.org
Component: binAssignee: Alexander V. Chernikov <melifaro>
Status: Closed FIXED    
Severity: Affects Some People CC: bugs.freebsd.org, melifaro, net, rgrimes
Priority: --- Keywords: needs-qa
Version: CURRENTFlags: koobs: mfc-stable12?
koobs: mfc-stable11?
Hardware: Any   
OS: Any   

Description bugs.freebsd.org 2019-04-19 16:37:27 UTC
For example:

route -n get 1.0.0.0
route: route has not been found

route -n get 1.0.0.1
   route to: 1.0.0.1
destination: 0.0.0.0
       mask: 0.0.0.0
    gateway: 10.146.1.1
        fib: 0
  interface: re1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0


route -n get 223.0.0.0
route: route has not been found

route -n get 223.0.0.1
   route to: 223.0.0.1
destination: 0.0.0.0
       mask: 0.0.0.0
    gateway: 10.146.1.1
        fib: 0
  interface: re1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    mtu        weight    expire
       0         0         0         0      1500         1         0
Comment 1 Conrad Meyer freebsd_committer freebsd_triage 2019-04-19 16:50:54 UTC
Reproduces on CURRENT; more accurately, it's related to the address being a "network address", the one address where the netmask portion is zero.  There exist trailing-zero(s) addresses that are not "network addresses", such as 1.1.0.0/8 (masked portion is non-zero 0.1.0.0).
Comment 2 Rodney W. Grimes freebsd_committer freebsd_triage 2019-04-19 17:59:11 UTC
Confirmed all the back to 5.4p8:
route -n get 10.0.0.0
route: writing to routing socket: No such process
pdx.rh.CN85.dnsmgr.net:root {650}# uname -a
FreeBSD pdx.rh.CN85.dnsmgr.net 5.4-RELEASE-p8 FreeBSD 5.4-RELEASE-p8 #0: Wed Sep 21 16:17:14 PDT 2016
{651}# route -n get 10.0.0.1
   route to: 10.0.0.1
destination: default
       mask: default
    gateway: 192.168.114.4
  interface: lnc1
      flags: <UP,GATEWAY,DONE,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0 

I suspect this is miss application of IN_CLASS{ABCD} macros in trying to pick a default netmask for 10.0.0.0 and then not finding an exact route match for 10.0.0.0/8 and so assuming that there is not a broader route.  Bug is most likely purely in the route(8) binary.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2019-04-20 05:40:42 UTC
mfc flags open/requested (?) until merged
Comment 4 Alexander V. Chernikov freebsd_committer freebsd_triage 2020-04-13 20:38:41 UTC
Raised https://reviews.freebsd.org/D24401 with a proposed change.
Comment 6 Alexander V. Chernikov freebsd_committer freebsd_triage 2021-03-07 22:01:45 UTC
The issue should be fixed.

Given that's the user-visible behaviour change, there will be no 11/12 backport.

I'm going to close this PR, please do reopen if current/FreeBSD 13 still behave in undesired way.