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. 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. 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. .... Ken
