> If we move the RTP_PROPOSAL_SOLICIT we might as well at the same time move
> the other RTP_PROPOSAL values to give us more room for additional devices.
>
> It would be a "upgrade with a snapshot or your dns might not work"
> situation.
or put PPP after SOLICIT
The sort function does not care,
Theo de Raadt(dera...@openbsd.org) on 2021.11.10 09:46:32 -0700:
> Sebastien Marie wrote:
>
> > I just wonder about the system behaviour after building a new kernel
> > and rebooting to build userland: RTP_PROPOSAL_SOLICIT is changed and
> > kernel/userland will mismatch.
> >
> > But UMB
Sebastien Marie wrote:
> I just wonder about the system behaviour after building a new kernel
> and rebooting to build userland: RTP_PROPOSAL_SOLICIT is changed and
> kernel/userland will mismatch.
>
> But UMB proposal was done this way too (moving RTP_PROPOSAL_SOLICIT to
> next id). So disturb
On Wed 10/11/2021 16:53, Sebastien Marie wrote:
> On Wed, Nov 10, 2021 at 04:22:49PM +0100, Bjorn Ketelaars wrote:
> > sppp(4) is currently using RTP_PROPOSAL_STATIC for sending DNS
> > proposals, whereas all others sources, e.g. umb(4), are using a specific
> > value. Diff below fixes this by
On Wed, Nov 10, 2021 at 04:22:49PM +0100, Bjorn Ketelaars wrote:
> sppp(4) is currently using RTP_PROPOSAL_STATIC for sending DNS
> proposals, whereas all others sources, e.g. umb(4), are using a specific
> value. Diff below fixes this by adding RTP_PROPOSAL_PPP.
>
> Although the diff is limited
sppp(4) is currently using RTP_PROPOSAL_STATIC for sending DNS
proposals, whereas all others sources, e.g. umb(4), are using a specific
value. Diff below fixes this by adding RTP_PROPOSAL_PPP.
Although the diff is limited in size it touches several pieces:
- sppp(4)
- route(4)
- route(8)
-
