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.
пн, 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
>>>
>>
