Summary: | net-dns/openresolv-3.4.1-r1: order of entries is not consistent with resolvconf -u on interface wakeup | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Renato Alves <simpledark> |
Component: | Current packages | Assignee: | Jim Ramsay (lack) (RETIRED) <lack> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alonbl |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
URL: | http://roy.marples.name/projects/openresolv/ticket/25 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
resolvconf log - wlan down, wlan up, resolvconf -u
Same a before, with more output Same a before, with more output and IF_METRIC openresolv-3.5.4-config-conflict.patch openresolv-3.5.4-r2.ebuild.diff |
Description
Renato Alves
2012-10-31 15:43:47 UTC
dup of bug#391175? Not quite sure. I installed the latest openvpn version (2.3.1) which should have the metric patch applied but after restarting the wireless I still get the same behavior (wireless nameserver takes priority). In addition I look at /var/run/resolvconf/metrics and only wlan seems to be present (0002003 wlan0) . tun0 is listed only under /var/run/resolvconf/interfaces. I looked at the changes on up.sh script on /etc/openvpn but couldn't figure out if metric is calculated automatically or if I need to set it somewhere. Thanks (In reply to comment #2) > I looked at the changes on up.sh script on /etc/openvpn but couldn't figure > out if metric is calculated automatically or if I need to set it somewhere. Do you have route-metric=XXX in your openvpn configuration? I didn't, but adding it didn't solve the problem. First I added "route-metric=3000" openvpn complained it could parse this line. Changed it to "route-metric 3000" and openvpn restarted but now the VPN nameserver became second on list immediately. Even after resolvconf -u it remained as second on list. I then changed it to "route-metric 1000" (wlan seems to use 2003) and at start the nameserver becomes first priority as expected. However if I break wlan connection and restore it few seconds after the wlan nameserver still becomes first on resolv.conf regardless of the metric defined. In the last case running resolvconf -u manually makes vpn's nameserver to become first priority again. With this it doesn't seem like a dup of bug#391175. Last comment should read: First I added "route-metric=3000" openvpn complained it *couldn't* parse this line. I use net-dns/openresolv-3.5.4-r2 and this sequence seems to be OK. I just upgraded openresolv to the same version you mentioned but I still get the same behavior. Was using openresolv-3.4.1-r1 before. One thing to add to the initial bug report is that at step 4 resolv.conf becomes: search ivpn nameserver 10.1.1.1 Any clue what other packages could be affecting this? Please attach /etc/conf.d/net This is all I have, the rest is commented. config_eth0="dhcp" dhcpcd_eth0="-L -I '' -t 60" fallback_eth0="192.168.176.150/24" fallback_route_eth0="default via 192.168.176.150" modules_wlan0="wpa_supplicant" wpa_supplicant_wlan0="-W -B -Dwext -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf" config_wlan0="dhcp" dhcpcd_wlan0="-L -I '' -t 120" associate_order="forcepreferred" blacklist_aps='"guest-eduroam" "default"' OK, this is not bug#400845. Just to make sure... You have both openvpn and wlan connected. openresolv -l - shows both /etc/resolv.conf - shows both You stop wlan openresolv -l - shows vpn /etc/resolv.conf - shows vpn You start wlan (wait for dhcp) openresolv -l - shows both /etc/resolv.conf - shows vpn You execute openresolv -u openresolv -l - shows both /etc/resolv.conf - shows both Right? You do have sys-apps/ifplugd installed, right? Not exactly. at: " You start wlan (wait for dhcp) openresolv -l - shows both /etc/resolv.conf - shows vpn " mine gives: Output of "resolvconf -l": # resolv.conf from tun0 # Generated by openvpn for interface tun0 domain ivpn-domain nameserver 10.1.1.1 # resolv.conf from wlan0 # Generated by dhcpcd from wlan0 nameserver 192.168.1.1 Output of "cat /etc/resolv.conf": # Generated by resolvconf domain ivpn-domain nameserver 192.168.1.1 <--- wlan nameserver 10.1.1.1 <--- vpn And after *resolvconf -u* Output of "resolvconf -l": # resolv.conf from tun0 # Generated by openvpn for interface tun0 domain ivpn-domain nameserver 10.1.1.1 # resolv.conf from wlan0 # Generated by dhcpcd from wlan0 nameserver 192.168.1.1 Output of "cat /etc/resolv.conf": # Generated by resolvconf domain ivpn-domain nameserver 10.1.1.1 <--- vpn nameserver 192.168.1.1 <--- wlan I don't have ifplugd installed but I do have sys-apps/netplug-1.2.9-r5. Well... I cannot explain that! Best to update /sbin/resolvconf and add some debug info. Just after the first line add: { echo "LOG-END $$" date echo "$*" ps -efa find /var/run/resolvconf/ echo "LOG-END $$" } >> /tmp/resolvconf.log Created attachment 348008 [details]
resolvconf log - wlan down, wlan up, resolvconf -u
Well, still have no clue. Let's come back to the basics... What happens if you: resolvconf -d wlan0 echo "nameserver 192.168.1.1" | resolvconf -a wlan0 -m 2003 Do you see the order is incorrect? If so, can you please send me: resolvconf -d wlan0 echo "nameserver 192.168.1.1" | resolvconf -a wlan0 -m 2003 2> /tmp/resolvconf.debug.log If not, lets try to put the following in the resolvconf script: { echo "LOG-BEGIN $$" date echo "$*" ps -efa find /var/run/resolvconf/ echo "LOG-END $$" } >> /tmp/resolvconf.log exec 2>> /tmp/resolvconf.log set -x Thanks! Created attachment 348034 [details]
Same a before, with more output
Running:
resolvconf -d wlan0
echo "nameserver 192.168.1.1" | resolvconf -a wlan0 -m 2003
Actually kept vpn as first on the list, as opposed to what happens when I bring the wlan0 interface down.
Added log with more output as requested.
Are you sure you running net-dns/openresolv-3.5.4-r2? And can you please add the following to the debug: echo "${IF_METRIC}" (In reply to comment #9) > modules_wlan0="wpa_supplicant" above can be global... modules="wpa_supplicant" > wpa_supplicant_wlan0="-W -B -Dwext -iwlan0 > -c/etc/wpa_supplicant/wpa_supplicant.conf" Why isn't this simply: wpa_supplicant_wlan0="-D nl80211" Or if you have very old card: wpa_supplicant_wlan0="-D wext" Not that it is related... Created attachment 348036 [details]
Same a before, with more output and IF_METRIC
* net-dns/openresolv
Latest version available: 3.5.4-r2
Latest version installed: 3.5.4-r2
Quite sure about the version.
Attached the same as before plus the metric as requested.
echo "${IF_METRIC}" added after set -x
What do you have at /etc/resolvconf.conf ? It seems you have non default interface_order. This is my resolvconf.conf # Configuration for resolvconf(8) # See resolvconf.conf(5) for details resolv_conf=/etc/resolv.conf # If you run a local name server, you should uncomment the below line and # configure your subscribers configuration files below. #name_servers=127.0.0.1 OK... Go to /lib64/dhcpcd/dhcpcd-run-hooks for list_interfaces and add: --- { + local interface_order (In reply to comment #23) > OK... > > Go to /lib64/dhcpcd/dhcpcd-run-hooks for list_interfaces and add: > --- > { > + local interface_order wait, it won't help... but this is the problem... will figure out how best to solve it. (In reply to comment #24) > (In reply to comment #23) > > OK... > > > > Go to /lib64/dhcpcd/dhcpcd-run-hooks for list_interfaces and add: > > --- > > { > > + local interface_order > > wait, it won't help... but this is the problem... will figure out how best > to solve it. add the following at top of /sbin/resolvconf --- unset interface_order --- > add the following at top of /sbin/resolvconf
> ---
> unset interface_order
> ---
This one fixed it.
I also did a grep on /etc for interface_order but got no matches. I've no idea where this comes from. Created attachment 348086 [details, diff]
openresolv-3.5.4-config-conflict.patch
Created attachment 348088 [details, diff]
openresolv-3.5.4-r2.ebuild.diff
Sorry it took so long to figure this out. Can you please confirm this works? Thanks! Yup the attached patches fix it. Thanks for the good detective work. Hello lack, Can you please commit this or should I. Thanks, Alon Fixed in openresolv-3.5.4-r3. |