On Thu, 2013-06-13 at 15:27 -0500, Dan Williams wrote: > Because the parent device config is passed to the dispatcher here, which > pulls out the DHCP options. Given that VPN connections don't currently > have DHCP capability, I'd expect clients to ignore that information. > > For proxy configuration, we'd define new PROXY_ env variables that > contain the merged proxy configuration from various sources, including > DHCP and VPN.
OK. > > In each case you may want to trust or distrust certain information > > according to whether it comes from DHCPv4 or DHCPv6 or RA or VPN server > > or wpad.$searchdomain or wherever. But that isn't fundamentally a Legacy > > IP vs. IPv6 distinction and it's wrong to make it one as we have > > historically done. > > Yeah, except that it's *delivered* via those mechanisms, and who knows > whether they talk to each other. I know we argued about this on IRC and > I think we mostly agree; they are global *after* NM receives them and > combines them with user overrides, but their sources are clearly > stack-specific and users may want/need to override them that way. No. Their sources are *not* stack-specific. There is *no* reason to lump DHCPv6 along with RA under "IPv6", while DHCPv4 is under "IPv4" and what we get given from a VPN server is... well, who the hell knows? That *isn't* a meaningful classification. It *doesn't* make sense to say "trust this information if I received it from an IPv6 source" vs. "trust this information if I received it from an IPv4 source". That *isn't* the interesting distinction between the sources. And it doesn't make sense to say "add <this> search domain or <this> DNS server to the list if you happen to pick up an IPv6 address somehow". I can't think of any valid use case for that one either. You might say "DO *NOT* use <this> nameserver if you happen to pick an IPv6 address somehow", if you have a known-broken but local and fast nameserver, so when you *are* stuck in the 20th century without IPv6, you want to use it anyway. But we don't support that use case anyway. We can only *add* nameservers when there's IPv6, not remove them. > But yes they are obviously global when written out to the system, like proxy > information is. > > > > And I have no idea how a client would make > > > a decision on which PAC URL to use if they had more than one? > > > > For now my dispatcher script (bug #701824) just punts that question, on > > the basis that if you have more than one, it's probably because you have > > split-tunnel VPN. And if you have split-tunnel VPN, it's probably done > > *specifically* to avoid having to use the damn corporate proxies for > > real "Internet" access, so just having no proxy should be fine. > > Hmm, not sure we can assume that. I'd rather do "use first one". Split > tunnel doesn't have anything to do with it though, right? In practice, "use first one" is more likely to be wrong, for now, than "bail and use none". It's not as if "do the right thing with all available configs simultaneously" is far off. But one thing at a time. > > Well, lets start with something like an internal NMProxyConfig just like > we have NMIPxConfig; export that over the bus just like the other two, > and stuff the PAC URL into it. We can add the other manual settings > later if/when we get NMSettingProxy. Then you can populate ProxyConfig > with the info from VPN and info from DNS, and eventually the dispatcher > can use it too. How does that sound? I'll take a look. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
