On Sat, Jun 10, 2017 at 04:14:16PM +0200, Martin Pieuchot wrote: > If there's a real need for such arguments, because somebody use pppoe(4) > with static IP/route then why not. But that's not what you said. What > you said is that the current hack of 0.0.0.0+0.0.0.1 is broken.
Static IP/route setups with pppoe(4) do exist. Just buy business DSL. The problem I want to fix is allowing more than one dynamic connection. Static setups work either way, with or without my fix. In either case, just configure your real addresses upfront to get a fully static setup. > I'm not fan of your approach because it makes pppoe(4) special, does > umb(4) will need 'dynaddr' and 'dyntest' too? I consider this a quirk in sppp(4), not pppoe or p2p interfaces in general. sppp(4) is using these DYN flags which we're toggling. The new ifconfig commands are documented in ifconfig(8)'s 'SPPP' section for that reason. umb(4) does not use sppp(4). In my mind, making some IP addresses act as magic toggles for internal sppp(4) state flags is a worse hack than mine. The old hack even has an XXX comment saying it should be removed, added by its author. > So IMHO if what you want is fix the EEXIST, I'd do that. I see where you are coming from. Fixing the routing table as you suggest would make the old hack work again and also bring other benefits. You were saying your old diff was "the first of 14 steps." That project seems to be substantially more involved than my proposed patch, which took me just a few hours. It does not sound like a project I could start working on now (I am not even done reading xhci.c, let alone actually hacking on it). I have proposed an easy fix which works and which does not preclude future work being done on the routing table. But I won't insist. I don't expect leaving sppp(4) in a broken state will suddenly motivate anyone to do substantial work on the routing table, though. My guess is that sppp(4) will just stay broken for multiple connections.
