Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 May 2002 13:43:22 +0200
From:      Andre Oppermann <oppermann@pipeline.ch>
To:        Mike Silbersack <silby@silby.com>
Cc:        freebsd-net@freebsd.org
Subject:   Re: Bug in net/route.[ch] with rmx_pksent while cloning
Message-ID:  <3CF761DA.72AE838A@pipeline.ch>
References:  <20020530233919.K22164-100000@patrocles.silby.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Silbersack wrote:
> 
> On Fri, 31 May 2002, Andre Oppermann wrote:
> 
> Ok, here we go.
> 
> >               if (req == RTM_RESOLVE) {
> >                       rt->rt_rmx = (*ret_nrt)->rt_rmx; /* copy metrics */
> > +                     rt->rt_rmx.rmx_pksent = 0; /* reset packet counter */
> 
> This has been committed to -current, and will be MFC'd after 4.6-release
> is tagged and away.  I guess this could really throw stats off for some
> people, good catch!

Thanks!

> > -     int     rtm_use;        /* from rtentry */
> > +     u_long  rtm_use;        /* from rtentry */
> 
> On i386 systems, making such a change should be safe, as int and u_long
> are both 32 bits, if I recall correctly.  However, changing this will
> change the size of the structure on 64-bit architectures, so I'm not sure
> I want to touch it.  I know that if you change the size of rtentry, you
> need to recompile route to match the kernel if you want any routing
> functions to work.  Will similar breakage occur if rt_msghdr is changed?

I think it will break. Isn't there a compiler warning in net/rtsocket.c
on 64bit platforms about the u_long to int assignment?

IMO the right solution would to simply axe this field from rt_msghdr.
It serves no purpose. At least none of the base utilites look at it and
I don't see neither gated nor Zebra using it.

My vote would go to axe it in -CURRENT and bump the version number. Netstat
and route need to be recompiled. Note in UPDATING.

> I agree that your change is correct, I just don't want to break anything
> in the process of making it better. :)

Yea, it's difficult. While testing this I locked myself out of the box
because I forgot to recompile route and then the startup could failed to
install the default route. Fortunatly I could login from another machine
in the subnet and fix it. So for -STABLE it's a no-go.

> > -             printf("%6ld %8ld ", rt->rt_refcnt, rt->rt_use);
> > +             printf("%6ld %8lu ", rt->rt_refcnt, rt->rt_use);
> 
> Also committed and slated for MFC.

Thanks!

-- 
Andre

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CF761DA.72AE838A>