[NiTr0]

Оффтоп: сегодня смотрел ради интереса ченжлог прошивки длинковского DIR-300... С ноября 2008 года на нем вместо поптопа - accel-pptp :)

Изменено 1 июля, 2009 пользователем NiTr0

[sfstudio]

Ага. Быстро они после нас с Андрюхой "осилили" accell =)))))))))

[nickD]

Помогите решить проблему.

 

Вываливается вот такое.

unregister_netdevice: waiting for ppp205 to become free. Usage count = 4150

Usage count постепенно уменьшается.

В этот период пользователи не могут поднять новую VPN сесию.

А те кто успел поднять до этого спокойно работают

Потом отвисает.

 

kernel 2.6.30

accel-pptp-0.8.3

pppd-2.4.4

 

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

Которые долбятся каждую минуту.

В логах это видно как:

r4 pptp[14378]: Peer login1 failed CHAP authentication

r4 pptpd[14377]: CTRL: EOF or bad error reading ctrl packet length.

r4 pptpd[14377]: CTRL: couldn't read packet header (exit)

r4 pptpd[14377]: CTRL: Fatal error reading control message in disconnect sequence

r4 pptpd[3007]: MGR: dropped small initial connection

 

Подвисает процес pppd и держит интерфейс например ppp205. Причем интерфейс командами ifconfig или ip link не виден.

На kill -s KILL или на kill -s TERM этот процес не реагирует.

 

Причем проблема не возникает при слабой загрузки сервера.

Например в выходные работает как часы. Т.к. к нему подключены только юрики которые в это время отдыхают.

 

[NiTr0]

У меня подобное было на обычном poptop - в сутки могло появиться 10-20 висячих сессий, которые хоть и не мешали коннекту, но ресурсы жрали дико. Причем - это создавали всего 2-3 долбящихся постоянно роутера.

Решил ограничением попыток коннекта в единицу времени (урезаю до 5 коннектов за 3 минуты):

iptables -A INPUT -p tcp -m tcp --dport 1723 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --rcheck --seconds 180 --hitcount 5 --name pptp --rsource -j DROP

iptables -A INPUT -p tcp -m tcp --dport 1723 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --set --name pptp --rsource

 

После данного нововведения волшебным образом повисшие сессии исчезли ;) После перехода на accel-pptp убирать его не стал - ибо нефиг долбиться при реджекте аутентификации.

[nickD]

Помог скрипт на перле который был размещен в этой теме.

Спасибо автору.

Запускаю раз в пять минут по крону. Он лог ведёт по логу видно что он вылавливает и грохает зависшие сессии.

Как показало расследование. Зависшие сессии возникают и без долбящихся роутеров. А долбящиеся роутеры всего лишь усугубляют ситуацию.

[kisa]

Помог скрипт на перле который был размещен в этой теме.

Спасибо автору.

Запускаю раз в пять минут по крону. Он лог ведёт по логу видно что он вылавливает и грохает зависшие сессии.

Как показало расследование. Зависшие сессии возникают и без долбящихся роутеров. А долбящиеся роутеры всего лишь усугубляют ситуацию.

А у меня после обновления glibc, ядра до 2.6.30 и пересборки pppd и accel этот глюк с зависшими сессиями ушел.

[nickD]

Помог скрипт на перле который был размещен в этой теме.

Спасибо автору.

Запускаю раз в пять минут по крону. Он лог ведёт по логу видно что он вылавливает и грохает зависшие сессии.

Как показало расследование. Зависшие сессии возникают и без долбящихся роутеров. А долбящиеся роутеры всего лишь усугубляют ситуацию.

А у меня после обновления glibc, ядра до 2.6.30 и пересборки pppd и accel этот глюк с зависшими сессиями ушел.

У меня

kernel 2.6.30

accel-pptp-0.8.3

pppd-2.4.4

Всё собраное из исходников

Сессии зависают.

 

До каккой версии glibc обновились у меня glibc-2.5

[NiTr0]

Вроде как последний (стабильный в Gentoo) - 2.9 :)

Изменено 13 июля, 2009 пользователем NiTr0

[kisa]

До каккой версии glibc обновились у меня glibc-2.5

sys-libs/glibc-2.8_p20080602-r1

gcc version 4.3.2 (Gentoo 4.3.2-r3 p1.6, pie-10.1.5)

 

[hiller]

Эх... Сервер 2.4.32 + accel 0.8.3, крашится через разные промежутки времени (на стандартном poptop работал годами), в логах ничего предвещающего падения или каких-то закономерностей нет. К сожалению, на сервере установлен WatchDog, который успевает дернуть его по reset'у, до того момента, пока я до него доберусь. Собственно это не тестовый сервер, там подругому нельзя.

 

Сталкивался ли кто-нибудь с этой проблемой на 0.8.3? Может посоветуете что сделать/посмотреть в моем случае?

[sfstudio]

Переехать на 2.6 ядро и не заморачиваться?

[hiller]

Есть специфичные потребности, которые пока не позволяют это сделать.

[sfstudio]

Ну тады апгрейдить сервак всмысле аппаратного обеспеченья и оставатьс жить с поптопом. Гадать почему сработала собака без каких-либо данных или гадать почему разваливается ядро не видя логов и дампов занятие для садомазахистов =))

 

А вообще забавно, ПОКА не позволяют =) С 2.4.32 ой как много воды утекло...

[hiller]

Ничего забавного, грустно все это. Есть некий софт, который привязан к 2.4.

 

Сейчас подумываю соединить этот сервер с соседним по RS-232, заставить ядро писать логи в COM-порт, а на втором сервере запущу minicom и буду ждать следующего краша...

[sfstudio]

Ничего забавного, грустно все это. Есть некий софт, который привязан к 2.4.

Софт или модули ядра? Если софт тады весьма сомнительно как минимум. А грустного тут ничего нет. ССЗБ если юзаете проприретарщину которая держит на древних ядрах.

 

Как вариант, можно и netlogger поднять. Или хотябы до 2.4.37 патчами догнать ядро. Всё посвежее будет.

[random2]

У меня подобное было на обычном poptop - в сутки могло появиться 10-20 висячих сессий, которые хоть и не мешали коннекту, но ресурсы жрали дико. Причем - это создавали всего 2-3 долбящихся постоянно роутера.

Решил ограничением попыток коннекта в единицу времени (урезаю до 5 коннектов за 3 минуты):

iptables -A INPUT -p tcp -m tcp --dport 1723 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --rcheck --seconds 180 --hitcount 5 --name pptp --rsource -j DROP

iptables -A INPUT -p tcp -m tcp --dport 1723 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --set --name pptp --rsource

 

После данного нововведения волшебным образом повисшие сессии исчезли ;) После перехода на accel-pptp убирать его не стал - ибо нефиг долбиться при реджекте аутентификации.

pptp:/var/log# iptables -A INPUT -p tcp -m tcp --dport 1723 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --rcheck --seconds 120 --hitcount 5 --name pptp --rsource -j DROP

iptables: No chain/target/match by that name

 

pptp:/var/log# lsmod | grep ip

iptable_nat 4252 0

nf_nat 16488 1 iptable_nat

iptable_mangle 2228 1

nf_conntrack_ipv4 11696 5 iptable_nat,nf_nat

nf_defrag_ipv4 1656 1 nf_conntrack_ipv4

nf_conntrack 58044 4 iptable_nat,nf_nat,nf_conntrack_ipv4,xt_state

ipt_ULOG 6584 8

iptable_filter 2228 1

ip_tables 10240 3 iptable_nat,iptable_mangle,iptable_filter

x_tables 14080 6 iptable_nat,xt_state,xt_limit,ipt_ULOG,xt_tcpudp,ip_tables

ipv6 235788 188

 

кто нибудь может понять чего ему не хватает?

[NiTr0]

Нет xt_recent.

[_ruslan_]

Обновил у себя ядро до 2.6.30, libc6 до 2.9

Поставил accel-pptpd 0.8.3 накатил пачт allow-mppe.

 

Полет нормальный :-), все пока стабильно. онлайн под 1000 на тестовом.

Поток чуть более 100 мегабит/c.

 

нагрузка

vmstat 1

procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----

r b swpd free buff cache si so bi bo in cs us sy id wa

0 0 0 3212628 1240 31068 0 0 0 1 98 32 1 11 88 0

0 0 0 3212744 1240 31068 0 0 0 0 21131 316 0 14 86 0

0 0 0 3212868 1240 31068 0 0 0 0 18653 1022 1 19 80 0

0 0 0 3212876 1240 31068 0 0 0 0 19811 264 0 15 85 0

0 0 0 3212876 1240 31068 0 0 0 12 21276 273 0 14 86 0

 

86% против 79-80% (pptpd).

 

Бонус с патчем конечно вышел для клиентов.

 

 

pstree

init---Xvnc

--cron

--fluxbox--aterm---sh----pstree

--3*[pppd]

--pptp---984*[pptpctrl---pppd]

--startx---xinit---X

x --fluxbox---aterm---sh

--syslog-ng

 

В принципе даже такой небольшой прирост вполне не плох :-).

 

Заметил что раньше у меня более 24Мбит/c сессия не выдавала, теперь вот тупо запустил speedtest скорость под 37Мбит/с, ровно столько сколько осталось от пропускной способности канала :-)

 

Вообщем рекомендую.

 

Добавлю:

xeb спасибо :-)

[_ruslan_]

Интересный момент, у меня раньше сетевые карты использовали прерывания конкретного CPU и потом через буквально сек. пеерключалась на след и т д по всем 8 ядрам.

Ядро таким образом по афинити маске переключало.

 

Теперь же у меня почему то одновлемено все 8 ядер накручивают счетчик прерываний...

 

Это новая фишка ядра или все же в accelе ? :-)

Изменено 27 июля, 2009 пользователем _ruslan_

[NiTr0]

Итак, аптайм 43 суток - полет нормальный.

[hiller]

Круто! Сделал новый сервер, поставил 2.6.30 и accel 0.8.3, нагрузка пока тестовая, uptime 17 days, все в порядке!

[xeb]

<br />Интересный момент, у меня раньше сетевые карты использовали прерывания конкретного CPU и потом через буквально сек. пеерключалась на след и т д по всем 8 ядрам.<br />Ядро таким образом по афинити маске переключало.<br /><br />Теперь же у меня почему то одновлемено все 8 ядер накручивают счетчик прерываний...<br /><br />Это новая фишка ядра или все же в accelе ? :-)<br />

accel тут не причём, какие ядра указал в affinity, такие ядра и будут грузиться под pptp, остальные хз чем занимаются ...

[_ruslan_]

в афините у меня стояло ff и щас стоит ff (на irq сетевых).

 

Просто мне показалось интересным изменение принципа работы.

Конечно изменение коснулось ядра ... не додумал и написал :-).

Изменено 30 июля, 2009 пользователем _ruslan_

[[anp/hsw]]

у меня есть небольшой вопрос.

в проекте у вас есть файл ppp-generic-smp.c

но он не работает под 2.4 (в частности просто нету файлов mutex.h, device.h итд)

возможно ли его переделать на 2.4? хотелось бы посмотреть разницу при его использовании и без.

 

[xeb]

у меня есть небольшой вопрос.

в проекте у вас есть файл ppp-generic-smp.c

но он не работает под 2.4 (в частности просто нету файлов mutex.h, device.h итд)

возможно ли его переделать на 2.4? хотелось бы посмотреть разницу при его использовании и без.

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

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