it1804

У меня получилось, что max-try для interim-update не учитывается. Сессия рвется через acct-timeout + acct-interim-interval секунд, а timeout определяет время между повторными посылками. Это при fail-time=0, если это имеет значение.

Добрый день. Возникла парочка вопросов: 1.Прочитал, что иногда процесс работает, но начинает без причины отказывать l2tp/pptp в подключении. Это можно где-то увидеть/определить, чтобы сразу перезагрузить его? 2. В продакшн всё-таки stable ветку использовать, или git уже достаточно стабилен?

Мне кажется я нашел реальную причину такого поведения клиента в l2tp. Сервер закрывает туннельное соединение раньше, чем происходит окончательный обмен запрос-подтверджение по управляющему туннелю. И клиент не может узнать, отключать соединение, шлёт запросы на уже закрытое сервером соединение. Теперь сервер принимает ответный stopCCN от клиента, и отправляет финальный ZLB, на ожидании которого клиент и зависает. И порядок CDN, потом lcp term-request вроде как действительно не имеет значения. Отправил новый патч на проверку в список рассылки. P.S. После этого пропали сообщения про invalid tid при финализации туннеля. --- l2tp.c.orig 2014-01-15 00:57:50.000000000 +0600 +++ l2tp.c 2014-01-15 23:59:07.025954894 +0600 @@ -663,9 +663,12 @@ { struct l2tp_packet_t *pack; - if (conn->state != STATE_CLOSE) - conn->state = STATE_CLOSE; - + if (conn->state == STATE_ESTB) { + conn->state= STATE_CLOSE; + return; + } else + conn->state= STATE_CLOSE; + if (conn->sess_count != 0) { /* * There are still sessions in this tunnel: remove the ones

Явного указания тоже не нашел. Посмотрел сейчас в какой последовательности дисконнектит cisco. Первым также CDN, потом lcp term-request. Я перебирал разные варианты, получилось что отработал только этот. Клиент win7 тут же выдал окно о прерывании сессии. А до этого было видно в tcpdump что клиент явно не понимал что от него потребовали, продолжал слать ещё какое-то время запросы, сервер на которые уже не отвечал. И так до таймаута. diff отправил.

Мне кажется такой disconnect более корректен, т.к CDN пакет вроде должен отправляться раньше закрытия PPP туннеля. По крайней мере клиент теперь получает это уведомление при radius Session-Timeout (или terminate if ppp0 из telnet), и сразу разрывает соединение, а не ждет таймаута, чтобы отвалиться с ошибкой. --- l2tp.c.orig 2014-01-15 00:57:50.000000000 +0600 +++ l2tp.c 2014-01-15 01:40:41.879940918 +0600 @@ -763,6 +763,21 @@ return 0; } +static void l2tp_ppp_terminate(struct ap_session *ses, int hard) +{ + struct l2tp_sess_t *sess = l2tp_session_self(); + switch (sess->state1) { + case STATE_PPP: + if (l2tp_send_CDN(sess, 2, 0) < 0) + log_session(log_error, sess, + "impossible to notify peer of session" + " disconnection, disconnecting anyway\n"); + break; + } + ppp_terminate(ses,hard); +} + + static void l2tp_ppp_finished(struct ap_session *ses) { struct l2tp_sess_t *sess = l2tp_session_self(); @@ -774,10 +789,6 @@ " disconnecting session\n", ses->ifname, ses->username ? ses->username : ""); sess->state1 = STATE_CLOSE; - if (l2tp_send_CDN(sess, 2, 0) < 0) - log_session(log_error, sess, - "impossible to notify peer of session" - " disconnection, disconnecting anyway\n"); if (l2tp_session_free(sess) < 0) log_session(log_error, sess, "impossible to free session," @@ -890,7 +901,7 @@ sess->ctrl.name = "l2tp"; sess->ctrl.started = l2tp_ppp_started; sess->ctrl.finished = l2tp_ppp_finished; - sess->ctrl.terminate = ppp_terminate; + sess->ctrl.terminate = l2tp_ppp_terminate; sess->ctrl.max_mtu = conf_ppp_max_mtu; sess->ctrl.mppe = conf_mppe; sess->ctrl.calling_station_id = _malloc(17);

Поскажите пожалуйста, как сбросить соединение l2tp через radius Session-Timeout. Сервер гасит ppp соединение, закрывает сессию, но клиенту (win7) по всей видимости не приходит уведомление, и он только через пару минут сбрасывает по таймауту. pptp сбрасывается сразу, что в принципе логично (из-за tcp) accel-ppp версия из git-a (01fcf87fe35502f6745137d79f56e618368872eb) Хотя Call-Disconnect-Notify отправляется