[sirmax]

Столкнулся с паникой, какие-то идеи?

Ядро обновлял, текущее 2.6.39.1

[NiTr0]

Поставьте 2.6.35.13, на нем проблем нет.

[mcym]

Поставьте 2.6.35.13, на нем проблем нет.

 

У меня тоже с 2.6.39 были трудности , падало когда например у активного клиента выдернут кабель, через минутку когда сервер будет отбивать пустующие соединение будет паника и падеж. Я откатился на 2.6.36.4. У всех ядрах выше pptp модуль уже на борту и поведение одинаковое.

Изменено 17 июня, 2011 пользователем mcym

[mcym]

Иногда на экране появляется сообщение вида: localhost kernel: unregister_netdevice: waiting for ppp161 to become free. Usage count = 12

Что бы этот значило и на сколько это критично ?

[nsa2006]

Вопрос не в тему accel-ppp, но в тему шейпера на базе tbf. Куда копать дальше не знаю.

Исходные данные:

1. Система Debian Squeeze 6.0.1.

2. Железо DELL R210

3. Сетевые интегрированные

02:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)

02:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)

4. Базовое ядро входящее в дистрибутив

 

Результат:

Работает нормально Upload/Download равен установленным, при повышенном pps отваливался интерфейс.

 

Меняю ядро на 2.6.35.9, сборка с исходников.

 

Используя tbf, upload в норме, download низкий.

 

С стороны сервера:

 

tc qdisc show dev ppp1

qdisc tbf 1: root refcnt 2 rate 30000Kbit burst 375000b lat 50.0ms

qdisc ingress ffff: parent ffff:fff1 ----------------

 

C стороны клиента:

 

iperf -c XXX.XXX.XXX.4 --format k -m -t 180 -d

 

------------------------------------------------------------

Server listening on TCP port 5001

TCP window size: 85.3 KByte (default)

------------------------------------------------------------

------------------------------------------------------------

Client connecting to XXX.XXX.XXX.4, TCP port 5001

TCP window size: 42.1 KByte (default)

------------------------------------------------------------

[ 5] local XXX.XXX.XXX.1 port 42242 connected with XXX.XXX.XXX.4 port 5001

[ 4] local XXX.XXX.XXX.1 port 5001 connected with XXX.XXX.XXX.4 port 58607

[ ID] Interval Transfer Bandwidth

[ 5] 0.0-180.1 sec 639840 KBytes 29097 Kbits/sec

[ 4] 0.0-186.6 sec 1256 KBytes 55.1 Kbits/sec !!!

 

 

Перепробовал ядра 2.6.35, 2.6.35.9, 2.6.39.1 результат тот же.

Тем не менее на сетевых от intel таких боков не было.

 

Что могло поломаться?

 

 

Вылечилось:

 

ethtool -K eth0 tso off rx off tx off sg off

Изменено 23 июня, 2011 пользователем nsa2006

[lan-viper]

kern.log

Jun 22 00:00:34 nas kernel: [2588305.151524] accel-pppd[1571]: segfault at 7265735d ip b7801b05 sp b5b831f0 error 4 in libtriton.so[b77fc000+7000]

debug.log accel-я

ppp23: 1d2f01c080ef54e1: tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)connect: ppp23 <--> pppoe(vlan40:00:25:22:67:d9:ec)
ppp90: 1d2f01c080ef55d1: tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)disconnected
ppp88: 1d2f01c080ef4e9b: tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: ioctl(SIOCGIFINDEX)tbf: failed to remove shaper
...
tbf: nl_connect: Address already in usetbf: nl_connect: Address already in usetbf ... 

...и дальше в том же духе с разным количеством вхождений tbf: ioctl(SIOCGIFINDEX) и nl_connect: Address already in usetbf в строке

 

PS

Это моё второе или третье сообщение по данной проблеме. Ответа нет... Абоненты так и светятся лучами поноса в 00:00 или 08:00 через каждый день-два.

[xeb]

ppp5: 1d2f01c080ef48bf: tbf: nl_connect: Address already in usetbf: nl_connect: Address already in usetbf: ...... nl_connect: Address already in usetbf: failed to remove shaper

пробуй последний комит

[ogirya]

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

Лог сервера, последний коммит на сегодняшнее время:

[2011-06-22 22:00:16]: debug: ppp13: fsm timeout

[2011-06-22 22:00:16]: info: ppp13: send [LCP ConfReq id=1 <auth PAP> <magic 435d994a> <mru 1490>]

[2011-06-22 22:00:16]: info: ppp13: recv [LCP ConfAck id=1 <auth PAP> <magic 435d994a> <mru 1490>]

[2011-06-22 22:00:16]: debug: ppp13: lcp_layer_started

[2011-06-22 22:00:16]: debug: ppp13: auth_layer_start

[2011-06-22 22:00:16]: debug: ppp13: recv [LCP EchoReq id=0 <magic ea9ccf89>]

[2011-06-22 22:00:16]: debug: ppp13: send [LCP EchoRep id=0 <magic ea9ccf89>]

[2011-06-22 22:00:16]: info: ppp13: recv [PAP AuthReq id=49]

[2011-06-22 22:00:16]: warn: ppp13: pppoe:tr101: invalid tag received

[2011-06-22 22:00:16]: warn: ppp13: PAP: authentication error

[2011-06-22 22:00:16]: info: ppp13: send [PAP AuthNak id=49 "Authentication failed"]

[2011-06-22 22:00:16]: info: ppp13: d2558561: authentication failed

[2011-06-22 22:00:16]: debug: ppp13: ppp_terminate

[2011-06-22 22:00:16]: debug: ppp13: lcp_layer_finish

[2011-06-22 22:00:16]: info: ppp13: send [LCP TermReq id=2]

[2011-06-22 22:00:16]: debug: ppp13: auth_layer_finish

[2011-06-22 22:00:16]: debug: ppp13: auth_layer_finished

До радиуса дело не доходит.

[2c2i]

[2011-06-22 22:00:16]: warn: ppp13: pppoe:tr101: invalid tag received

 

это pppoe circuit id insertion, его могут делать свитчи длинк(может еще какие то) и дсламы.

[ogirya]

[2011-06-22 22:00:16]: warn: ppp13: pppoe:tr101: invalid tag received

 

это pppoe circuit id insertion, его могут делать свитчи длинк(может еще какие то) и дсламы.

Что можно сделать, что бы accel-pptpd все же выполнил авторизацию? если не меняя настроек дслама? (нету доступа)

[xeb]

warn: ppp13: pppoe:tr101: invalid tag received

в последнем комите tr101 можно отключить:

[pppoe]

tr101=0

[marikoda]

Что обычно делают для MSS FIX с accel-ppp ?

А то стали внедрять и у некоторых юзеров (венда без роутера) перестали открываться некоторые "важные сайты" (odnoklassniki.ru).

За роутерами всё отлично (вероятно роутер делает mss fix ?).

[Ivan Rostovikov]

http://yandex.ru/yandsearch?text=iptables+clamp+mss&lr=3

[marikoda]

Естественно, делали. И даже set mss делали.

Но яндекс и одноклассники либо вообще не открываются, либо открываются, но не скоро.

tcpdump смотрели, видно, что исправление mss отрабатывает, но толку нет

[lan-viper]

marikoda, тут правда есть один маленький подводный камень

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Где-то слышал, что цель TCPMSS корректно работает только в таблице mangle, в filter, который по умолчанию, может не давать желаемого результата. Да и man iptables пример именно с -t mangle.

[Ivan Rostovikov]

Делаю так:

$IPTABLES -t filter -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Последний дебиан, ядро "стоковое".

[marikoda]

В общем, кому интересно, проблему удалось локализовать.

При отключении shaper сайты начинают открываться нормально (Gentoo 2.6.38 genkernel). Причем, достаточно просто удалить tbf с ppp интерфейса через tc.

 

Но, самое интересное, что на ubuntu 11.04 с такой же версией ядра проблема отсутствует.

Изменено 29 июня, 2011 пользователем marikoda

[xeb]

При отключении shaper сайты начинают открываться нормально

для корректной работы шейпера нужно на карте отключать gro/lro

[Ivan Rostovikov]

2.6.38 - то еще мутево...

У меня нормально так и не запустилось.

[marikoda]

При отключении shaper сайты начинают открываться нормально

для корректной работы шейпера нужно на карте отключать gro/lro

 

Спасибо. Может что-то еще отключить стоит (на eth0 подняты несколько сотен vlan) ?

 

Offload parameters for eth0:

rx-checksumming: on

tx-checksumming: off

scatter-gather: off

tcp-segmentation-offload: off

udp-fragmentation-offload: off

generic-segmentation-offload: off

generic-receive-offload: off

large-receive-offload: off

rx-vlan-offload: on

tx-vlan-offload: on

ntuple-filters: off

receive-hashing: off

[marikoda]

Вдогонку:

 

А как шейперы работают? От сервера к клиенту вроде бы понятно, видно их в tc qdisc show.

А где глянуть те, которые в обратную сторону?

[NiTr0]

tx-checksumming: off

scatter-gather: off

включить, если поддерживается.

[marikoda]

Упали одновременно на 3 серверах с разницей в несколько секунд

 

Jul  1 21:35:08 l01 kernel: [37827.834123] accel-pppd[14141]: segfault at 20 ip 0000000000403d74 sp 00007f7834f66d60 error 4 in accel-pppd[400000+19000]

Jul  1 21:36:09 l03 kernel: [ 6878.028593] accel-pppd[24979]: segfault at 20 ip 0000000000403d74 sp 00007f3412b43d60 error 4 in accel-pppd[400000+19000]

Jul  1 21:35:05 l04 kernel: [17696.410423] accel-pppd[1151]: segfault at 20 ip 0000000000403d74 sp 00007f0956fc1d60 error 4 in accel-pppd[400000+19000]

Куда смотреть?

[xeb]

обновиться до версии из git

[marikoda]

обновиться до версии из git

Ок, обновлю.. Посмотрел diff, отличия лишь в tr01, у меня оно стоит без DSLAM, как эти правки могут касаться?

 

UPD. Обманул, еще shaper_tbf.c в mutex разница..

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