Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
谢谢回复。
关于第2点,你可能理解错了;我是指在路由器的web上修改网�
��设置并保存,会使/etc/config/dhcp文件中域名列表丢失,然后��
�又要去添加一遍。。。难道这是个案?
Original comment by titanium98118
on 13 Jan 2014 at 9:32
[deleted comment]
很遗憾没这一项,我是用gargoyle 1.5.11 http://www.gargoyle-router.com
基于openwrt 12.09,看来是没办法了。
Original comment by titanium98118
on 14 Jan 2014 at 7:14
[deleted comment]
[deleted comment]
[deleted comment]
新问题
今天试了用ssh
layer3模式,不知什么原因autopvpn.sh这个脚本,通过在终端下是
能正常连接的,但放到crontab后就不能正常连接了,我把pvpn开
了debug后在/tmp下的log也只记录了
[ 2014/01/16 23:56:01 ] restart pvpn
tun50:
[ 2014/01/16 23:57:01 ] restart pvpn
tun50:
难道又是固件的原因?
ps |grep -v grep|grep -qe "ssh.*-TCf\|pppd ifname pvpn"
if [ $? -ne 0 ] ;then
echo "[ `date +'%Y/%m/%d %H:%M:%S'` ] restart pvpn" >>/tmp/autopvpn.log
export SSH_ARGS="-p 22 -i /root/.ssh/id_rsa"
pvpn -d -t ssh-3 root@xxx.net 8.8.8.8 >>/tmp/autopvpn.log
fi
Original comment by titanium98118
on 16 Jan 2014 at 4:04
[deleted comment]
[deleted comment]
谢谢,找到原因了,
是因为我把openssh装在tf卡上了,pvpn没找到ssh的路径,我把ssh
ln -s 到/bin下就正常了。
Original comment by titanium98118
on 17 Jan 2014 at 2:35
近2天怎么回事呢?openvpn和ssh的阻塞好像挺严重的,经常连上��
�过一会儿就丢包严重
从路由ping服务端
64 bytes from 10.111.141.2: seq=0 ttl=64 time=36102.297 ms
64 bytes from 10.111.141.2: seq=1 ttl=64 time=35102.549 ms
64 bytes from 10.111.141.2: seq=2 ttl=64 time=34103.947 ms
64 bytes from 10.111.141.2: seq=3 ttl=64 time=33104.403 ms
64 bytes from 10.111.141.2: seq=4 ttl=64 time=32104.963 ms
64 bytes from 10.111.141.2: seq=5 ttl=64 time=31105.279 ms
64 bytes from 10.111.141.2: seq=6 ttl=64 time=30105.576 ms
64 bytes from 10.111.141.2: seq=7 ttl=64 time=29105.863 ms
64 bytes from 10.111.141.2: seq=8 ttl=64 time=28106.169 ms
64 bytes from 10.111.141.2: seq=9 ttl=64 time=27106.459 ms
64 bytes from 10.111.141.2: seq=10 ttl=64 time=26106.741 ms
64 bytes from 10.111.141.2: seq=11 ttl=64 time=25107.031 ms
64 bytes from 10.111.141.2: seq=12 ttl=64 time=24107.324 ms
64 bytes from 10.111.141.2: seq=13 ttl=64 time=23107.616 ms
64 bytes from 10.111.141.2: seq=14 ttl=64 time=22107.909 ms
64 bytes from 10.111.141.2: seq=15 ttl=64 time=21108.203 ms
64 bytes from 10.111.141.2: seq=16 ttl=64 time=20108.501 ms
64 bytes from 10.111.141.2: seq=17 ttl=64 time=19108.778 ms
64 bytes from 10.111.141.2: seq=18 ttl=64 time=18109.081 ms
64 bytes from 10.111.141.2: seq=19 ttl=64 time=17109.376 ms
64 bytes from 10.111.141.2: seq=20 ttl=64 time=16109.672 ms
64 bytes from 10.111.141.2: seq=21 ttl=64 time=15109.970 ms
64 bytes from 10.111.141.2: seq=22 ttl=64 time=14113.140 ms
64 bytes from 10.111.141.2: seq=23 ttl=64 time=13113.332 ms
64 bytes from 10.111.141.2: seq=24 ttl=64 time=12113.455 ms
64 bytes from 10.111.141.2: seq=25 ttl=64 time=11113.626 ms
64 bytes from 10.111.141.2: seq=26 ttl=64 time=10113.745 ms
64 bytes from 10.111.141.2: seq=27 ttl=64 time=9113.859 ms
64 bytes from 10.111.141.2: seq=28 ttl=64 time=8113.969 ms
64 bytes from 10.111.141.2: seq=29 ttl=64 time=7114.086 ms
64 bytes from 10.111.141.2: seq=30 ttl=64 time=6114.206 ms
64 bytes from 10.111.141.2: seq=31 ttl=64 time=5114.319 ms
64 bytes from 10.111.141.2: seq=32 ttl=64 time=4114.480 ms
64 bytes from 10.111.141.2: seq=33 ttl=64 time=3114.574 ms
64 bytes from 10.111.141.2: seq=34 ttl=64 time=2114.659 ms
64 bytes from 10.111.141.2: seq=35 ttl=64 time=1114.736 ms
64 bytes from 10.111.141.2: seq=36 ttl=64 time=419.316 ms
64 bytes from 10.111.141.2: seq=37 ttl=64 time=240.677 ms
64 bytes from 10.111.141.2: seq=38 ttl=64 time=245.866 ms
64 bytes from 10.111.141.2: seq=39 ttl=64 time=206.013 ms
64 bytes from 10.111.141.2: seq=40 ttl=64 time=201.292 ms
64 bytes from 10.111.141.2: seq=41 ttl=64 time=206.831 ms
64 bytes from 10.111.141.2: seq=42 ttl=64 time=214.684 ms
64 bytes from 10.111.141.2: seq=43 ttl=64 time=233.938 ms
64 bytes from 10.111.141.2: seq=44 ttl=64 time=219.890 ms
64 bytes from 10.111.141.2: seq=45 ttl=64 time=215.809 ms
64 bytes from 10.111.141.2: seq=46 ttl=64 time=211.734 ms
64 bytes from 10.111.141.2: seq=47 ttl=64 time=212.461 ms
64 bytes from 10.111.141.2: seq=48 ttl=64 time=200.994 ms
64 bytes from 10.111.141.2: seq=49 ttl=64 time=202.779 ms
64 bytes from 10.111.141.2: seq=50 ttl=64 time=210.338 ms
64 bytes from 10.111.141.2: seq=51 ttl=64 time=209.274 ms
64 bytes from 10.111.141.2: seq=52 ttl=64 time=212.956 ms
Original comment by titanium98118
on 17 Jan 2014 at 2:53
[deleted comment]
ssh layer3生成的tun设备要怎样卸载?
不知为什么服务器上的tun50一直在线,然后路由器再次连上ssh
后,服务端用了新的tun49
Original comment by titanium98118
on 17 Jan 2014 at 3:23
[deleted comment]
我发现打了path的dnsmasq进程会不定时地结束
好像也没什么方法能查出原因结西的原因
现在写了一脚本定时ps一下,如果dnsmasq的进程结束了就重启��
�下,囧
Original comment by titanium98118
on 19 Jan 2014 at 4:45
[deleted comment]
[deleted comment]
[deleted comment]
并没有kill -HUP `pgrep dnsmasq`这一行,我用的脚本就是#8那个。
目前我还没能找到更多信息。
邮件已收到。
PS:路由器为水星mw4530r
Original comment by titanium98118
on 19 Jan 2014 at 1:07
Original issue reported on code.google.com by
titanium98118
on 9 Jan 2014 at 1:53