On 2012-06-24 3:18 AM, Daniel Golle wrote: > Hi! > > From what I can see, the udhcpc script currently doesn't support any way to > not > set or override the default-gateway. Support for that is already part of netifd in a proto-independent way.
> In some cases (here: I connect to an non-routed infrastructure using DHCP, > then > use PPP-over-L2TP on top of it to get to the Internet) this would be feasible. > > The scenario looks like this: > The default gateway passed-down via DHCP from the modem-interface is useful > piece of information, even if we don't use it as a default route. > In my situation, however, I want to use this DHCP-supplied default gateway > for a > couple of destinations only, to be precise: the (inside-infrastructure-only) > DHCP-supplied DNS servers which allow resolving the address of the > L2TP-server(s) and the L2TP-server(s) themselves. > > For now, I can do this only by setting the interface connected to the > cable-modem up with a static IP, but this works only if I never disconnect > longer than the DHCP lease-time and I do get different IPs assigned by the > infrastructure once the lease has expired. This can even be on a entirely > different subnet and include different DNS servers. (ouch!) > > So as long as I keep it always-on, it's ok. I use only the address and the > netmask in the interface configuration and setup a couple of static routes to > the DNS server and (potential) L2TP-servers. Instead of directly using the > DNS-servers, I tell dnsmasq to only use the DNS-servers for resolving the > L2TP-servers address, like this: > > config dnsmasq > option domainneeded '1' > option boguspriv '1' > ... > list rebind_domain '[l2tp-server]' > list bogusnxdomain '192.168.101.101' > list bogusnxdomain '192.168.101.102' > list server '/[l2tp-server]/192.168.101.101' > list server '/[l2tp-server]/192.168.101.102' > > > This is not very nice as: > - I got to hard-code 192.168.101.101, those might change and I should use the > DNS servers passed-over by DHCP. > - I got to setup static routes to the DNS-servers, here also, the ones > supplied > via DHCP should be used. > - I got to include the name of the L2TP-server in dnsmasqs config. > - I got to setup static routes to the L2TP-server addresses as well, this > should > be resolved via DNS. > > > I suggest to add options to DHCP-configured interfaces: > - use_gateway_as_defaultroute (would be disabled in my case) There is already the 'defaultroute' option (defaults to 1). Set that to 0 and netifd will not apply udhcpc's default route. > - use_gateway_for_dns_servers (would be enabled in my case) > - usepeerdns (would be disabled in my case) There's the 'peerdns' option, also supported for all proto handlers. > though we don't use the gateway as default route and do not set the dns-server > in /tmp/resolv.conf.auto, both pieces of information should still be > available, > so once the l2tp interface wants to fire up, it can use those dns-servers to > resolve the l2tp-servers IPs and setup routes via the dhcp-supplied default > gateway. You can extract the provided DNS server and default gateway (even when unused) by using the ifstatus script (which simply does a ubus call). > Probably it would be a good idea to let the user select the parent-interface > for > PPtP and L2TP links instead of dynamically adding the interface-dependencies > based on routes, as that won't always work nicely (especially when there is > more > than one such interface providing a potential default route). Yep, that's on my todo list as well. > I guess I'm not the only one in that mess (PPPoL2TPv2 on top of a non-routed > IPv4 cable infrastructure should be a common case in many places afaik) and > would like to know your opinions on how can we solve that in the right way. > The > goal should be that it works out-of-the-box, it should be maintainance-free > (currently isn't) and also easy to setup for newbies. Only a few minor details are missing to make that work. - Felix _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
