Can we restart dnsmasq in the end of vpnup.sh under wget mode?

[GoogleCodeExporter]

請描述一下您進行怎樣的操作之後碰到了問題
1.start router, wait pptp connected
2.wait several hours until router's pptp reconnected
3.twitter cannot connect since it's dns responce is poisoned

你期待是怎樣的結果，然而卻出現了什麼情形？
the dns response, when the vpn is starting has already been poisoned, even 
after vpn is connected. I think the vpnup.sh should automatically drop all old 
dns cache, since in classic mode no more customization can be done in dns level.

請提供以下資訊：

1. 您的路由器型號：Buffalo WHR-HP-G54 
2. DD-WRT版本：DD-WRT v24-sp2 (08/07/10) vpn - build 14896
3. 您的作業系統：Snow Leopard 10.6.8, Lion 10.7.2, Windows 7 SP1, iOS 
5.0.1, Android 4.0.1
4. 您的瀏覽器版本：chrome dev, mobile safari, v8 lite
5. autoddvpn的連線模式(pptp+wget, pptp+jffs, openvpn+jffs等)：pptp+wget
6. 
autoddvpn的運行模式，傳統模式(classicMode)還是優雅模式(graceMode
)：classicMode
7. DD-WRT WAN口連線模式是 pptp or dhcp or static ：pppoe
8. 運行autoddvpn之後DD-WRT 的命令輸出 # route -n  | tail -n 20 ：
182.96.0.0      masked.1     255.224.0.0     UG    0      0        0 ppp0
36.192.0.0      masked.1     255.224.0.0     UG    0      0        0 ppp0
111.0.0.0       masked.1     255.192.0.0     UG    0      0        0 ppp0
61.128.0.0      masked.1     255.192.0.0     UG    0      0        0 ppp0
223.64.0.0      masked.1     255.192.0.0     UG    0      0        0 ppp0
36.128.0.0     masked.1     255.192.0.0     UG    0      0        0 ppp0
117.128.0.0    masked.1     255.192.0.0     UG    0      0        0 ppp0
59.192.0.0      masked.1     255.192.0.0     UG    0      0        0 ppp0
183.192.0.0     masked.1     255.192.0.0     UG    0      0        0 ppp0
183.0.0.0       masked.1    255.192.0.0     UG    0      0        0 ppp0
39.128.0.0      masked.1     255.192.0.0     UG    0      0        0 ppp0
113.64.0.0      masked.1     255.192.0.0     UG    0      0        0 ppp0
116.128.0.0   masked.1     255.192.0.0     UG    0      0        0 ppp0
120.192.0.0    masked.1     255.192.0.0     UG    0      0        0 ppp0
112.0.0.0       masked.1    255.192.0.0     UG    0      0        0 ppp0
39.0.0.0        masked.1     255.0.0.0       UG    0      0        0 ppp0
106.0.0.0       masked.1     255.0.0.0       UG    0      0        0 ppp0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.x.1     0.0.0.0         UG    0      0        0 ppp1
0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 ppp1

(以上1-8點必填，否則可能沒辦法即時協助你解決問題)

如果方便的話，請參考這裡的說明，貼上autoddvpn.log內容
(說明：http://code.google.com/p/autoddvpn/wiki/DEBUG)
tail -f /tmp/autoddvpn.log 
[INFO#32063] 03/Jan/2012:14:42:33 add default gw 192.168.x.1
[INFO#32063] 03/Jan/2012:14:42:33 adding the static routes, this may take a 
while.
[INFO#32063] 03/Jan/2012:14:43:14 preparing the exceptional routes
[INFO#32063] 03/Jan/2012:14:43:14 modifying the exceptional routes
[INFO#32063] 03/Jan/2012:14:43:14 modifying custom exceptional routes if 
available
[INFO#32063] 03/Jan/2012:14:43:14 adding custom host/subnet MASKEDCIDR via 
wan_gateway
[INFO#32063] 03/Jan/2012:14:43:14 adding custom host/subnet MASKEDCIDR via 
wan_gateway
[INFO#32063] 03/Jan/2012:14:43:14 adding custom host/subnet MASKEDCIDR via 
wan_gateway
[INFO#32063] 03/Jan/2012:14:43:15 adding custom host/subnet MASKEDCIDR via 
wan_gateway
[INFO#32063] 03/Jan/2012:14:43:16 vpnup.sh ended

最後如果可能的話，請附上截屏或任何可能有幫助的夾檔
#after pptp reconnect( vpnup.sh ended ), before dnsmasq restart
ping twitter.com
PING twitter.com (159.106.121.75): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 0
Request timeout for icmp_seq 0
Request timeout for icmp_seq 0
^C
--- twitter.com ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
#after manually restart dnsmasq via stopservice & startservice
ping twitter.com
PING twitter.com (199.59.148.82): 56 data bytes
64 bytes from 199.59.148.82: icmp_seq=0 ttl=52 time=387.097 ms
64 bytes from 199.59.148.82: icmp_seq=1 ttl=52 time=407.534 ms
64 bytes from 199.59.148.82: icmp_seq=2 ttl=52 time=324.996 ms
64 bytes from 199.59.148.82: icmp_seq=3 ttl=52 time=321.665 ms
^C
--- twitter.com ping statistics ---
5 packets transmitted, 4 packets received, 20.0% packet loss
round-trip min/avg/max/stddev = 321.665/360.323/407.534/37.710 ms

Original issue reported on code.google.com by ptp...@gmail.com on 3 Jan 2012 at 8:49

[GoogleCodeExporter]

所以你的問題是，在vpnup.sh進行中，DDWRT甚至你的電腦都有被D
NS poisoned的風險是吧？

Original comment by pahud...@gmail.com on 3 Jan 2012 at 8:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

我現在手邊沒有DDWRT可以測試，但我記得DDWRT裡面有個restart_dn
s命令，你看看執行這個命令是否會強迫clear dnsmasq cache

如果有用的話，你試試看這樣

cd /tmp;wget http://autoddvpn.googlecode.com/svn/trunk/pptp/wget/run.sh  && 
/bin/sh run.sh && restart_dns || touch failed

看看是不是有幫助

Original comment by pahud...@gmail.com on 3 Jan 2012 at 9:04

[GoogleCodeExporter]

Thanks, this command works excellently. But the problem is I need the 
restart_dns run everytime in the end of vpnup.sh, or next time when it 
reconnecting the dns will be poison again - you know when pptp reconnect it 
cost several minute. So can we directly put it in the pptp-wget classic mode's 
source code? Or is there any way I can insert some shell code in nvram that 
runs just after pptp connect?

Original comment by ptp...@gmail.com on 3 Jan 2012 at 10:03

[GoogleCodeExporter]

vpnup.sh最後我加入restart_dns的動作了，請試試看吧！

detail: 
http://code.google.com/p/autoddvpn/source/diff?spec=svn544&r=544&format=side&pat
h=/trunk/vpnup.sh

Original comment by pahud...@gmail.com on 3 Jan 2012 at 10:14

[GoogleCodeExporter]

Thanks, verified works well in production situation!
Now the only problem is the wget mode always fallback when click "Apply" in 
DD-WRT web interface, that makes all generated file like /tmp/pptp_client/ip-up 
revert to original form(before patched by run.sh), but that seems hard to fix, 
until there's a way to hook script after Apply. 
Anyway, thanks for the fix:) This issue can be close now.

Original comment by ptp...@gmail.com on 4 Jan 2012 at 9:02

[GoogleCodeExporter]

Original comment by pahud...@gmail.com on 4 Jan 2012 at 9:04

• Changed state: Fixed