[cpulink]

На версии 1.3.7 есть проблема с l2tp. На более низких возможно тоже, но видимо накопительная штука.

Вот что дает статистика показывает:

accel-ppp version 1.3.7
accel-ppp# show stat
uptime: 2.08:16:46
cpu: 5%
mem(rss/virt): 50680/239444 kB
core:
 mempool_allocated: 36501730
 mempool_available: 1023192
 thread_count: 5
 thread_active: 1
 context_count: 1546
 context_sleeping: 1
 context_pending: 0
 md_handler_count: 5839
 md_handler_pending: 2
 timer_count: 3086
 timer_pending: 1
ppp:
 starting: 0
 active: 1431
 finishing: 0
pptp:
 starting: 0
 active: 1209
l2tp:
 starting: 496
 active: 222
radius:
 auth sent: 11380
 auth lost(total/5m/1m): 122/0/0
 auth avg query time(5m/1m): 362/470 ms
 acct sent: 20033
 acct lost(total/5m/1m): 1098/9/0
 acct avg query time(5m/1m): 17/23 ms
 interim sent: 255251
 interim lost(total/5m/1m): 0/0/0
 interim avg query time(5m/1m): 40/39 ms

Настораживает большое количество l2tp старт 496, при этом сервер в соединении отказывает - ошибка 678.

В логах в это время:

[2011-08-19 17:51:11]: error: : l2tp: connect(tunnel): File exists
[2011-08-19 17:51:11]:  info: : disconnected
[2011-08-19 17:51:12]: error: : l2tp: connect(tunnel): File exists
[2011-08-19 17:51:12]:  info: : disconnected
[2011-08-19 17:51:17]: error: : l2tp: connect(tunnel): File exists
[2011-08-19 17:51:17]:  info: : disconnected

5-7 минут позднее

uptime: 2.08:30:16
cpu: 8%
mem(rss/virt): 50684/239444 kB
core:
 mempool_allocated: 33056858
 mempool_available: 1269908
 thread_count: 5
 thread_active: 1
 context_count: 1394
 context_sleeping: 1
 context_pending: 0
 md_handler_count: 5240
 md_handler_pending: 1
 timer_count: 2766
 timer_pending: 1
ppp:
 starting: 0
 active: 1282
 finishing: 0
pptp:
 starting: 0
 active: 1083
l2tp:
 starting: 961
 active: 199
radius:
 auth sent: 11418
 auth lost(total/5m/1m): 122/0/0
 auth avg query time(5m/1m): 0/0 ms
 acct sent: 20260
 acct lost(total/5m/1m): 1122/9/3
 acct avg query time(5m/1m): 26/30 ms
 interim sent: 258902
 interim lost(total/5m/1m): 0/0/0
 interim avg query time(5m/1m): 44/55 ms
accel-ppp#  

При чем до этого заметил одну странность - при одновременном коннекте юзеров, возможна ситуация, что

обоим присваивается один и тот же номер ppp интерфейса, что с этим происходит дальше, не понятно.

При чем может быть одновременное pptp и pptp, а может разное pptp и l2tp. В логах выглядит

как конект одного, и тутже в эту же секунду другого. На l2tp замечено в статистике - никто не конектится, а в статистике висит,

что 10 на подключении и так и будет висеть...

Вот пример 2х pptp:

[2011-08-17 09:31:09]:  info: ppp21: recv [RADIUS Accounting-Response id=1]
[2011-08-17 09:31:14]:  info: ppp23: connect: ppp23 <--> pptp(10.0.100.36)
[2011-08-17 09:31:15]:  info: ppp23: connect: ppp23 <--> pptp(10.0.41.199)
[2011-08-17 09:31:15]:  info: ppp24: connect: ppp24 <--> pptp(10.0.145.253)
[2011-08-17 09:31:15]:  info: ppp25: connect: ppp25 <--> l2tp(10.0.110.160)
[2011-08-17 09:31:16]: error: ppp23: pptp: read: Connection reset by peer
[2011-08-17 09:31:16]:  info: ppp23: disconnected
[2011-08-17 09:31:17]:  info: ppp26: connect: ppp26 <--> pptp(10.0.86.101)
[2011-08-17 09:31:17]:  info: ppp27: connect: ppp27 <--> pptp(10.0.63.28)
[2011-08-17 09:31:18]:  info: ppp23: send [RADIUS Access-Request id=1....

[2011-08-17 09:34:41]:  info: ppp18: disconnected
[2011-08-17 09:34:44]:  info: ppp18: connect: ppp18 <--> pptp(10.0.100.36)
[2011-08-17 09:34:44]:  info: ppp18: connect: ppp18 <--> pptp(10.0.77.171)
[2011-08-17 09:34:44]:  info: ppp79: connect: ppp79 <--> l2tp(10.0.125.235)
[2011-08-17 09:34:46]: error: ppp18: pptp: read: Connection reset by peer
[2011-08-17 09:34:46]:  info: ppp18: disconnected
[2011-08-17 09:34:47]:  info: ppp18: send [RADIUS Access-Request id=1 ... "10.0.125.235"..]
......
[2011-08-17 09:34:48]:  info: ppp18: 20784-02-2011: authentication successed

[adron2]

adron2, у тебя хреновая связь, большие потери пакетов

 

Странно но потерь пакетов вообще нет.

--- 172.20.100.224 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 2401ms
rtt min/avg/max/mdev = 1.884/2.274/5.276/0.358 ms, ipg/ewma 2.403/2.479 ms

 

При этом эти же роутеры на 0.8.5 работают идеально.

Вот лог с 0.8.5

Aug 19 13:07:45 core0-ylt pptp[13182]: using channel 2266
Aug 19 13:07:45 core0-ylt pptp[13182]: sent [LCP ConfReq id=0x1 <mru 1400> <asyncmap 0x0> <auth chap MS-v2> <magic 0x2a72fa0e> <pcomp> <accomp>]
Aug 19 13:07:46 core0-ylt pptp[13182]: rcvd [LCP ConfReq id=0x4 <mru 1400> <asyncmap 0x0> <magic 0x7ae58e2c> <pcomp> <accomp>]
Aug 19 13:07:46 core0-ylt pptp[13182]: sent [LCP ConfAck id=0x4 <mru 1400> <asyncmap 0x0> <magic 0x7ae58e2c> <pcomp> <accomp>]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [LCP ConfReq id=0x1 <mru 1400> <asyncmap 0x0> <auth chap MS-v2> <magic 0x2a72fa0e> <pcomp> <accomp>]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [LCP ConfAck id=0x1 <mru 1400> <asyncmap 0x0> <auth chap MS-v2> <magic 0x2a72fa0e> <pcomp> <accomp>]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [LCP EchoReq id=0x0 magic=0x2a72fa0e]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [CHAP Challenge id=0x51 <e1e813a8a97444bb40eb8ec5fedce6c5>, name = "pptpd"]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [LCP EchoReq id=0x0 magic=0x7ae58e2c]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [LCP EchoRep id=0x0 magic=0x2a72fa0e]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [LCP EchoRep id=0x0 magic=0x7ae58e2c]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [CHAP Response id=0x51 <141b85cff51c81d844dce560064d14f400000000000000000ad42600f9dc269da8d6de52129c7605cef3d09f8936c24800>, name = "shlyk"]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [CHAP Success id=0x51 "S=54C98A7076720DFB8281D12082327700A78272D8"]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [CCP ConfReq id=0x3 <mppe +H -M +S +L -D -C>]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [CCP ConfNak id=0x3 <mppe +H -M +S -L -D -C>]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [CCP ConfReq id=0x4 <mppe +H -M +S -L -D -C>]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [CCP ConfAck id=0x4 <mppe +H -M +S -L -D -C>]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [iPCP ConfReq id=0x1 <addr 10.10.10.1>]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [iPCP ConfReq id=0x4 <compress VJ 0f 01> <addr 10.10.51.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [iPCP ConfRej id=0x4 <compress VJ 0f 01>]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [iPCP ConfAck id=0x1 <addr 10.10.10.1>]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [iPCP ConfReq id=0x5 <addr 10.10.51.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [iPCP ConfNak id=0x5 <ms-dns1 10.10.10.1> <ms-dns2 10.10.10.1>]
Aug 19 13:07:48 core0-ylt pptp[13182]: rcvd [iPCP ConfReq id=0x6 <addr 10.10.51.65> <ms-dns1 10.10.10.1> <ms-dns2 10.10.10.1>]
Aug 19 13:07:48 core0-ylt pptp[13182]: sent [iPCP ConfAck id=0x6 <addr 10.10.51.65> <ms-dns1 10.10.10.1> <ms-dns2 10.10.10.1>]
Aug 19 13:07:48 core0-ylt pptp[13182]: Script /etc/ppp/ip-up started (pid 13185)
Aug 19 13:07:48 core0-ylt pptp[13182]: Script /etc/ppp/ip-up finished (pid 13185), status = 0x0
Aug 19 14:05:06 core0-ylt pptp[13182]: rcvd [LCP TermReq id=0x5 "MPPE disabled"]
Aug 19 14:05:06 core0-ylt pptp[13182]: Script /etc/ppp/ip-down started (pid 2934)
Aug 19 14:05:06 core0-ylt pptp[13182]: sent [LCP TermAck id=0x5]
Aug 19 14:05:06 core0-ylt pptp[13182]: rcvd [LCP TermReq id=0x6 "MPPE disabled"]
Aug 19 14:05:06 core0-ylt pptp[13182]: sent [LCP TermAck id=0x6]
Aug 19 14:05:06 core0-ylt pptp[13182]: Script /etc/ppp/ip-down finished (pid 2934), status = 0x0
Aug 19 14:05:07 core0-ylt pptpd[13181]: CTRL: Reaping child PPP[13182]

[andretty]

Уткнулся я лбом в такую вот бетонную стену: пытаюсь заставить совместно работать модуль dynashape от билинга utm5 и accel-ppp. Основная проблема в динамическом (без дропа ppp сессии) изменении ограничений шейпера на интерфейсе. По докам к utm5 при смене установленных в настройках условий (в моем случае времени суток) radius сервер отправляет NAS'у пакет, содержащий новые значения атрибутов шейпера. Судя по логам utm, он их таки отправляет

...
?Debug : Aug 24 22:00:08 b684fb70 Radius: Got 2 shaping radius attributes
?Debug : Aug 24 22:00:08 b684fb70 Radius: Sending shaping attr slink_id <1566> vendor_id <0> attr_id <230> length <5>
?Debug : Aug 24 22:00:08 b684fb70 Radius: Sending shaping attr slink_id <1566> vendor_id <0> attr_id <231> length <5>
...

правда неизвестно (но могу выяснить) каким типом пакета. Но вот accel-ppp наверное игнорирует приходящий пакет (может просто не знает что с ним делать) т.к. по логам и реально, после момента подключения абсолютно ничего не происходило

ppp539: 0040de0f53557093: connect: ppp539 <--> pppoe(00:a0:c9:af:4e:84)
ppp539: 0040de0f53557093: send [LCP ConfReq id=1 <auth MSCHAP-v1> <mru 1400> <magic 4f5ea0a0>]
ppp539: 0040de0f53557093: recv [LCP ConfReq id=1 <mru 1492> <magic b1d6f7e1>]
ppp539: 0040de0f53557093: send [LCP ConfAck id=1 ]
ppp539: 0040de0f53557093: recv [LCP ConfAck id=1 <auth MSCHAP-v1> <mru 1400> <magic 4f5ea0a0>]
ppp539: 0040de0f53557093: send [MSCHAP-v1 Challenge id=1 <5e57e2634e4fc42>]
ppp539: 0040de0f53557093: recv [MSCHAP-v1 Response id=1 <000000000000000000000000>, <1d976f33aca5d9deff9108a935c3111dd15c6b5043d0>, F=1, name="andrei"]
ppp539: 0040de0f53557093: send [RADIUS Access-Request id=1 <User-Name "****"> <NAS-Identifier "****"> <NAS-IP-Address ****> <NAS-Port 539> 
<NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:a0:c9:af:4e:84"> <Called-Station-Id "00:1b:21:2b:6b:e9">
<Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP-Response >]
ppp539: 0040de0f53557093: recv [RADIUS Access-Accept id=1 <Service-Type Framed-User> <Framed-Protocol PPP> <Framed-IP-Address ********> 
<Framed-IP-Netmask 255.255.255.255> <Session-Timeout 86400> <Acct-Interim-Interval 120> <PPPD-Upstream-Speed-Limit "50000"> <PPPD-Downstream-Speed-Limit "50000">]
ppp539: 0040de0f53557093: send [MSCHAP-v1 Success id=1 "Authentication successed"]
ppp539: 0040de0f53557093: send [iPCP ConfReq id=1 <addr 78.109.240.5>]
ppp539: 0040de0f53557093: *******: authentication successed
ppp539: 0040de0f53557093: recv [iPCP ConfReq id=1 <addr 0.0.0.0>]
ppp539: 0040de0f53557093: send [iPCP ConfNak id=1 <addr **************>]
ppp539: 0040de0f53557093: recv [iPCP ConfAck id=1 <addr **************>]
ppp539: 0040de0f53557093: recv [iPCP ConfReq id=2 <addr **************>]
ppp539: 0040de0f53557093: send [iPCP ConfAck id=2]
ppp539: 0040de0f53557093: send [RADIUS Accounting-Request id=1 <User-Name "******"> <NAS-Identifier "******"> <NAS-IP-Address ************> <NAS-Port 539> 
<NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:a0:c9:af:4e:84"> <Called-Station-Id "00:1b:21:2b:6b:e9"> 
<Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "0040de0f53557093"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> 
<Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address ***************>]
ppp539: 0040de0f53557093: recv [RADIUS Accounting-Response id=1]
ppp539: 0040de0f53557093: pppd_compat: ip-up started (pid 4543)
ppp539: 0040de0f53557093: pppd_compat: ip-up finished (0)

Подскажите пожалуйста, как можно заставить accel-ppp изменять ограничения шейпера на определенном интерфейсе при получении такого пакета, или как минимум обновления файла radattr.ppp*?

Изменено 24 августа, 2011 пользователем andretty

[xeb]

Подскажите пожалуйста, как можно заставить accel-ppp изменять ограничения шейпера на определенном интерфейсе при получении такого пакета, или как минимум обновления файла radattr.ppp*?

можно конечно, но пакет от биллинга явно не приходит, проверь совпадают ли порты и секрет, посмотри снифером куда уходит реально пакет и доходит ли он до наса

 

да и какая версия accel-ppp ?

присутсвует ли dae-server в конфиге ?

вообще конфиг в части [radius] не помешал бы

[andretty]

Подскажите пожалуйста, как можно заставить accel-ppp изменять ограничения шейпера на определенном интерфейсе при получении такого пакета, или как минимум обновления файла radattr.ppp*?

можно конечно, но пакет от биллинга явно не приходит, проверь совпадают ли порты и секрет, посмотри снифером куда уходит реально пакет и доходит ли он до наса

Порты и секрет совпадают, авторизация то идет нормально, машина рабочая. Радиус сервер и nas стоят на соседних полках, включены в один свитч, в котором одна сеть, сложно представить, что пакет не дойдет физически... я тогда пожалуй поймаю пакет и выложу внутряшку сюда, мож чего интересного найдется, да и подтвердится точно, отправляется он или нет.

 

UPD:

accel-ppp 9999 последний из гита

dae-server не указан

секция radius: (чуть подправил приватные строки, не обессудьте плиз :) )

[radius]
dictionary=/usr/share/accel-ppp/radius/dictionary
nas-identifier=*****
nas-ip-address=x.x.x.x
gw-ip-address=x.x.x.x
auth-server=y.y.y.y:1812,*секрет*
acct-server=y.y.y.y:1813,*секрет*
acct-interim-interval=120
verbose=1
timeout=300
max-try=10
acct-timeout=300
#dae-server=127.0.0.1:3799,testing123
#dm_coa_secret=testing123 (deprecated)

Изменено 24 августа, 2011 пользователем andretty

[andretty]

Простите за тупость =) до этого момента не знал, что такое dae server, он не был нужен, поэтому в настройках не указывал. Может, если укажу это решит мою проблему?

[xeb]

dae-server не указан

я так понимаю скорость нужно менять через CoA ? тогда нужно сконфигурировать dae-server и биллингу сказать чтобы слал запросы на заданный ип:порт,секрет

[cpulink]

На версии из гит 9d4a4daad3221efefbdb2a6b98c301d75d9b23bc поймал сегфолт такого вида (за ~1час работы):

[ 4984.076240] accel-pppd[10460]: segfault at 7f4e6fcfeff8 ip 000000000041bd16 sp 00007f4e6fcfeff0 error 6 in accel-pppd[400000+26000]

конфиг такой:

[modules]
#path=/usr/local/lib/accel-ppp
log_file
#log_tcp
#log_pgsql
pptp
#pppoe
l2tp
auth_mschap_v2
#auth_mschap_v1
#auth_chap_md5
#auth_pap
radius
#ippool
sigchld
pppd_compat
#shaper_tbf
#chap-secrets

[core]
log-error=/var/log/accel-ppp/core.log
thread-count=4

[ppp]
verbose=1
min-mtu=1280
mtu=1460
mru=1460
#ccp=0
#sid-case=upper
#check-ip=0
single-session=replace
#mppe=require
ipv4=require
#ipv6=allow
#ipv6-intf-id=0:0:0:1
#ipv6-peer-intf-id=0:0:0:2
#ipv6-accept-peer-intf-id=1

[lcp]
echo-interval=30
echo-failure=10

[pptp]
#echo-interval=30
verbose=1

[l2tp]
#dictionary=/usr/local/share/accel-ppp/l2tp/dictionary
#hello-interval=60
#timeout=60
#rtimeout=5
#retransmit=5
#host-name=accel-ppp
verbose=1

[dns]
dns1=10.0.0.2
dns2=10.0.0.3

[radius]
#dictionary=/usr/local/share/accel-ppp/radius/dictionary
nas-identifier=nas3
nas-ip-address=172.1.1.1
gw-ip-address=10.128.0.128
server=172.6.10.1,xxxxx
#dae-server=127.0.0.1:3799,testing123
verbose=1
#timeout=3
max-try=4
acct-timeout=0
#acct-delay-time=0

[client-ip-range]
10.0.0.0/16

[log]
log-file=/var/log/accel-ppp/accel-ppp.log
log-emerg=/var/log/accel-ppp/emerg.log
log-fail-file=/var/log/accel-ppp/auth-fail.log
#log-debug=/dev/stdout
#log-tcp=127.0.0.1:3000
copy=1
#color=1
#per-user-dir=per_user
#per-session-dir=per_session
#per-session=1
level=3
#log-tcp=127.0.0.1:3000

[pppd-compat]
ip-pre-up=/etc/ppp/ip-pre-up
ip-up=/etc/ppp/ip-up
ip-down=/etc/ppp/ip-down
ip-change=/etc/ppp/ip-change.sh
radattr-prefix=/var/run/radattr
verbose=1

[cli]
telnet=127.0.0.1:2000
tcp=127.0.0.1:2001
#password=123

#[snmp]
#master=0
#agent-name=accel-ppp

В логе - подключение-отключение, вроде ниче критичного....

[xeb]

на данный момент в ветке master находится нестабильная версия, т.к. идёт внедрение нового функционала (ipv6, multi-radius и пр.), который еще нужно тестировать, это будущая версия 1.4, 1.3.х вынесена в отдельную ветку 1.3, туда будут вноситься только исправления ошибок, нового ничего добавляться не будет

[andretty]

dae-server не указан

я так понимаю скорость нужно менять через CoA ? тогда нужно сконфигурировать dae-server и биллингу сказать чтобы слал запросы на заданный ип:порт,секрет

Увы, действительно RADIUS никакого пакета не отправляет, только пишет, что отправляет... Буду мастерить отправлялку

[cpulink]

на данный момент в ветке master находится нестабильная версия, т.к. идёт внедрение нового функционала (ipv6, multi-radius и пр.), который еще нужно тестировать, это будущая версия 1.4, 1.3.х вынесена в отдельную ветку 1.3, туда будут вноситься только исправления ошибок, нового ничего добавляться не будет

Я не прочь потестировать, функционал интересный. Что включить в настройках-системе чтобы инфа была полезнее?

Брать последнее из гит? Как-либо специально компилить?

[xeb]

Что включить в настройках-системе чтобы инфа была полезнее?

[log]

level=5

при этом быть готовым, что логов будет много, хранить желательно хотя-бы за последние 2-3 дня

 

Как-либо специально компилить?

cmake -DCMAKE_BUILD_TYPE=Debug -DMEMDEBUG=TRUE

и собирать coredump'ы

Изменено 26 августа, 2011 пользователем xeb

[Victor Safronov]

Что может означать для pptp-сессии частый разрыв с причиной Acct-Terminate-Cause NAS-Request? Кто инициировал разрыв в этом случае? Радиусом служит штатный утмовский.

[xeb]

Что может означать для pptp-сессии частый разрыв с причиной Acct-Terminate-Cause NAS-Request?

либо через cli, либо, если в конфиге стоит single-session=replace, то повторный коннект с тем-же именем, при этом предыдущая сессия разрывается с причиной NAS-Request

[Victor Safronov]

либо через cli, либо, если в конфиге стоит single-session=replace, то повторный коннект с тем-же именем, при этом предыдущая сессия разрывается с причиной NAS-Request

Забавно. Через cli точно не отрубали. В конфиге действительно стоит single-session=replace, но юзеры клянутся и божатся, что разрывается само. Есть ли вероятность того, что accel-ppp неправильно определяет что-нибудь и в итоге отрубает ни в чём неповинную сессию?

[xeb]

вероятность равна 0, если проанализировать логи, то можно посмотреть с одинаковых ли адресов происходит повторный вход, либо имеет место быть кража паролей, либо по дхцп меняется ип во время активности сессии, но это уже из логов понять будет сложней

[Victor Safronov]

Обнаружил ещё один неприятный момент от использования удобной штуки single-session=replace

Если туннель уже умер, но сервер через lcp echo-requests ещё не успел об этом узнать, то при переподключении он авторизует новую сессию и после этого автоматически убьёт старую.

У нас между NAS-ами и бордером настроен OSPF, поэтому в момент укладывания старого туннеля посылается сообщение о недоступности этого маршрута, хотя на самом деле он есть. В итоге в новой сессии интернет не работает, нужно отключить VPN и подключить его снова. Существует ли возможность при использовании этой опции отложить поднятие нового туннеля до укладывания старого или это вызовет другие проблемы?

[xeb]

Существует ли возможность при использовании этой опции отложить поднятие нового туннеля до укладывания старого

что-нибудь придумаю...

[Ivan Rostovikov]

Именно по этому я использую RIP.

[mcym]

Не подскажете как мне с git-a стащить последние обновления к линейке 1.3.x

Команда git clone git://accel-ppp.git.sourceforge.net/gitroot/accel-ppp/accel-ppp скачает все патчи .

[cpulink]

Обнаружил ещё один неприятный момент от использования удобной штуки single-session=replace

Если туннель уже умер, но сервер через lcp echo-requests ещё не успел об этом узнать, то при переподключении он авторизует новую сессию и после этого автоматически убьёт старую.

У нас между NAS-ами и бордером настроен OSPF, поэтому в момент укладывания старого туннеля посылается сообщение о недоступности этого маршрута, хотя на самом деле он есть. В итоге в новой сессии интернет не работает, нужно отключить VPN и подключить его снова. Существует ли возможность при использовании этой опции отложить поднятие нового туннеля до укладывания старого или это вызовет другие проблемы?

можно костылятором побороться и не давать заходить пока та не потухнет, смотря на маршруты:

/etc/ppp/pre-up

#!/bin/bash

IPREMOTE=$5
if /sbin/ip route ls ${IPREMOTE}|grep -q ${IPREMOTE}
then
exit 1
fi

[NiTr0]

Не подскажете как мне с git-a стащить последние обновления к линейке 1.3.x

man git покурите, много чего узнаете. Коротко - git pull.

[Victor Safronov]

можно костылятором побороться и не давать заходить пока та не потухнет, смотря на маршруты:

Да, этот костылятор даже писать не надо, он называется single-session=deny

[cpulink]

Да, этот костылятор даже писать не надо, он называется single-session=deny

В целом, для опции deny - да, не нужно. Но если клиент завис на одном НАСе, а конектится на другой тут мало чем поможешь replace.

[xeb]

В целом, для опции deny - да, не нужно. Но если клиент завис на одном НАСе, а конектится на другой тут мало чем поможешь replace.

в этом случае только радиус может всё разрулить, либо вторую сессию не авторизовывать, либо отправлять Disconnect-Message первой