Theo de Raadt([email protected]) on 2021.11.10 09:46:32 -0700: > Sebastien Marie <[email protected]> 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 shouldn't be big. > > This is a messy part of the route proposal mechanism. The messaging is a > bit weird. We discussed eventually fixing, but never got around to it. > > The route priority code rt_priority is abused to signal the DNS resolver > choice priority. resolvd sees proposals in the range RTP_PROPOSAL_STATIC > to RTP_PROPOSAL_UMB (57 to 60), and uses this to sort output in the > resolv.conf file. RTP_PROPOSAL_SOLICIT is a totally different kind of > message in the opposite direction. > > Something bad might happens if a new prio code is placed on the other > side of RTP_PROPOSAL_SOLICIT, so would not encourage that. > > rtm_type indicates RTM_PROPOSAL for all DNS resolver messages, so the > priority code can be totally unique. Maybe we should move > RTP_PROPOSAL_SOLICIT out of the sorted range. like make it 1?. The > only goal being to make the range-to-be-sorted not contain it, even > as we expand the priorities in the future... > > This would break compatibility only one more time.
Yes. RTP_PROPOSAL* is only used in RTM_PROPOSAL messages and thus the range of values in rt_priority can overlap with the other RTP_ values. 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.
