Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Sep 2001 17:08:43 -0400 (EDT)
From:      Darren Henderson <darren@bmv.state.me.us>
To:        freebsd-stable@FreeBSD.ORG
Subject:   4.4 arp problem
Message-ID:  <Pine.A41.4.21.0109251620020.25940-100000@katahdin.bmv.state.me.us>
In-Reply-To: <3BB0CF0C.2CDCAA38@mitre.org>

next in thread | previous in thread | raw e-mail | index | archive | help

I upgraded a system from 4.3-STABLE to 4.4-STABLE using cvs on 9/23.

Everything was fine before the upgrade, upgrade went smoothly with the
exeption of the MAKEDEV problem thats been reported on the list recently.

This is a dual homed box (multi homed actually but only two interfaces are
in the kernel and active). Typical set up with ipfw/natd.

The system is apparently running just fine. However, I am seeing "/kernel:
arp_rtrequest: bad gateway value" messages which were never there before.
Anyone have an idea what may be causing them?

Searching the archives and the web turns up precious little. This is
apparently generated in netinet/if_ether and relates to aliases. I do have
several aliases defined on one interface. They are configured in
/etc/rc.conf as (x.y.z being numeric of course) ...

ifconfig_dc0="inet 10.0.0.1 netmask 255.255.255.0"
ifconfig_dc1="inet x.y.z.22 netmask 255.255.255.240"
ifconfig_dc1_alias0="inet x.y.z.23 netmask 255.255.255.255"
ifconfig_dc1_alias1="inet x.y.z.26 netmask 255.255.255.255"
ifconfig_dc1_alias2="inet x.y.z.34 netmask 255.255.255.255"
gateway_enable="YES"
router_enable="YES"
defaultrouter="x.y.z.21"

And from netstat -rn we see (in part, lo0 & dc0 routes excluded)....

default     x.y.z.21           UGSc       29   541559    dc1
x.y.z.20/28 link#2             UC          2        0    dc1
x.y.z.21    (nic of gateway)   UHLW        3        0    dc1   1183
x.y.z.23    x.y.z.23           UHLW        0        4    lo0 =>
x.y.z.23/32 link#2             UC          1        0    dc1
x.y.z.26    x.y.z.26           UHLW        0       10    lo0 =>
x.y.z.26/32 link#2             UC          1        0    dc1
x.y.z.34    (nic of link#2)    UHLW        0        6    lo0 =>
x.y.z.34/32 link#2             UC          0        0    dc1

I believe 34 looks different then 23 and 26 becuase those two addresses
are redirected via ipfw/natd to internal addresses.

Something changed in the way interface aliases are handled? Am I looking at
the wrong things? Any thoughts appreciated.
 
-Darren

________________________________________________________________________
Darren Henderson                                  darren@bmv.state.me.us
                                            darren.henderson@state.me.us



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.A41.4.21.0109251620020.25940-100000>