On Fri, Apr 16, 2021 at 10:42:00AM -0400, Kenneth R Westerback wrote:
> On Fri, Apr 16, 2021 at 03:17:45PM +0200, Florian Obser wrote:
> > On Thu, Apr 15, 2021 at 12:54:44AM +0000, Lucas wrote:
> > > >Synopsis: dhcpleased(8) doesn't handle underlying changes in
> > > >trunk(4)
> > > >Category: system
> > > >Environment:
> > > System : OpenBSD 6.9
> > > Details : OpenBSD 6.9 (GENERIC.MP) #459: Fri Apr 9 11:31:33 MDT
> > > 2021
> > >
> > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> > > Architecture: OpenBSD.amd64
> > > Machine : amd64
> > >
> > > >Description:
> > > On a trunk(4) interface for wired-WiFi failover, dhcpleased(8)
> > > isn't able to ask for a new lease on active physical interface change.
> > > This is a problem for me, because the network for wired and wireless
> > > devicen on my LAN are different (172.16.0.0/24 for wired, 172.17.0.0/24
> > > for wireless).
> > >
> > > >How-To-Repeat:
> > > Start with a trunk(4) with failover configured as showed below,
> > > connected over WiFi and without an ethernet cord plugged in. Start
> > > dhcpleased(8) and get a lease. Now plug ethernet cord and check
> > > interface status; despite the change on the active physical interface
> > > dhcpleased(8) doesn't solicite a new lease. dhclient(8) does work in
> > > this setup.
> >
> > Rough consensus is that this setup is a poor choice when wired and
> > wireless are on different L2 networks.
> >
> > In that case it's better to not have a trunk(4) but request leases on
> > wired and wireless. Interface priorities will pick the correct
> > network.
> >
> > Trunking is more appropriate when wired and wireless are on the same
> > L2 network since then the IP address does not change when switching
> > between wired and wireless and long running sessions (ssh) stay alive.
> >
> > Arguably the point of trunk(4) is to hide changes in network topology
> > from upper layers. When the active physical interface changes nothing
> > changes on the trunk(4) port. The MAC address stays the same, the link
> > state doesn't change and the interface stays running. Therefore
> > dhcpleased(8) concludes that there is nothing to do.
> >
> > I think this working with dhclient(8) is due to a logic error and not
> > intentional. It also tries to check if something changed on the
> > interface but gets this wrong.
> >
> > --
> > I'm not entirely sure you are real.
> >
>
> dhclient(8) deliberately behaves the way it does by specific demand from
> developers using trunk(4). A fairly recent (2019) demand.
Ha! I had forgotten all about it.
>
> Never having been a user of trunk(4) I have no opinion on the correctness or
> desirabilty of the behaviour. Which of course may have changed over time.
>
> As I recall (and as mentioned in the commit message) there were also routing
> socket changes made by claudio@ at the same time to support this.
> Unfortunately
> a quick pre-caffeine scan of Changelogs did not make those changes pop out for
> me.
>
> I refer to r1.634 of dhclient.c, May 10, 2019.
Yes, that was for the case of being on the same L2 network.
So that diff checks if the mac address changed and does
quit = RESTART;
I don't quite get what it does about link state changing.
I think this did that but that's unconditional.
+ if (quit == 0)
+ quit = RESTART;
If nothing changed try to get a new lease.
I think I misunderstood the diff in 2019.
in r1.634 this changed to
- if (quit == 0)
+ if (oldmtu == ifi->mtu)
quit = RESTART;
So if the mtu did not change request a new lease.
I think this comes down to:
RTM_IFINFO is received
if the mac address changed or the mtu did not change
request a new lease.
I think we didn't get the "relevant RTM_IFINFO" quite right:
Restart the protocol and get a new/renewed lease for any relevant
RTM_IFINFO seen. As dhclient no longer commits suicide to restart the
protocol this should be very low cost.
What happens is, whenever something twiddles the interface, dhclient
requests a new lease, unless it twiddled the interface itself.
>
> I can try scanning my email archives to find a record of any detailed
> reasoning,
> but this took place at g2k19 so the discussion may have just been verbal.
Probably. I remember wandering around suspending and resuming my
laptop and wondering why I wouldn't get a new lease.
>
> .... Ken
--
I'm not entirely sure you are real.
