Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!wuarchive!gem.mps.ohio-state.edu!usc!ucla-cs!seashell!lcc
From: lcc@seashell.seas.ucla.edu (Locus Computing Corporation)
Newsgroups: comp.unix.aix
Subject: Re: IP routing subnet mask bug?
Keywords: routing subnet
Message-ID: <29065@shemp.CS.UCLA.EDU>
Date: 11 Nov 89 08:14:42 GMT
References: <464@janus.UUCP> <394@itcatl.UUCP> <468@janus.UUCP> <397@itcatl.UUCP> <328@ursa-major.SPDCC.COM>
Sender: news@CS.UCLA.EDU
Reply-To: brian@la.locus.com (Brian Horn)
Distribution: usa
Organization: Locus Computing Corp.
Lines: 20

In article <328@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes:
>In article <397@itcatl.UUCP> robin@itcatl.UUCP (Robin Cutshaw) writes:
>>Guess I should have included more detail.  I am using ifconfig with
>>netmask 255.0.0.0 and broadcast MYNET.255.255.255.  ifconfig shows
>>the netmask to be ff000000 but it actually arp's 000000ff...
>
	Well, I tried to respond to this ages ago, but it looks like it
never made it out.  First off the system doesn't arp ff000000 or 000000ff, but
it DOES respond to ICMP mask request/responses.  As it turned out there
were TWO bugs w.r.t. ICMP mask responses.  1)  The subnet mask was NOT being
used, consequently the requester only saw the "normal" mask (i.e. no subnet
mask in use) which is potentially wrong.  2)  The mask was not sent out
in the canonical IP byte ordering (leastwise not on little-endian machines).
	Both of these problems HAVE been fixed in version 1.2 (at least that
is what I THINK IBM is calling it this week).  A bug fix should be available
for your first generation system.  Check with your SE.

							Brian Horn
							PMTS AIX development
							Locus Computing Corp.