XPost: linux.debian.bugs.dist 
 From: tglaser@b1-systems.de 
  
 (@all please keep me in Cc, d-devel is too high-volume to subscribe) 
  
 Hi Daniel, 
  
 >Unfortunately dhcpcd-base breaks most assumptions :D. 
  
 this is€€€ sad. Thanks, again, for working on this and for writing 
 so detailled about it. 
  
 >I assume you're talking about IPv4-LL? I'm disabling that from ifupdown 
 >now so a new option to neutralize it shouldnt be needed going forward. 
  
 Nice! 
  
 Although, you wrote€€€ 
  
 > - inet6 auto has accept_ra=2 by default (which is questionable 
 IMO), 
 > - inet6 dhcp has accept_ra=1 
  
  
  
  
  
  
  
  
 > - inet6 static has accpet_ra=0 
  
  
  
  
  
  
  
 €€€ but there€€€s a fourth: just €€€inet dhcp€€€ and no inet6 stanza, 
 which should also continue to operate with accept_ra=1, unless 
 changed by the user. 
  
 That€€€s the one I use in my €€€uncomplicated€€€ setups, and the one 
 I expect to do the following: 
  
 - configure link-local address based on MAC EUI64 
 - let the kernel listen to rtadvd on the LAN and apply its config 
  
 (I€€€ve been bitten by ifup/ifdown issues when listing both inet 
 and inet6 for the same interface in the past.) 
  
 I€€€ve never seen inet6 auto used anywhere, only inet6 static (and 
 I€€€ve not personally encountered inet6 dhcp yet, and given rtadvd 
 and rtsol work, I don€€€t quite see the use for most networks). 
  
 For €€€inet6 static€€€ I expect it to set up the link-local address 
 and the one given in address and gateway, if any, and not do rtsol. 
  
 >I learned ifupdown actually has an established `inet ipv4ll` method 
 >which would have been the right integration point for controlling this. 
  
 Ah, good. 
  
 >> Thanks for caring. I€€€ll be available for testing that (on a trixie 
 >> setup so with extra effort), if needed. 
 > 
 >See "Finishing deprecation of isc-dhcp-client in ifupdown" on d-devel with 
 >rationale and code https://lists.debian.org/debian-devel/2025/1 
 /msg00201.html. 
  
 So, basically this? 
  
 >Proposed ifupdown unstable upload: 
 >  [17]https://salsa.debian.org/debian/ifupdown/-/merge_requests/28 
  
 I can give this a spin on trixie. If I understood correctly from 
 the threads, I can revert the /etc/dhcpcf.conf change€€€ 
  
  # Generate SLAAC address using the Hardware Address of the interface 
 -#slaac hwaddr 
 +slaac hwaddr 
  # OR generate Stable Private IPv6 Addresses based from the DUID 
 -slaac private 
 +#slaac private 
  
 €€€ with this, as ifupdown handles it, right? 
  
 While there, I do have more questions related to it. 
  
 +option ntp_servers 
  
 Where would that be handled? If I wanted to, where do I have 
 to look to write integration for this for? (I use a custom 
 OpenNTPD packaging.) 
  
 +# hands off 
 +nohook resolv.conf, hostname, timezone, lookup-hostname 
  
 Is there a way to control this from ifupdown (for both ISC 
 and dhcpcd)? 
  
 >In unstable dhcpcd.service starts After=networking.service (ifup) meaning 
 >it triggers this conflict reproducibly. In Trixie no Before/After on 
 >networking is declared so the conflict will happen non-deterministically -- 
 >oh joy. 
  
 Oh wow. So, note taken, do not install the dhcpcd package (let€€€s hope 
 nothing Recommends it). 
  
 Note that it could also be started from /etc/init.d/dhcpcd, so 
 ordering there also needs to be correct. 
  
 >That leaves us to think about what to do about current and future Trixie 
 >users: Retract the isc-dhcp-client deprecation? Fix it all in a stable 
 >update? 
  
 Likely not going to happen, as it has no security support. 
  
 (But, good to know that for systems with more complex networking 
 setups that are remote (thus hard to fix if somethign goes wrong) 
 I can still install isc-dhcp-client and keep dhcpcd-base away and 
 things continue to work€€€ for now. IIUC?) 
  
 When I test your branch, did you also address the issue of, again 
 with a config just saying €€€iface eth0 inet dhcp€€€ (no inet6), plus 
 wireless-* and wpa-* for WLAN as needed, that€€€ 
  
 - I expect to not be assigned a Microsoft address; rather, either 
   an address from a DHCP server with much waiting or no address 
   and default route at all 
  
 - I expect the address and default gateway to be usable for both 
   post-up scripts and commands executed immediately after ifup 
   returns, which is currently not the case (I have to add a manual 
   five-second-or-so sleep) 
  
 (€€€expect€€€ here does not mean €€€I demand the maintainers do this 
 immediately€€€, I use it with the meaning €€€this is how things work 
 in older releases, so from the principle of least surprise this 
 is what I, as user, expect from newer releases€€€) 
  
 THanks in advance, 
 //Thorsten 
 -- 
 Thorsten Glaser 
 Linux / Unix Developer 
 Tel.: +49 160 91168501 
 E-Mail: tglaser@b1-systems.de 
  
 B1 Systems GmbH 
 Osterfeldstra€€e 7 / 85088 Vohburg / https://www.b1-systems.de/ 
 GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)