NetBSD Problem Report #23847

Received: (qmail 13815 invoked by uid 605); 22 Dec 2003 23:15:54 -0000
Message-Id: <200312222315.hBMNFbPj008503@keppi.cute.fi>
Date: Tue, 23 Dec 2003 01:15:37 +0200 (EET)
From: torppa@cute.fi
Sender: gnats-bugs-owner@NetBSD.org
Reply-To: torppa@cute.fi
To: gnats-bugs@gnats.netbsd.org
Subject: route interprets cidr format destinations strangely
X-Send-Pr-Version: 3.95

>Number:         23847
>Category:       bin
>Synopsis:       route add 10.10.10/21 dest results in 10/21 to dest
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 22 23:16:00 +0000 2003
>Closed-Date:    
>Last-Modified:  Thu Nov 29 00:00:02 +0000 2007
>Originator:     Jarkko Torppa
>Release:        NetBSD 1.6ZF
>Organization:

>Environment:
System: NetBSD keppi 1.6ZF NetBSD 1.6ZF (KEPPI) #34: Fri Nov 28 16:19:07 EET 2003 root@keppi:/usr/src/sys/arch/i386/compile/KEPPI i386
Architecture: i386
Machine: i386

p4 1:07 keppi[177]%ident /sbin/route
/sbin/route:
     $NetBSD: crt0.c,v 1.13 2003/07/26 19:24:27 salo Exp $
     $NetBSD: route.c,v 1.70 2003/10/01 06:24:19 itojun Exp $
     $NetBSD: show.c,v 1.21 2003/08/07 10:04:39 agc Exp $


>Description:

route add of 10.10.10/21 dest results into a route to 10/21, this
is because route uses inet_addr to parse that address and it only
understands "classfull" reprensentations.

route add 10.10.0.0/21 dest, does what is expected. But notice that
route command itself prints entries like 10.10/21 when it shows
the route table and inet_net_ntop function also creates strings
like 10.10/21.

>How-To-Repeat:
%route add 10.10/21 10.0.0.4
add net 10.10: gateway 10.0.0.4
%route get 10/21    
   route to: 10.0.0.0
destination: 10.0.0.0
       mask: 255.255.248.0
    gateway: 10.0.0.4
 local addr: 10.0.0.22

>Fix:

change route to use inet_net_pton or something else for parsing destination. 
>Release-Note:
>Audit-Trail:

From: Jarkko Torppa <torppa@cute.fi>
To: gnats-bugs@netbsd.org
Cc:  
Subject: Re: bin/23847: route interprets cidr format destinations strangely
Date: Tue, 23 Dec 2003 02:16:04 +0200

 Here is a ugly fix for the problem. Ugly because the work might fit more 
 nicely into a new function.

 Index: route.c
 ===================================================================
 RCS file: /cvsroot/src/sbin/route/route.c,v
 retrieving revision 1.70
 diff -u -r1.70 route.c
 --- route.c     2003/10/01 06:24:19     1.70
 +++ route.c     2003/12/23 00:08:21
 @@ -1146,7 +1146,8 @@
          sup su;
          struct hostent *hp;
          struct netent *np;
 -       u_int32_t val;
 +       u_int32_t val,mask;
 +       int preflength;
          char *t;
          int afamily;  /* local copy of af so we can change it */

 @@ -1319,12 +1320,17 @@
          *hpp = NULL;

          if ((t = strchr(s, '/')) != NULL && which == RTA_DST) {
 -               *t = '\0';
 -               if ((val = inet_addr(s)) != INADDR_NONE) {
 -                       inet_makenetandmask(htonl(val), &su->sin);
 -                       return prefixlen(&t[1]);
 +               preflength=inet_net_pton(AF_INET, s, &val, sizeof(val));
 +               if(preflength != -1) {
 +                 rtm_addrs |= RTA_NETMASK;
 +                 memset(&so_mask,0,sizeof(so_mask));
 +                 mask = ( 0xffffffffu << ( 32 - preflength));
 +                 su->sin.sin_addr.s_addr = htonl(ntohl(val) & mask);
 +                 so_mask.sin.sin_family = AF_INET;
 +                 so_mask.sin.sin_len = sizeof(struct sockaddr_in);
 +                 so_mask.sin.sin_addr.s_addr = htonl(mask);
 +                 return preflength == 32 ? 1: 0;
                  }
 -               *t = '/';
          }
          if (((val = inet_addr(s)) != INADDR_NONE) &&
              (which != RTA_DST || forcenet == 0)) {

From: David Holland <dholland@eecs.harvard.edu>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: bin/23847: route interprets cidr format destinations strangely
Date: Wed, 28 Nov 2007 18:55:16 -0500

 ...just noting that this problem still exists in -current.
 (And to clarify slightly, the problem is that route interprets
 10.10/21 as 10.0.0.10/21.)

 -- 
    - David A. Holland / dholland@eecs.harvard.edu

>Unformatted:

Home	PR Database Search