On Tue, May 19, 2020 at 11:21:13AM +0300, Bars Bars wrote:
> it seems i figured out why userland was 'broken' on recompiled kernel
> with changed RT_TABLEID_MAX.
> I dont think things are really broken, may be i dont them right way, please
> advice.
>
> I could reproduce the issue (all steps are done exactly as in openbsd.org
> faq).
> I changed RT_TABLEID_MAX, recompiled the kernel, booted from it, and change
> didnt work on userland.
> Then i rebuilt userland, rebooted, all works now.
> Now if i apply some patch from errata, there is kernel re-linking done, and
> just after that kernel change doesnt work.
> Is it expected behavior? How can i fix it? syspacth -r doesnt help.
>
You can not syspatch a system with a custom kernel. You need to do apply
the patches yourself. syspatch only works for non-modified kernels.
It should actually check this by making sure that the kernel signature is
correct so not sure what exactly happend but I guess you never properly
installed your kernel including the relink directory and so syspatch
relinked a default kernel over your modified one.
> пн, 18 мая 2020 г. в 13:31, Bars Bars <tutbara...@gmail.com>:
>
> > To be more convinient, when i said about that its limit became shorter its
> > relevant to sys/net/rtable.c struct dommp.
> > struct dommp {
> > unsigned int limit;
> > /*
> > * Array to get the routing domain and loopback interface related
> > to
> > * a routing table. Format:
> > *
> > * 8 unused bits | 16 bits for loopback index | 8 bits for rdomain
> > */
> > unsigned int *value;
> > };
> >
> > In past the maxumum value was limited to u_int16_t in some deep places,
> > but nowadays there is only 8 bits allocated to it based on the struct + 8
> > unused bits which i hop i can safely add to allocation.
> > I worried these unused bits are not guaranteed to users, so actually the
> > limit is 8 bits instead of 16 in earlier releases.
> >
> >
> >
> > пн, 18 мая 2020 г. в 11:51, Bars Bars <tutbara...@gmail.com>:
> >
> >> Hi, Claudio
> >>
> >> I mean these in sys/socket.h
> >> /*
> >> * Maximum number of alternate routing tables
> >> */
> >> #define RT_TABLEID_MAX 8000
> >> #define RT_TABLEID_BITS 16
> >> #define RT_TABLEID_MASK 0xffff
> >>
> >>
> >> пн, 18 мая 2020 г. в 10:18, Claudio Jeker <cje...@diehard.n-r-g.com>:
> >>
> >>> On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote:
> >>> > it seems the things work just when i rebuild userland completely (im
> >>> pretty
> >>> > sure i did it only with compiling kernel in past, correct me if i
> >>> wrong?).
> >>> >
> >>> > btw, questions for the Devs.
> >>> > Looking at the cvs history, i really worried that you do not expand
> >>> > rt_tableid_max limit for the years, moreover now its actually 8 bits
> >>> > shorter than it was before loopback to rdomain map. There are many
> >>> people
> >>> > with more than such a number of vpns, for example if they setup
> >>> centralized
> >>> > vpns setup, or border inter AS router role on the box.
> >>>
> >>> Sorry your mail is incredibly inprecise and unclear. There is no
> >>> rt_tableid_max in OpenBSD at least not in my tree (grep -r rt_tableid_max
> >>> returned nothing). So I have no idea what you are talking about and am
> >>> therefor not able to give you a better answer.
> >>>
> >>> > вс, 17 мая 2020 г., 10:25 Bars Bars <tutbara...@gmail.com>:
> >>> >
> >>> > > Hey, guys.
> >>> > >
> >>> > > I always used the rt_tableid_max expanded to 16 bit range in past
> >>> releases
> >>> > > 5.x and after rebuilding the kernel it worked immediately.
> >>> > > But now I installed 6.6 on the new system, and after changing
> >>> > > rt_tableid_max (and new rt_tableid_mask and bits values too), my
> >>> whole
> >>> > > userland throw an rtable / rdomain too large error.
> >>> > > Is there behaviour change?
> >>> > > The only thing changed (as i know) it is news net/trable.c struct to
> >>> map
> >>> > > loopback to domain, where there is only 8 unused bits to which i can
> >>> expand
> >>> > > tableid value.
> >>> > >
> >>> > >
> >>>
> >>> --
> >>> :wq Claudio
> >>>
> >>
--
:wq Claudio
