From jin@eubie.lbl.gov  Wed Jun 26 16:13:26 2002
Return-Path: <jin@eubie.lbl.gov>
Received: from eubie.lbl.gov (eubie.lbl.gov [131.243.2.36])
	by hub.freebsd.org (Postfix) with ESMTP id 6508237B83C
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 26 Jun 2002 16:01:14 -0700 (PDT)
Received: from eubie.lbl.gov (localhost [127.0.0.1])
	by eubie.lbl.gov (8.12.3/8.12.3) with ESMTP id g5QKuFRX000410
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 26 Jun 2002 13:56:15 -0700 (PDT)
	(envelope-from jin@eubie.lbl.gov)
Received: (from root@localhost)
	by eubie.lbl.gov (8.12.3/8.12.3/Submit) id g5QKuFY0000409;
	Wed, 26 Jun 2002 13:56:15 -0700 (PDT)
Message-Id: <200206262056.g5QKuFY0000409@eubie.lbl.gov>
Date: Wed, 26 Jun 2002 13:56:15 -0700 (PDT)
From: Jin Guojun (DSD staff) <jin@eubie.lbl.gov>
Reply-To: j_guojun@lbl.gov
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: netmask 0xffffff00 no longer works in /etc/exports
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         39896
>Category:       bin
>Synopsis:       netmask 0xffffff00 no longer works in /etc/exports
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jun 26 16:20:01 PDT 2002
>Closed-Date:    Mon Jun 25 20:37:22 GMT 2007
>Last-Modified:  Mon Jun 25 20:37:22 GMT 2007
>Originator:     Jin Guojun (DSD staff)
>Release:        FreeBSD 4.6-RELEASE i386
>Organization:
>Environment:


	FreeBSD 4.6-RELEASE
>Description:
	Somehow, netmask format in  /etc/exports is restricted to
	###.###.###.### only.
	/data -maproot=bin: -network 131.104.48 -mask 255.255.255.0

	eubie# kill -HUP `cat /var/run/mountd.pid`
	eubie# mount eubie:/data /mnt
	eubie#

	The following format does not work any more
	/data -maproot=bin: -network 131.104.48 -mask 0xffffff00

	mountd does not complain, but silently denies to export this
	partition:

	eubie# kill -HUP `cat /var/run/mountd.pid`
	eubie# mount eubie:/data /mnt
	eubie:/data: Permission denied


>How-To-Repeat:
	add similar line to /etc/exports, restart mountd, and
	mount this partition locally or remotely.

	/data -maproot=bin: -network 131.104.48 -mask 0xffffff00
>Fix:

	Is any reason to make such change? or Is this a bug?


>Release-Note:
>Audit-Trail:

From: "Crist J. Clark" <crist.clark@attbi.com>
To: j_guojun@lbl.gov
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 00:05:26 -0700

 On Wed, Jun 26, 2002 at 01:56:15PM -0700, Jin Guojun wrote:
 [snip]
 
 > 	Somehow, netmask format in  /etc/exports is restricted to
 > 	###.###.###.### only.
 > 	/data -maproot=bin: -network 131.104.48 -mask 255.255.255.0
 > 
 > 	eubie# kill -HUP `cat /var/run/mountd.pid`
 > 	eubie# mount eubie:/data /mnt
 > 	eubie#
 > 
 > 	The following format does not work any more
 > 	/data -maproot=bin: -network 131.104.48 -mask 0xffffff00
 > 
 > 	mountd does not complain, but silently denies to export this
 > 	partition:
 > 
 > 	eubie# kill -HUP `cat /var/run/mountd.pid`
 > 	eubie# mount eubie:/data /mnt
 > 	eubie:/data: Permission denied
 > 
 > 
 > >How-To-Repeat:
 > 	add similar line to /etc/exports, restart mountd, and
 > 	mount this partition locally or remotely.
 > 
 > 	/data -maproot=bin: -network 131.104.48 -mask 0xffffff00
 > >Fix:
 > 
 > 	Is any reason to make such change? or Is this a bug?
 
 I can't reproduce this.
 
   # uname -r
   4.6-RELEASE
   # grep ^/export /etc/exports
   /export         -alldirs -ro -network 192.168.64 -mask 255.255.255.0
   # kill -HUP `cat /var/run/mountd.pid`
   # showmount -e | grep ^/export
   /export                            192.168.64.0
 
 And on a different machine on that net, I can mount it fine.
 -- 
 Crist J. Clark                     |     cjclark@alum.mit.edu
                                    |     cjclark@jhu.edu
 http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

From: "Jin Guojun[DSD]" <j_guojun@lbl.gov>
To: "Crist J. Clark" <cjc@FreeBSD.ORG>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 09:38:14 -0700

 "Crist J. Clark" wrote:
 > 
 > On Wed, Jun 26, 2002 at 01:56:15PM -0700, Jin Guojun wrote:
 > [snip]
 > 
 > >       Somehow, netmask format in  /etc/exports is restricted to
 > >       ###.###.###.### only.
 > >       /data -maproot=bin: -network 131.104.48 -mask 255.255.255.0
 > >
 > >       eubie# kill -HUP `cat /var/run/mountd.pid`
 > >       eubie# mount eubie:/data /mnt
 > >       eubie#
 > >
 > >       The following format does not work any more
 > >       /data -maproot=bin: -network 131.104.48 -mask 0xffffff00
 > >
 > >       mountd does not complain, but silently denies to export this
 > >       partition:
 > >
 > >       eubie# kill -HUP `cat /var/run/mountd.pid`
 > >       eubie# mount eubie:/data /mnt
 > >       eubie:/data: Permission denied
 > >
 > >
 > > >How-To-Repeat:
 > >       add similar line to /etc/exports, restart mountd, and
 > >       mount this partition locally or remotely.
 > >
 > >       /data -maproot=bin: -network 131.104.48 -mask 0xffffff00
 > > >Fix:
 > >
 > >       Is any reason to make such change? or Is this a bug?
 > 
 > I can't reproduce this.
 > 
 >   # uname -r
 >   4.6-RELEASE
 >   # grep ^/export /etc/exports
 >   /export         -alldirs -ro -network 192.168.64 -mask 255.255.255.0
 >   # kill -HUP `cat /var/run/mountd.pid`
 >   # showmount -e | grep ^/export
 >   /export                            192.168.64.0
 > 
 > And on a different machine on that net, I can mount it fine.
 
 Are you sure that you understand or did things correctly? :-)
 (Assume that all lines you typed are not typo !!!)
 
 Your netmask is 255.255.255.0 not 0xffffff00. If not typo, plesse try
  0xffffff00 , which is asked in "How-To-Repeat" section.
 
 > --
 > Crist J. Clark                     |     cjclark@alum.mit.edu
 >                                    |     cjclark@jhu.edu
 > http://people.freebsd.org/~cjc/    |     cjc@freebsd.org
 
 -- 
 ------------ Jin Guojun ----------- v --- j_guojun@lbl.gov ---
 Distributed Systems Department		http://www.itg.lbl.gov/~jin
 M/S 50B-2239				Ph#:(510) 486-7531 Fax: 486-6363
 Lawrence Berkeley National Laboratory,	Berkeley, CA 94720

From: "Crist J. Clark" <crist.clark@attbi.com>
To: "Jin Guojun[DSD]" <j_guojun@lbl.gov>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 10:23:05 -0700

 On Thu, Jun 27, 2002 at 09:38:14AM -0700, Jin Guojun[DSD] wrote:
 > "Crist J. Clark" wrote:
 
 [snip]
 
 > > I can't reproduce this.
 > > 
 > >   # uname -r
 > >   4.6-RELEASE
 > >   # grep ^/export /etc/exports
 > >   /export         -alldirs -ro -network 192.168.64 -mask 255.255.255.0
 > >   # kill -HUP `cat /var/run/mountd.pid`
 > >   # showmount -e | grep ^/export
 > >   /export                            192.168.64.0
 > > 
 > > And on a different machine on that net, I can mount it fine.
 > 
 > Are you sure that you understand or did things correctly? :-)
 > (Assume that all lines you typed are not typo !!!)
 > 
 > Your netmask is 255.255.255.0 not 0xffffff00. If not typo, plesse try
 >  0xffffff00 , which is asked in "How-To-Repeat" section.
 
 Sorry. Wrong cut-n-paste. I did use 0xffffff00 and it seemed to work
 fine. When did you notice a change? src/sbin/mountd/mountd.c hasn't
 changed since 4.4-RELEASE. I can't see anything that deals with
 reading the netmask that has changed since 1998. The mask is actually
 read with the inet_network(3) function, and I see no significant
 changes in that for several years either.
 -- 
 Crist J. Clark                     |     cjclark@alum.mit.edu
                                    |     cjclark@jhu.edu
 http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

From: Ian Dowse <iedowse@maths.tcd.ie>
To: "Crist J. Clark" <crist.clark@attbi.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG,
	"Jin Guojun[DSD]" <j_guojun@lbl.gov>
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports 
Date: Thu, 27 Jun 2002 18:59:01 +0100

 In message <200206271730.g5RHU3PL084959@freefall.freebsd.org>, "Crist J. Clark"
  writes:
 > Sorry. Wrong cut-n-paste. I did use 0xffffff00 and it seemed to work
 > fine. When did you notice a change? src/sbin/mountd/mountd.c hasn't
 > changed since 4.4-RELEASE. I can't see anything that deals with
 > reading the netmask that has changed since 1998. The mask is actually
 > read with the inet_network(3) function, and I see no significant
 > changes in that for several years either.
 
 I'm not sure how this could have ever worked correctly, since
 inet_network(3) does not support hex addresses of this form. There
 are also no examples of it on the mountd man page. It is probably
 a bug that inet_network() is not a bit more picky about what it
 does accept though.
 
 Ian

From: "Crist J. Clark" <crist.clark@attbi.com>
To: Ian Dowse <iedowse@maths.tcd.ie>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG,
	"Jin Guojun[DSD]" <j_guojun@lbl.gov>
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 11:18:01 -0700

 On Thu, Jun 27, 2002 at 06:59:01PM +0100, Ian Dowse wrote:
 > In message <200206271730.g5RHU3PL084959@freefall.freebsd.org>, "Crist J. Clark"
 >  writes:
 > > Sorry. Wrong cut-n-paste. I did use 0xffffff00 and it seemed to work
 > > fine. When did you notice a change? src/sbin/mountd/mountd.c hasn't
 > > changed since 4.4-RELEASE. I can't see anything that deals with
 > > reading the netmask that has changed since 1998. The mask is actually
 > > read with the inet_network(3) function, and I see no significant
 > > changes in that for several years either.
 > 
 > I'm not sure how this could have ever worked correctly, since
 > inet_network(3) does not support hex addresses of this form.
 
 Actually, it does. The manpage says,
 
      All numbers supplied as ``parts'' in a `.' notation may be decimal,
      octal, or hexadecimal, as specified in the C language (i.e., a leading 0x
      or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other-
      wise, the number is interpreted as decimal).
 
 And since it is perfectly valid to provide an internet address as a
 single "part," an address like 0xffffff00 is totally valid by these
 rules. To illustrate this, all of these are the same IP address,
 
   0xffffff00
   4294967040
 
   0xff.0xffff00
   255.16776960
 
   0xff.0xff.0xff00
   255.255.65280
 
   0xff.0xff.0xff.0x0
   255.255.255.0
 
 -- 
 Crist J. Clark                     |     cjclark@alum.mit.edu
                                    |     cjclark@jhu.edu
 http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

From: "Jin Guojun[DSD]" <j_guojun@lbl.gov>
To: cjclark@alum.mit.edu
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 11:21:15 -0700

 "Crist J. Clark" wrote:
 > 
 > On Thu, Jun 27, 2002 at 09:38:14AM -0700, Jin Guojun[DSD] wrote:
 > > "Crist J. Clark" wrote:
 > 
 > [snip]
 > 
 > > > I can't reproduce this.
 > > >
 > > >   # uname -r
 > > >   4.6-RELEASE
 > > >   # grep ^/export /etc/exports
 > > >   /export         -alldirs -ro -network 192.168.64 -mask 255.255.255.0
 > > >   # kill -HUP `cat /var/run/mountd.pid`
 > > >   # showmount -e | grep ^/export
 > > >   /export                            192.168.64.0
 > > >
 > > > And on a different machine on that net, I can mount it fine.
 > >
 > > Are you sure that you understand or did things correctly? :-)
 > > (Assume that all lines you typed are not typo !!!)
 > >
 > > Your netmask is 255.255.255.0 not 0xffffff00. If not typo, plesse try
 > >  0xffffff00 , which is asked in "How-To-Repeat" section.
 > 
 > Sorry. Wrong cut-n-paste. I did use 0xffffff00 and it seemed to work
 > fine. When did you notice a change? src/sbin/mountd/mountd.c hasn't
 > changed since 4.4-RELEASE. I can't see anything that deals with
 > reading the netmask that has changed since 1998. The mask is actually
 > read with the inet_network(3) function, and I see no significant
 > changes in that for several years either.
 
 Yesterday, when upgrading OpenSSH, we upgraded FreeBSD to 4.6 and found
 this problem. I just repeat it now and pasted output below. The showmount
 does not show any problem, but mount does.
 
 The reason I would like to use 0xffffff00 is because we have an automated
 sys-admin process that grep the netmask from ifconfig, which uses
 0xffffffff notation instead of 255.255.255.255 notation, put it into 
 /etc/exports file, and test it locally first.
 During the upgrading, the server hung on mounting exported partition.
 So, I tried to mount this partition on a remote host, and got the same
 result -- Permission denied.
 
 After thought a little bit, I manually changed 0xffffff00 to 255.255.255.0
 and things started to work. So, I tried to upgrade all servers, which have
 different hardware, and they all had the same problem on netmask for
 exporting partitions.
 
 Since ifconfig uses hex notation (0xffffffff), and sed/awk/expr has no easy
 way to convert it to decimal notation (255.255.255.255), it is important
 to make this work; or ifconfig and exports should use the same notation,
 either all hex or all decimal.
 
 eubie# df /data
 Filesystem  1K-blocks  Used  Avail Capacity  Mounted on
 /dev/ad0s2g    546414 22126 480576     4%    /data
 eubie# uname -r
 4.6-RELEASE
 eubie# echo "/data -network 131.243.2 -mask 255.255.255.0" > /etc/exports
 eubie# kill -HUP `cat /var/run/mountd.pid`
 eubie# showmount -e
 Exports list on localhost:
 /data                              131.243.2.0 
 eubie# mount eubie:/data /mnt
 eubie# echo "/data -network 131.243.2 -mask 0xffffff00" > /etc/exports
 eubie# kill -HUP `cat /var/run/mountd.pid`
 eubie# showmount -e
 Exports list on localhost:
 /data                              131.243.2.0 
 eubie# mount eubie:/data /mnt
 eubie:/data: Permission denied
 ^C
 eubie# date
 Thu Jun 27 11:00:18 PDT 2002
 
 > --
 > Crist J. Clark                     |     cjclark@alum.mit.edu
 >                                    |     cjclark@jhu.edu
 > http://people.freebsd.org/~cjc/    |     cjc@freebsd.org
 
 -- 
 ------------ Jin Guojun ----------- v --- j_guojun@lbl.gov ---
 Distributed Systems Department		http://www.itg.lbl.gov/~jin
 M/S 50B-2239				Ph#:(510) 486-7531 Fax: 486-6363
 Lawrence Berkeley National Laboratory,	Berkeley, CA 94720

From: Ian Dowse <iedowse@maths.tcd.ie>
To: cjclark@alum.mit.edu
Cc: FreeBSD-gnats-submit@FreeBSD.ORG,
	"Jin Guojun[DSD]" <j_guojun@lbl.gov>
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports 
Date: Thu, 27 Jun 2002 19:30:48 +0100

 In message <20020627111801.B77359@blossom.cjclark.org>, "Crist J. Clark" writes
 :
 >On Thu, Jun 27, 2002 at 06:59:01PM +0100, Ian Dowse wrote:
 >> I'm not sure how this could have ever worked correctly, since
 >> inet_network(3) does not support hex addresses of this form.
 >
 >Actually, it does. The manpage says,
 >
 >     All numbers supplied as ``parts'' in a `.' notation may be decimal,
 >     octal, or hexadecimal, as specified in the C language (i.e., a leading 0x
 >     or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other-
 >     wise, the number is interpreted as decimal).
 >
 >And since it is perfectly valid to provide an internet address as a
 >single "part," an address like 0xffffff00 is totally valid by these
 >rules. To illustrate this, all of these are the same IP address,
 
 Ok, but the code in inet_network() seems to disagree
 
 	...
 	for (val = 0, i = 0; i < n; i++) {
 		val <<= 8;
 		val |= parts[i] & 0xff;
 	}
 	return (val);
 
 so 0xffffff00 gets converted to 0.
 
 Ian

From: "Crist J. Clark" <crist.clark@attbi.com>
To: "Jin Guojun[DSD]" <j_guojun@lbl.gov>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 11:59:55 -0700

 On Thu, Jun 27, 2002 at 11:21:15AM -0700, Jin Guojun[DSD] wrote:
 [snip]
 
 OK, I _can_ reproduce this. There is something really, really wack
 going on. This is actually the issue I thought you were refering to
 when I first read your PR.
 
 Your error is here,
 
 > eubie# echo "/data -network 131.243.2 -mask 255.255.255.0" > /etc/exports
                                        ^
 As I understand inet_network(3), you are refering to the network,
 
   131.243.0.2
 
 And if you change that to,
 
   131.243.2.0
 
 Everything in all of your examples should work fine. This should be
 trivial to do in your scripting, so I think you have the correction you
 need for your problem.
 
 The real question is why the heck did this ever work? Something quite
 strange is going on here. In my examples I was in a Class C space, and
 it worked fine. Yours is Class B, and you hit problems. But I don't
 see where Class B or Class C addresses ever come into this. Might be
 time to run mountd(8) in a debugger to see what the heck is going on
 here.
 -- 
 Crist J. Clark                     |     cjclark@alum.mit.edu
                                    |     cjclark@jhu.edu
 http://people.freebsd.org/~cjc/    |     cjc@freebsd.org

From: "Jin Guojun[DSD]" <j_guojun@lbl.gov>
To: cjclark@alum.mit.edu
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 12:33:19 -0700

 "Crist J. Clark" wrote:
 > 
 > On Thu, Jun 27, 2002 at 11:21:15AM -0700, Jin Guojun[DSD] wrote:
 > [snip]
 > 
 > OK, I _can_ reproduce this. There is something really, really wack
 > going on. This is actually the issue I thought you were refering to
 > when I first read your PR.
 > 
 > Your error is here,
 > 
 > > eubie# echo "/data -network 131.243.2 -mask 255.255.255.0" > /etc/exports
 >                                        ^
 > As I understand inet_network(3), you are refering to the network,
 > 
 >   131.243.0.2
 > 
 > And if you change that to,
 > 
 >   131.243.2.0
 > 
 > Everything in all of your examples should work fine. This should be
 > trivial to do in your scripting, so I think you have the correction you
 > need for your problem.
 
 This is very minor to change if it s true. 
 But the problem is not quite like that.
 Showmount says both 131.243.2 and 131.243.2.0 are correct and the 
 problem persists:
 
 eubie# echo "/data -network 131.243.2.0  -mask 0xffffff00" > /etc/exports
 eubie# kill -HUP `cat /var/run/mountd.pid`
 eubie# showmount -e
 Exports list on localhost:
 /data                              131.243.2.0 
 eubie# mount eubie:/data /mnt
 eubie:/data: Permission denied
 ^C
 eubie# echo "/data -network 131.243.2 -mask 0xffffff00" > /etc/exports
 eubie# kill -HUP `cat /var/run/mountd.pid`
 eubie# showmount -e
 Exports list on localhost:
 /data                              131.243.2.0 
 eubie# mount eubie:/data /mnt
 eubie:/data: Permission denied
 ^C
 
 I will try reinstall it without X or other packages. 
 It seems to me when I first time tested 4.6 without X and other stuff,
 it had not problem; but do not remember what was exactly.
 
 More later.
 
 	-Jin

From: Ian Dowse <iedowse@maths.tcd.ie>
To: "Crist J. Clark" <crist.clark@attbi.com>
Cc: "Jin Guojun[DSD]" <j_guojun@lbl.gov>,
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports 
Date: Thu, 27 Jun 2002 21:10:13 +0100

 In message <200206271910.g5RJA4sI004556@freefall.freebsd.org>, "Crist J. Clark"
  writes:
 > Your error is here,
 > 
 > > eubie# echo "/data -network 131.243.2 -mask 255.255.255.0" > /etc/exports
 >                                        ^
 > As I understand inet_network(3), you are refering to the network,
 > 
 >   131.243.0.2
 
 I'm not super-familiour with the intricacies of parsing <4 part IP
 addresses, but if you look at the code or instrument mountd, you
 will see that this is not the case for inet_network() (I think the
 effect you refer to happens to IP addresses, not network numbers).
 
 Below is a simple patch for inet_network() that makes it support
 32-bit hex network numbers. It now also returns INADDR_NONE in a
 few cases where previously the number would be silently truncated.
 This could probably be improved upon.
 
 Ian
 
 Index: inet_network.c
 ===================================================================
 RCS file: /home/iedowse/CVS/src/lib/libc/net/inet_network.c,v
 retrieving revision 1.6.2.1
 diff -u -r1.6.2.1 inet_network.c
 --- inet_network.c	21 Apr 2001 14:53:04 -0000	1.6.2.1
 +++ inet_network.c	27 Jun 2002 19:55:06 -0000
 @@ -85,6 +85,8 @@
  		return (INADDR_NONE);
  	*pp++ = val;
  	n = pp - parts;
 +	if (val > 0xff)
 +		return (n == 1 ? val : INADDR_NONE);
  	for (val = 0, i = 0; i < n; i++) {
  		val <<= 8;
  		val |= parts[i] & 0xff;

From: "Jin Guojun[DSD]" <j_guojun@lbl.gov>
To: Ian Dowse <iedowse@maths.tcd.ie>
Cc: "Crist J. Clark" <crist.clark@attbi.com>,
	FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Thu, 27 Jun 2002 17:03:08 -0700

 Ian Dowse wrote:
 > 
 > In message <200206271910.g5RJA4sI004556@freefall.freebsd.org>, "Crist J. Clark"
 >  writes:
 > > Your error is here,
 > >
 > > > eubie# echo "/data -network 131.243.2 -mask 255.255.255.0" > /etc/exports
 > >                                        ^
 > > As I understand inet_network(3), you are refering to the network,
 > >
 > >   131.243.0.2
 > 
 > I'm not super-familiour with the intricacies of parsing <4 part IP
 > addresses, but if you look at the code or instrument mountd, you
 > will see that this is not the case for inet_network() (I think the
 > effect you refer to happens to IP addresses, not network numbers).
 > 
 > Below is a simple patch for inet_network() that makes it support
 > 32-bit hex network numbers. It now also returns INADDR_NONE in a
 > few cases where previously the number would be silently truncated.
 > This could probably be improved upon.
 > 
 > Ian
 > 
 > Index: inet_network.c
 > ===================================================================
 > RCS file: /home/iedowse/CVS/src/lib/libc/net/inet_network.c,v
 > retrieving revision 1.6.2.1
 > diff -u -r1.6.2.1 inet_network.c
 > --- inet_network.c      21 Apr 2001 14:53:04 -0000      1.6.2.1
 > +++ inet_network.c      27 Jun 2002 19:55:06 -0000
 > @@ -85,6 +85,8 @@
 >                 return (INADDR_NONE);
 >         *pp++ = val;
 >         n = pp - parts;
 > +       if (val > 0xff)
 > +               return (n == 1 ? val : INADDR_NONE);
 >         for (val = 0, i = 0; i < n; i++) {
 >                 val <<= 8;
 >                 val |= parts[i] & 0xff;
 
 Yup, it fixed the problem.
 I have looked and diffed mountd and related sources, but did not find
 any significant change. most files are not changed.
 inet_network.c is the same in both 4.5 and 4.6. How it works under 4.5 
 but not under 4.6 is a mystery.
 
 I will try to trace what happend in 4.6 a little further. If some
 developer feels something they changed may have affection to this,
 pleae send message to this liet, so we can benefit from it.
 
 To understand what causes the problem is more important than a fix.
 
 Thanks folks,
 
 -- 
 ------------ Jin Guojun ----------- v --- j_guojun@lbl.gov ---
 Distributed Systems Department		http://www.itg.lbl.gov/~jin
 M/S 50B-2239				Ph#:(510) 486-7531 Fax: 486-6363
 Lawrence Berkeley National Laboratory,	Berkeley, CA 94720

From: Bruce Evans <bde@zeta.org.au>
To: "Crist J. Clark" <crist.clark@attbi.com>
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Fri, 28 Jun 2002 17:11:58 +1000 (EST)

 On Thu, 27 Jun 2002, Crist J. Clark wrote:
 
 >  On Thu, Jun 27, 2002 at 11:21:15AM -0700, Jin Guojun[DSD] wrote:
 >  [snip]
 >
 >  OK, I _can_ reproduce this. There is something really, really wack
 >  going on. This is actually the issue I thought you were refering to
 >  when I first read your PR.
 >
 >  Your error is here,
 >
 >  > eubie# echo "/data -network 131.243.2 -mask 255.255.255.0" > /etc/exports
 >                                         ^
 >  As I understand inet_network(3), you are refering to the network,
 >
 >    131.243.0.2
 >
 >  And if you change that to,
 >
 >    131.243.2.0
 >
 >  Everything in all of your examples should work fine. This should be
 >  trivial to do in your scripting, so I think you have the correction you
 >  need for your problem.
 
 The conventions for export(5) are quite different from those of
 inet_network(3).  131.243.2 means all hosts on the subnetwork 131.243.2.
 
 I know very little about this except that the TIRPC changes broke the
 convention for -network, and rev.1.48 of mountd.c or thereabouts fixed
 this.  I noticed the breakage for -network but didn't noticed any problems
 for -mask.
 
 Bruce
 

From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= <bkoenig@alpha-tierchen.de>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: bin/39896: netmask 0xffffff00 no longer works in /etc/exports
Date: Mon, 25 Jun 2007 22:16:32 +0200 (CEST)

 This PR should be closed. The problem doesn't persist today.
 
 Bjrn
 
 
State-Changed-From-To: open->closed 
State-Changed-By: remko 
State-Changed-When: Mon Jun 25 20:37:21 UTC 2007 
State-Changed-Why:  
Close per bjorns request, thanks for the feedback! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=39896 
>Unformatted:
