RT_TABLEID_MAX behavior changed?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

RT_TABLEID_MAX behavior changed?

Bars Bars
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.
Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Bars Bars
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.


вс, 17 мая 2020 г., 10:25 Bars Bars <[hidden email]>:

> 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.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Claudio Jeker
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 <[hidden email]>:
>
> > 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

Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Bars Bars
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 <[hidden email]>:

> 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 <[hidden email]>:
> >
> > > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Bars Bars
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>> >
>> > > 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
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Bars Bars
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 <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>> >
>>> > > 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
>>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Bars Bars
as i understand, kernel relinking currently used object file and installs
new kernel.
what i do not understand is how could it 'rollback' kernel changes done
during compilation,
if it using current object files which arre built during compilation.

Just one note, i not yet rebooted after re-linking done, because of created
domains are working (the traffic on them),
just userland does not, and im afraid they will fail to create after reboot
and i should repeat userland rebuild again.

вт, 19 мая 2020 г. в 11:21, Bars Bars <[hidden email]>:

> 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 <[hidden email]>:
>
>> 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 <[hidden email]>:
>>
>>> 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 <[hidden email]>:
>>>
>>>> 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 <[hidden email]>:
>>>> >
>>>> > > 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
>>>>
>>>
Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Claudio Jeker
In reply to this post by Bars Bars
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 <[hidden email]>:
>
> > 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 <[hidden email]>:
> >
> >> 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 <[hidden email]>:
> >>
> >>> 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 <[hidden email]>:
> >>> >
> >>> > > 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

Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Bars Bars
Thank you much.

Do you mean i should not do syspatch if a modified kernel sources?
When reading KARL notes i tough that it only incompatible with kernel
changed
with config -e or kernel configuration file, which i did not modified.

What about kernel relinking at boot time?
Kernel changes was working after reboot, before applying syspatch.
So it seems at boot time relinking script took right base kernel to relink.

And as i understand, to fix current state it is enough if i
rebuild kernel only w/o userland?

вт, 19 мая 2020 г. в 12:41, Claudio Jeker <[hidden email]>:

> 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 <[hidden email]>:
> >
> > > 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 <[hidden email]>:
> > >
> > >> 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 <[hidden email]>:
> > >>
> > >>> 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 <[hidden email]>:
> > >>> >
> > >>> > > 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
>
Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Theo de Raadt-2
Bars Bars <[hidden email]> wrote:

> Thank you much.
>
> Do you mean i should not do syspatch if a modified kernel sources?

syspatches can deliver replacements for kernel .o files

So if you have changed a .h or .c file, the syspatches are not
going to work correctly.

Once you use source-code methods, you can't use those binary
methods.

Reply | Threaded
Open this post in threaded view
|

Re: RT_TABLEID_MAX behavior changed?

Bars Bars
thanks, i got it.
so probably i should manually patch, recompile and install kernel again.
Then should i care about boot time kernel re-linking if i have such a
custom kernel?

Claudio, please, do not forget to advice with the question about
RT_TABLEID_MAX itself,
i hope i clarified you what im talking about. if not, ask me please.

вт, 19 мая 2020 г. в 15:05, Theo de Raadt <[hidden email]>:

> Bars Bars <[hidden email]> wrote:
>
> > Thank you much.
> >
> > Do you mean i should not do syspatch if a modified kernel sources?
>
> syspatches can deliver replacements for kernel .o files
>
> So if you have changed a .h or .c file, the syspatches are not
> going to work correctly.
>
> Once you use source-code methods, you can't use those binary
> methods.
>