Перейти к содержимому
Калькуляторы

Хотел бы уточнить, почему изредка при попытке перечитать конфиг акцеля (подавая команду reload в cli или через tcp) в ответ тут же отдается "failed". Но самое печальное при этом, что процесс вываливается из памяти вместе со всеми абонентами (сначала виден как <defunc>, и потом и следа его нет). После перезапуска - все ок.

 

[root@acc45 ~]# echo "reload"|nc 127.0.0.1 2001

failed

 

root@acc45 ~]# echo "pppoe interface show"|nc 127.0.0.1 2001|awk '{ SUM += $2} END { print SUM }'

0

 

[root@acc45 ~]# ps ax|grep acc

1832 ? Zsl 3050:51 [accel-pppd] <defunct>

Изменено пользователем Dmitry76

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну это он банально падает при попытке перечитать конфиг.

Какая версия стоит? Вроде как эти баги были пофикшены давным-давно, еще до 1.9.0, после ни разу не вываливался.

Но мы nc не пользуемся, только 'accel-cmd reload'. Может в сетевой консоли какая беда есть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну это он банально падает при попытке перечитать конфиг.

Какая версия стоит? Вроде как эти баги были пофикшены давным-давно, еще до 1.9.0, после ни разу не вываливался.

Но мы nc не пользуемся, только 'accel-cmd reload'. Может в сетевой консоли какая беда есть.

Версия стоит 1.10.0 последний релиз. Такой же баг получался и если непосредственно делать в телнете акцеля (2000 порт). Через accel-cmd попробую.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

сталкивался тоже с тем, что иногда по телнету на reload аксель тупо вис (уходил в себя, отказываясь отвечать на внешние раздражители).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я также, но не смог найти причину. Причем непонятно что помогло и в чем было дело (фиг отследишь), но стало виснуть намного реже (кажись отключил мультитридовость и еще что-то, но это все шаманство получается).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я также, но не смог найти причину. Причем непонятно что помогло и в чем было дело (фиг отследишь), но стало виснуть намного реже (кажись отключил мультитридовость и еще что-то, но это все шаманство получается).

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Беда в том, что хотелось бы автору помочь, но как это отладить?

Под valgrind все еле ползает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Собрать в дебаге, сделать краш путем многократного релоада, посмотреть в gdb что в корке получилось.

Для IPOE мы лечили именно так, вроде полностью вылечили 3-4 фиксами. Для PPPoE возможно древние баги все еще живут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если виснет, то надо подключиться к нему с помощью gdb и посмотреть что там:

gdb -p пид_процесса

info threads

thread apply all bt full

valgrind это таки оверкруто :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

если там например повреждение стека - имхо gdb не поможет - и не факт, что оно полностью висит, но вобщем попробую

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Подскажите, а можно ли сделать такую вещь, чтобы после освобождения порта (речь идет о ppp), он не сразу занимался следующим авторизовываемым абонентом, а по возможности держался свободным какой-то время? Биллинг жалуется, что иногда старт по новой сессии они видят раньше, что стоп по этому же порту от предыдущего юзера. В логах аццеля последовательность правильная: сначала юзер отвалился (например по lcp timeout), а потом на этот порт подключает следующего. И это в одну секунду. С учетом, что авторизация происходит примерно 100-120 мс, то теоретически может быть, что очередь на самом радиусе создается иногда не в том порядке.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не подскажете, если на один влан/интерфейс отдавать несколько подсетей

[ipoe]

...

interface=eth3,range=172.16.104.0/24

interface=eth3,range=172.16.105.0/24

interface=eth3,range=172.16.106.0/24

 

можно так сделать или нужно использовать секцию ip-pool?

 

Так не работает, через запятую тоже... если брать ip-pool, там тоже каждая подсеть под своим именем. Друзья есть ли вообще возможность привязать несколько /24 подсетей на определенный интерфейс?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А так interface=eth3,range=172.16.104.0/23 не работает?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

можно через запятую попробовать.

 

если глобально - то можно так:

interface=re:eth1.[1-9][0-9][0-9][0-9]
gw-ip-address=10.251.0.1/21
gw-ip-address=10.250.128.1/20

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

NiTr0

Это ж dhcp-пулы им не отдает, только шлюз меняет принудительно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Debian 7.8

Linux vesta 3.2.0-4-amd64 #1 SMP Debian 3.2.68-1+deb7u3 x86_64 GNU/Linux

accel-ppp-1.9.0_wheezy_amd65.deb

 

Столкнулся с проблемой подвисания. В определенный момент перестает принимать новые подключения (PPTP/L2TP) и передавать accounting по существующим подключениям. Причем через ранее поднятые подключения трафик идет. В чем может быть проблема?

 

В логах из непонятного только такие сообщения:

[2016-03-18 19:03:10]: error: : failed to connect PPTP socket (Operation already in progress)

За сутки их бывает достаточно много.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Mar 19 04:49:47 svn kernel: PPP generic driver version 2.4.2
Mar 19 04:49:47 svn kernel: NET: Registered protocol family 24
Mar 19 04:49:47 svn kernel: PPTP driver version 0.8.5
Mar 19 04:49:47 svn kernel: PPTP: can't add protocol
Mar 19 04:49:47 svn kernel: PPPoL2TP kernel driver, V1.0
Mar 19 04:49:47 svn accel-pppd: accel-ppp version 95bef06065ba1a95c3334fcb22cf613776d1433b

смотрю, на centos 6 так до сих пор и не пофиксили багу. Или я что то делаю не так?

 

Mar 19 12:23:55 svn accel-pppd: ippool: open (null): Bad address

еще при старте стала появляться такая строка, раньше ее не было. Или это нормально?

 

А на ядрах 3.10.x. -DKDIR вообще не надо задавать?

# cmake -DKDIR=/usr/src/kernels/3.10.101-1.el6.elrepo.x86_64 -DCMAKE_INSTALL_PREFIX=/opt/accel-ppp-1.10.0-3.10.101 ../accel-ppp-src/
-- The C compiler identification is GNU 4.4.7
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- 'x86_64'
-- Looking for timerfd_create
-- Looking for timerfd_create - found
-- Looking for linux/netfilter/ipset/ip_set.h
-- Looking for linux/netfilter/ipset/ip_set.h - found
-- Configuring done
-- Generating done
CMake Warning:
 Manually-specified variables were not used by the project:

   KDIR


-- Build files have been written to: /root/vpn/build

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В логах из непонятного только такие сообщения:

[2016-03-18 19:03:10]: error: : failed to connect PPTP socket (Operation already in progress)

 

За сутки их бывает достаточно много.

Проблема есть где то с unit-cache, для теста можно попробовать выключить данный функционал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В логах из непонятного только такие сообщения:

[2016-03-18 19:03:10]: error: : failed to connect PPTP socket (Operation already in progress)

 

За сутки их бывает достаточно много.

Проблема есть где то с unit-cache, для теста можно попробовать выключить данный функционал.

Проблема, похоже, все таки не с этим. Пробовал ставить unit-cache=2000, пробовал совсем отключать unit-cache=0. Ситуация повторяется. Сервер в тесте и терминирует всего 300-400 пользователей. Причем самое печальное в этом, это то, что в момент подвисания интерфейсы не прибиваются и Quagga считает, что маршрут есть и даже если пользователя перебросит на другой сервер, то появится задвоенный маршрут, т.к. у нас несколько серверов с динамической маршрутизацией.

 

Еще один момент заметил в момент подвисания. Если останов делать с помощью /etc/init.d/accel-ppp stop (сигнал там судя по логу SIGTERM=15), то очень долго процедура выполняется. Если в нормальном режиме, то быстрее.

Есть еще варианты что покрутить?

 

UPDATE:

Удалось выяснить достоверно, что accel перестает принимать подключения после следующего сообщения в логе:

[2016-03-23 22:25:28]:  info: ppp180: 9352: second session denied 

При этом в конфиге стоит:

[common]
single-session=deny

 

Вроде как неправильное поведение. Была такая бага?

Изменено пользователем SokolovS

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

SokolovS, у вас есть возможность выбрать логи от начала сессии и до полного завершения.

cat /var/log/accel-ppp/accel-ppp.log | grep ppp180

Логи желательно уровня 5, при accel-cmd reload применяется без перезапуска демона.

 

И покажите секцию [ppp] в конфиге accel-ppp.conf

Изменено пользователем Dimka88

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

SokolovS, у вас есть возможность выбрать логи от начала сессии и до полного завершения.

cat /var/log/accel-ppp/accel-ppp.log | grep ppp180

Логи желательно уровня 5, при accel-cmd reload применяется без перезапуска демона.

 

И покажите секцию [ppp] в конфиге accel-ppp.conf

 

Судя по всему проблема происходит при отключении одного пользоватея и подключении другого, см. лог:

[2016-03-23 17:37:09]:  info: ppp180: connect: ppp180 <--> pptp(192.168.104.35)
[2016-03-23 17:37:12]:  info: ppp180: send [RADIUS(1) Access-Request id=1 <User-Name "10252"> <NAS-Identifier "VPN"> <NAS-IP-Address 192.168.50.8> <NAS-Port 180> <NAS-Port-Id "ppp180"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.104.35"> <Called-Station-Id "192.168.50.8"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2016-03-23 17:37:13]:  info: ppp180: recv [RADIUS(1) Access-Accept id=1 <Session-Timeout 86400> <Service-Type Framed-User> <Session-Octets-Limit 0> <Idle-Timeout 7200> <Framed-Protocol PPP> <Acct-Interim-Interval 180> <Octets-Direction Output> <Framed-IP-Address 91.203.125.195> <Framed-Compression None><Microsoft MS-CHAP2-Success >]
[2016-03-23 17:37:13]:  info: ppp180: 10252: authentication succeeded
[2016-03-23 17:37:16]:  info: ppp180: send [RADIUS(2) Accounting-Request id=1 <User-Name "10252"> <NAS-Identifier "VPN"> <NAS-IP-Address 192.168.50.8> <NAS-Port 180> <NAS-Port-Id "ppp180"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.104.35"> <Called-Station-Id "192.168.50.8"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "4f546a2a8c2480d2"> <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 91.203.125.195> <Framed-Interface-Id 91:203:125:195>]
[2016-03-23 17:37:16]:  info: ppp180: recv [RADIUS(2) Accounting-Response id=1]
[2016-03-23 22:17:06]:  info: ppp180: send [RADIUS(2) Accounting-Request id=5e <User-Name "10252"> <NAS-Identifier "VPN"> <NAS-IP-Address 192.168.50.8> <NAS-Port 180> <NAS-Port-Id "ppp180"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.104.35"> <Called-Station-Id "192.168.50.8"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "4f546a2a8c2480d2"> <Acct-Session-Time 16797> <Acct-Input-Octets 13483765> <Acct-Output-Octets 167112568> <Acct-Input-Packets 158756> <Acct-Output-Packets 146794> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address 91.203.125.195> <Framed-Interface-Id 91:203:125:195> <Acct-Terminate-Cause User-Request>]
[2016-03-23 22:17:07]:  info: ppp180: disconnected
[2016-03-23 22:25:25]:  info: ppp180: connect: ppp180 <--> pptp(192.168.98.9)
[2016-03-23 22:25:28]:  info: ppp180: send [RADIUS(1) Access-Request id=1 <User-Name "9352"> <NAS-Identifier "VPN"> <NAS-IP-Address 192.168.50.8> <NAS-Port 180> <NAS-Port-Id "ppp180"> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "192.168.98.9"> <Called-Station-Id "192.168.50.8"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2016-03-23 22:25:28]:  info: ppp180: recv [RADIUS(1) Access-Accept id=1 <Session-Timeout 86400> <Service-Type Framed-User> <Session-Octets-Limit 0> <Idle-Timeout 7200> <Framed-Protocol PPP> <Acct-Interim-Interval 180> <Octets-Direction Output> <Framed-IP-Address 46.16.25.32> <Framed-Compression None><Microsoft MS-CHAP2-Success >]
[2016-03-23 22:25:28]:  info: ppp180: 9352: second session denied

 

Секция [ppp]

[ppp]
mppe=deny
verbose=1
min-mtu=1280
mtu=1400
mru=1400
ipv4=require
ipv6=allow
ipv6-intf-id=0:0:0:1
ipv6-peer-intf-id=ipv4
ipv6-accept-peer-intf-id=0
lcp-echo-interval=20
lcp-echo-failure=2
lcp-echo-timeout=120
unit-cache=2000

 

Может стоит в этом случае поставить?:

[common]
single-session=replace

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

из man

lcp-echo-interval=n

If this option is given and greater then 0 then lcp module will send echo-request every n seconds.

 

lcp-echo-failure=n

Specifies maximum number of echo-requests may be sent without valid echo-reply, if exceeds connection will be terminated.

 

lcp-echo-timeout=sec

Specifies timeout in seconds to wait for any peer activity. If this option specified it turns on adaptive lcp echo functionality and "lcp-echo-failure" is not used.

 

Используйте или lcp-echo-failure или lcp-echo-timeout. Но по сути получается, что интерфейс уже как бы ушел в down а accel все еще думает что он поднят. Написал по этому поводу xebу, сказал посмотрит.

Изменено пользователем Dimka88

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

из man

lcp-echo-interval=n

If this option is given and greater then 0 then lcp module will send echo-request every n seconds.

 

lcp-echo-failure=n

Specifies maximum number of echo-requests may be sent without valid echo-reply, if exceeds connection will be terminated.

 

lcp-echo-timeout=sec

Specifies timeout in seconds to wait for any peer activity. If this option specified it turns on adaptive lcp echo functionality and "lcp-echo-failure" is not used.

 

Используйте или lcp-echo-failure или lcp-echo-timeout. Но по сути получается, что интерфейс уже как бы ушел в down а accel все еще думает что он поднят. Написал по этому поводу xebу, сказал посмотрит.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть необходимость в готовом решении авторизации Wi-Fi сети в гостинице

chillispot/nodogsplash. но это обсуждайте в новом топике, не в этом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.