[xeb]

xeb, что там по поводу некорректного согласования MTU и сообщения dns серверов для стеснительных клиентов, которые их не запрашивают?

насчёт мту это не баг

если хочется фиксированный мту, то

[ppp]

max-mtu=1400

min-mtu=1400

 

насчёт днс, не знаю как форсировать, pppd умеет ?

 

И что с pppd_compat - таки поломан в 1.7.2 или у меня криво собралось?

видимо криво собралось

на что конкретно ругается ?

strace'ом можно глянуть ?

 

xeb а что можете сказать по моему вопросу? Ну хотя бы приблизительно, реализуемо это вообще или нет, ждать ли, надеяться, верить или менять условия своих тарифных планов? :)

находится в работе

сейчас, к сожалению, у меня времени мало ...

[komper]

Lanbilling

Атрибуты скорости есть в базе.

Хочу получить скорость 1500 Кбит/с

а получаю вот такие параметры

cat /var/run/radattr.ppp0 
Session-Timeout 172800
Service-Type Framed-User
Framed-Protocol PPP
Framed-IP-Address 172.16.4.194
Framed-IP-Netmask 255.255.255.255
Class 3030303031343135
MS-CHAP2-Success 01533D31344638354541343639383745394331444336383843354636453533333038353843303636314536
MS-MPPE-Encryption-Policy 1
MS-MPPE-Encryption-Type 6
MS-MPPE-Send-Key C60286CC638C1D0A9505903CE141AC9DE735E5FBDDD1A35D55171D1745A549CDA3DE
MS-MPPE-Recv-Key 8772BD41786FBD020FF80A6B3986CE44C6C5B8CBDD1662EEDCA6D9827CD25105E330
Acct-Interim-Interval 60
Vendor-Specific 00003A8C080D313530306B2F313530306B
Vendor-Specific 00003035072B696E23313D616C6C20726174652D6C696D697420313530303030302031383735303020333735303030
Vendor-Specific 00003035072C6F757423313D616C6C20726174652D6C696D697420313530303030302031383735303020333735303030
PPPD-Upstream-Speed-Limit 1347440708
PPPD-Downstream-Speed-Limit 134744070

[xeb]

PPPD-Upstream-Speed-Limit 1347440708

PPPD-Downstream-Speed-Limit 134744070

должно быть 1500 если нужно 1500

Изменено 28 сентября, 2012 пользователем xeb

[komper]

должно быть 1500 если нужно 1500

В том то и проблема что в билинге указано 1500

upd: Вопрос закрыт, радиус атрибут внесли как string вместо int...

Изменено 28 сентября, 2012 пользователем komper

[Cramac]

Всем привет. Подскажите, недавно обновил до последней версии, и возникли проблемы с некоторыми роутерами и еще чем то. Почему то они оооооочень много делают реконектов. Из последнего замеченного, ДИР-615 (прошивка последняя)

Статистика подключений у них выглядит примерное так:

 

1 29.09.2012 01:24:13 29.09.2012 01:24:15 закрыта serkova 10.10.8.148 0 0

1 29.09.2012 01:24:18 29.09.2012 01:24:20 закрыта serkova 10.10.8.148 0 0

...

1 29.09.2012 01:25:10 29.09.2012 01:25:12 закрыта serkova 10.10.8.148 0 0

1 29.09.2012 01:25:15 29.09.2012 01:25:17 закрыта serkova 10.10.8.148 0 0

1 29.09.2012 01:25:20 29.09.2012 01:25:22 закрыта serkova 10.10.8.148 0 0

2 29.09.2012 01:25:25 29.09.2012 13:58:16 обновлена serkova 10.10.8.148 197.9814 kb 21.3984 kb

по логам вот что видно http://cramac.ru/ppp52.log

[sprite]

Добрый день, всем.

Поставил последний accel-ppp 1.7.2 Раньше никогда им не пользовался. Все завелось, но при активном использование вылезла следующая проблема. Не на все соединения вешаются шейперы.

qdisc tbf 1: dev ppp41 root refcnt 2 rate 1536Kbit burst 96000b lat 50.0ms 
qdisc ingress ffff: dev ppp41 parent ffff:fff1 ---------------- 
qdisc pfifo_fast 0: dev ppp42 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc tbf 1: dev ppp43 root refcnt 2 rate 3072Kbit burst 192000b lat 50.0ms 
qdisc ingress ffff: dev ppp43 parent ffff:fff1 ---------------- 
qdisc pfifo_fast 0: dev ppp44 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ppp45 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc tbf 1: dev ppp48 root refcnt 2 rate 3072Kbit burst 192000b lat 50.0ms 
qdisc ingress ffff: dev ppp48 parent ffff:fff1 ---------------- 
qdisc pfifo_fast 0: dev ppp51 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ppp49 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc tbf 1: dev ppp52 root refcnt 2 rate 1536Kbit burst 96000b lat 50.0ms 
qdisc ingress ffff: dev ppp52 parent ffff:fff1 ---------------- 
qdisc pfifo_fast 0: dev ppp53 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ppp54 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ppp20 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ppp55 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ppp56 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
qdisc pfifo_fast 0: dev ppp58 root refcnt 2 bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

и в логах ошибки на эту тему

[2012-10-02 04:33:07]: error: ppp67: tbf: nl_connect: Address already in use
[2012-10-02 04:35:03]: error: ppp76: tbf: nl_connect: Address already in use
[2012-10-02 04:35:34]: error: ppp78: tbf: nl_connect: Address already in use
[2012-10-02 04:40:10]: error: ppp82: tbf: nl_connect: Address already in use
[2012-10-02 04:40:22]: error: ppp82: tbf: nl_connect: Address already in use
[2012-10-02 04:41:59]: error: ppp82: tbf: nl_connect: Address already in use
[2012-10-02 04:48:23]: error: ppp67: tbf: nl_connect: Address already in use
[2012-10-02 04:49:53]: error: ppp46: tbf: nl_connect: Address already in use

вроде бы в интернете поискал подробные проблемы, не нашел.

ядро 3.5.4-gentoo

accel-ppp собирал скак с -DSHAPER=FALSE так и с -DSHAPER=TRUE

конфиг дефолтный кроме как в секции tbf добавил vendor=Cisco attr=Cisco-AVPair, шейпер shaper_tbf, пробовал и shaper, результат одинаков.

Пробовал по советам в инете offload на карточках погасить

Features for eth1:
rx-checksumming: on
tx-checksumming: on
       tx-checksum-ipv4: on
       tx-checksum-ip-generic: off [fixed]
       tx-checksum-ipv6: on
       tx-checksum-fcoe-crc: off [fixed]
       tx-checksum-sctp: off [fixed]
scatter-gather: on
       tx-scatter-gather: on
       tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
       tx-tcp-segmentation: off
       tx-tcp-ecn-segmentation: off
       tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off [fixed]
rx-vlan-offload: on [requested off]
tx-vlan-offload: off
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]

результата нет.

 

Кто нибудь сталкивался с таким? Как организовать нарезку трафика пользователям?

[nsa2006]

2012-10-02 04:41:59]: error: ppp82: tbf: nl_connect: Address already in use

[2012-10-02 04:48:23]: error: ppp67: tbf: nl_connect: Address already in use

[2012-10-02 04:49:53]: error: ppp46: tbf: nl_connect: Address already in use

 

Аналогичная проблема откатился на 1.6.1

[taf_321]

Если принять во внимание, что в master-ветке шейпер tbf выпилен, может имеет смысл перейти на htb? С ним проблем как-то не замечено.

Изменено 3 октября, 2012 пользователем taf_321

[sprite]

попробовал версии ниже 1.7.2, такой проблемы не замечено.

 

Если принять во внимание, что в master-ветке шейпер tbf выпилен, может имеет смысл перейти на htb? С ним проблем как-то не замечено.

извиняюсь за вопрос, а поподробнее можно? или киньте ссылочки

[nsa2006]

htb более ресурсоемкий как мне показалось, ранее гонял через ip-up, были замечены перекосы по скорости для pptp тоннелей, с tbf таких проблем не было.

[xeb]

htb использовать не обязательно, можно и tbf

[shaper]
down-limitter=tbf

[Victor Safronov]

А где можно почитать инфу по настройкам/возможностям IPoE?

[taf_321]

попробовал версии ниже 1.7.2, такой проблемы не замечено.

 

Если принять во внимание, что в master-ветке шейпер tbf выпилен, может имеет смысл перейти на htb? С ним проблем как-то не замечено.

извиняюсь за вопрос, а поподробнее можно? или киньте ссылочки

 

http://accel-ppp.git.sourceforge.net/git/gitweb.cgi?p=accel-ppp/accel-ppp;a=commit;h=6fe9ea35fb1484c37aa5f7eb9b023780f986f1e8

 

настройки для htb

...

[shaper]

attr=Filter-Id

down-burst-factor=0.1

up-burst-factor=1.0

mpu=0

r2q=10

quantum=1500

ifb=ifb0

up-limiter=htb

down-limiter=htb

verbose=1

#leaf-qdisc=sfq perturb 10

...

[nsa2006]

А где можно почитать инфу по настройкам/возможностям IPoE?

https://sourceforge.net/apps/trac/accel-ppp/wiki/IPoE_ru

[Cramac]

И мне подскажите по:

]# snmpset -m +ACCEL-PPP-MIB -v 2c -c local 10.10.10.1 ACCEL-PPP-MIB::termByIfName.0 = ppp215

2012-10-03 14:11:04 Cannot find module (ACCEL-PPP-MIB): At line 0 in (none)

2012-10-03 14:11:04 ACCEL-PPP-MIB::termByIfName.0: Unknown Object Identifier

 

СНМП на другом сервере

Изменено 3 октября, 2012 пользователем Cramac

[s.lobanov]

по цифровому OID обратитесь и не парьтесь

[Cramac]

s.lobanov а не подскажите ОИД?

 

нашел .1.3.6.1.4.1.8072.100.3.1.2.0

 

только все равно с удаленного ПК не работает...по таймауту отваливается

Изменено 3 октября, 2012 пользователем Cramac

[nsa2006]

Установил accel-ppp 1.7.2

Шейпер работает!

 

поставил 10Mbps полосу, up-limiter=police, down-limiter=tbf, провел тест синхронной передачи в оба направления получил в сумме 20Mbps, при htb/tbf перекос, вход 10Mbps исход. 5~6Mbps. При htb/htb вообще мрак.

Изменено 3 октября, 2012 пользователем nsa2006

[Victor Safronov]

А где можно почитать инфу по настройкам/возможностям IPoE?

https://sourceforge.net/apps/trac/accel-ppp/wiki/IPoE_ru

Клёво, спасибо.

 

Осталось придумать как прикрутить к схеме VLAN per user штатный UTM5 Radius.

С другой стороны, если к акселу уже прикручен LUA и через него можно получать username, то может быть несложно будет добавить возможность получения IP/маски/шлюза/атрибутов и прочих необходимых параметров через тот же LUA или любой другой внешний скрипт, минуя радиус вообще?

Изменено 3 октября, 2012 пользователем Victor Safronov

[s.lobanov]

Осталось придумать как прикрутить к схеме VLAN per user штатный UTM5 Radius.

 

В чём конкретно проблема? логины переименовывать не хочется?

[Victor Safronov]

Осталось придумать как прикрутить к схеме VLAN per user штатный UTM5 Radius.

 

В чём конкретно проблема? логины переименовывать не хочется?

Сейчас у пользователей ШПД в сервисные связки логины вообще не забиты, там пустота. Забит только IP и номер влана в поле Allowed_CID. А уже самописный скрипт из мускула напрямую делает ацл для кошки и конфиг для dhcpd.

Получается, что нужно будет всем создать логины на каждый адрес. В таком случае как быть, если в сервисной связке два адреса, например? Ну и куча сопутствующих вопросов возникает.

[Cramac]

А есть ли у кого или кто то может заморачивался, перегоном ошибок из файла в базу?

В частности интересно только почему пользователь не подключается с 691 ошибкой

[taf_321]

Все-таки с удалением vlan-интерфейса, на котором посидел accel проблема есть.

 

итак, accel-ppp 1.7.2, ядро 3.0.38, пачка vlan'ов, н аних pppoe клиенты.

 

Подымаем тестовый влан-интерфейс, даем команду

 

pppoe interface add vlanTEST

 

начинаем на нем просто подключать-отключать pppoe, раз так 100-200 для имитации реального использования. После этого через консоль accel даем команду:

 

pppoe interface del vlanTEST

 

и пробуем удалить уже ненужный интерфейс и... опаньки, все клинит на команде

 

/usr/bin/vconfig rem vlanTEST

 

в логах постоянное:

 

[8169493.878155] unregister_netdevice: waiting for vlanTEST to become free. Usage count = 1733

 

на момент "pppoe interface del vlanTEST" на этом интерфейсе было живое подключение (имитировалось перекидывание клиентов с одного BRAS'а на другой).

 

Такое ощущение, что сервер, при удалении интерфейса из списка активных, не освобождает дескрипторы. Цифра count = примерно коррелирует с тем количеством подключений, что было произведено на этот интерфейс.

[vinnipux]

Доброго времени суток!

Долгое время боролся с проблемой внезапных падений accel-pppd на ровном месте в процессе эксплуатации, высылал сюда и на сайт проекта bug-report-ы с корками.

http://forum.nag.ru/forum/index.php?showtopic=45266&view=findpost&p=690580

http://forum.nag.ru/forum/index.php?showtopic=45266&view=findpost&p=737560

Автор несколько раз пытался помочь, в результате в конфиг попала такая опция в секции

[core]

stack-size=

для попытки отрегулировать объем стека рабочего процесса — было подозрение на утечку памяти.

 

Увеличив объем в 10 раз от стандартного 1 Мбайта и проведя наблюдение в течении двух недель я не добился серьезных изменений.

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

На мой взгляд, если бы дело было все-таки в утечке памяти, то эта проблема должна была бы проявляться гораздо реже, т.е. Должна была бы прослеживаться линейная зависимость между увеличением объема stack-size и временем работы без сбоев.

Этой зависимости не наблюдалось.

 

В общем решил я сам немного поковыряться во внутренностях coredump-ов. Делал в первый раз, прошу не судить строго ))

 

Дальнейшие изыскания я прикрепляю в файле к этому посту.

 

Версия accel-pppd: 1.7.2 скомпилено с Debug

OS: Fedora 17 32-bit PAE

Linux-ядро: 3.5.3-1.fc17.i686.PAE

 

на двух других серверах:

Версия accel-pppd: 1.7.2 скомпилено с Debug

OS: Fedora 16 32-bit

Linux-ядро: 3.2.7-1.fc16.i686

 

 

core.5805.gz - сбой при сбросе юзера через snmp

core.13212.gz - сбой при выполнении команды через телнет

 

Вывод: имеется серьезная ошибка в процедуре сброса пользователя по логину

terminate match username test1 hard

и ее аналоге в snmp-реализации, приводящая к аварийному завершению процесса accel-pppd.

После того, как я отказался от использования snmp и сбрасываю юзера по ip или по интерфейсу через telnet, я вот уже как за 10 дней наблюдения забыл про сбои процесса accel-pppd и теперь мои клиенты довольны. :)

 

Прошу уважаемого xeb-а обратить внимание на мои скромные изыскания ))

accel-отчет-об-ошибке.txt

accel-отчет-об-ошибке.pdf

core.5805.gz

core.13212.gz

Изменено 7 октября, 2012 пользователем vinnipux

[Abram]

Вот это я понимаю баг-репорт!