Re: RT_TABLEID_MAX behavior changed?
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 : > Bars Bars 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. >
Re: RT_TABLEID_MAX behavior changed?
Bars Bars 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.
Re: RT_TABLEID_MAX behavior changed?
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 :
> 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 :
> >
> > > 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 :
> > >
> > >> 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 0x
> > >>
> > >>
> > >> пн, 18 мая 2020 г. в 10:18, 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 :
> > >>> >
> > >>> > > 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
>
Re: RT_TABLEID_MAX behavior changed?
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 :
>
> > 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 :
> >
> >> 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 0x
> >>
> >>
> >> пн, 18 мая 2020 г. в 10:18, 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 :
> >>> >
> >>> > > 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
Re: RT_TABLEID_MAX behavior changed?
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 :
> 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 :
>
>> 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 :
>>
>>> 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 0x
>>>
>>>
>>> пн, 18 мая 2020 г. в 10:18, 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 :
>
> > 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
>>>
Re: RT_TABLEID_MAX behavior changed?
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 :
> 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 :
>
>> 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 0x
>>
>>
>> пн, 18 мая 2020 г. в 10:18, 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 :
>>> >
>>> > > 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
>>>
>>
Re: RT_TABLEID_MAX behavior changed?
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 :
> 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 0x
>
>
> пн, 18 мая 2020 г. в 10:18, 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 :
>> >
>> > > 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
>>
>
Re: RT_TABLEID_MAX behavior changed?
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 0x пн, 18 мая 2020 г. в 10:18, 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 : > > > > > 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 >
Re: RT_TABLEID_MAX behavior changed?
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 : > > > 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
Re: RT_TABLEID_MAX behavior changed?
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 : > 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. > >
RT_TABLEID_MAX behavior changed?
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.
