On Fri, Apr 16, 2021 at 11:54:24AM -0400, Kenneth R Westerback wrote: > On Fri, Apr 16, 2021 at 05:19:38PM +0200, Florian Obser wrote: > > 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. > > As I recall, the change was to accommodate RTM_IFINFO messages that did *not* > have a link state change or an LLADDR change for the trunk(4), but were being > issued because an underlying interface had a link state change. So dhclient(4) > simply acquired a new lease, and thus possibly new address, default route, > etc.
Hmm, then I don't know what's going on. Maybe we misunderstood each other back then or I was confused. This would not have been my usecase back then. It would be the usecase of the OP but until recently I wasn't aware that people trunk different L2 networks together. > > What I don't recall is whether these RTM_IFINFO messages were already being > issued, or whether they appeared as a result of the promised routing socket > changes. > > There was a brief moment where dhclient(4) tried to detect this particular > brand > of RTM_IFINFO message, where the link state basically went UP -> UP, but > pushing > on the logic a bit compacted it down to simply get a new lease when any > RTM_IFINFO message for the trunk(4). Except for MTU changes which is an > entirely > different rabbit hole. > > .... Ken > > > > > 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. -- I'm not entirely sure you are real.
