BiTel

Обновились с 5.0 до 5.1 - пропала авторизация клиентов по альясам(в нашем случае ип адрес либо номер телефона).
На все попытки авторизоваться выдается ошибка 02 - неверный пароль логина, хотя в типах логина галочки напротив проверять пароль не стоит.
Если авторизоваться по логину\паролю - все норм.
При этом странно ведет себя радиус, реагирует на все ВОИП запросы ошибкой диалап модуля

ERROR [radiusListener-p-3-t-1] RadiusListenerWorker - ru/bitel/bgbilling/modules/dialup/radius/DialUpRadiusSessionParams
java.lang.NoClassDefFoundError: ru/bitel/bgbilling/modules/dialup/radius/DialUpRadiusSessionParams


т.е подробней, на запрос типа(авторизовался в 5.0 по ип адресу)



INFO [radiusListener-p-3-t-2] RadiusListenerWorker - REQUEST:
Packet type: Access-Request
Identifier: 1
Authenticator: {13 26 9B B3 09 BB E5 A8 9A A8 C0 36 C8 52 F1 D8}
Attributes:
User-Name=х.х.39.11
User-Password=pss
NAS-IP-Address=х.х.91.6
Calling-Station-Id=3ххххххххх1
NAS-Port-Type=0
Called-Station-Id=111ххххххх976
cisco-NAS-Port=PSS
h323-conf-id=BE875000 19317BDB E002C10 7DDBF60C
h323-call-type=Telephony
h323-call-origin=answer

ответ вида

ERROR [radiusListener-p-3-t-2] RadiusListenerWorker - ru/bitel/bgbilling/modules/dialup/radius/DialUpRadiusSessionParams
java.lang.NoClassDefFoundError: ru/bitel/bgbilling/modules/dialup/radius/DialUpRadiusSessionParams
at bitel.billing.server.processor.event.RadiusAuthenticationEvent.<init>(RadiusAuthenticationEvent.java:40)
at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accessRequest(RadiusProcessor.java:327)
at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:167)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)
07-26/18:41:05 INFO [radiusListener-p-3-t-2] RadiusListenerWorker - RESPONSE:
Packet type: Access-Reject
Identifier: 1
Authenticator: {13 26 9B B3 09 BB E5 A8 9A A8 C0 36 C8 52 F1 D8}
Attributes:
Reply-Message=2
h323-return-code=2

в radius.properties стоит processor.class=ru.bitel.bgbilling.modules.voiceip.radius.VoiceIpRadiusProcessor

в чем может быть беда?

Выложили обновление радиуса voiceip, 139 билд. Должно помочь.

Ошибка с диалапом пропала, но на запросы так же приходит реджект.

Пример где пользователь в 5.0 авторизовался по АОНу в 5.1 - реджект:

27 18:57:15
Packet type: Access-Request
Identifier: 22
Authenticator: {72 C1 49 92 0D 78 AB 33 10 FB BA 3F DC 8E 10 32}
Attributes:
User-Name=7хххххххх1
NAS-IP-Address=217.23.91.6
Calling-Station-Id=7хххххххх1
NAS-Port-Type=0
Called-Station-Id=7ххххххххх7
cisco-NAS-Port=PSS
h323-conf-id=2A19422B 10CFC441 5695D23B A704B24E
h323-call-type=Telephony
h323-call-origin=answer

27 18:57:15
Packet type: Access-Reject
Identifier: 22
Authenticator: {72 C1 49 92 0D 78 AB 33 10 FB BA 3F DC 8E 10 32}
Attributes:
Reply-Message=2
h323-return-code=2
Process time auth: 89


Причем, если с авторизацией по ип это можно обойти, послав со шлюза вместе с ип еще и пароль, переделав, при этом, в биллинге тип логина это пользователя на с "проверять пароль", то вот авторизацию по АОНу уже никак.
Такое чувство что галочка в типах логина "проверять пароль" стала неотключаемой.

пс
139 не успели поставить для скачивания был доступен сразу 140

Еще раз выложили...

Авторизация заработала, спасибо.
Теперь осталось разобраться с аккаунтингом. Старые скрипты предобработки отказываются работать.
Часть возникающих ошибок удалось победить, остальные в процессе.. Надеюсь справимся сами.

Какие ошибки возникают?

Сделали. С 5.0 изменились синтаксис и апи, пришлось все переписывать.
Теперь пустим под нагрузкой тестировать заявленные обновления, надеюсь заработает. В пред версии под большой нагрузкой работать можно было только аккаунтингом, аус жестко тормозил процесс.

Помимо этой проблемы - viewtopic.php?f=5&t=4387, при работе периодически сыпятся ошибки:


radius 08-06/18:09:59 ERROR [radiusListener-p-4-t-65] RadiusListenerWorker -
java.lang.NullPointerException
at ru.bitel.bgbilling.modules.voiceip.radius.VoiceIpRadiusProcessor.accounting(VoiceIpRadiusProcessor.java:827)
at ru.bitel.bgbilling.modules.voiceip.radius.VoiceIpRadiusProcessor.accounting(VoiceIpRadiusProcessor.java:1)
at ru.bitel.bgbilling.kernel.network.radius.RadiusProcessor.accountingRequest(RadiusProcessor.java:399)
at ru.bitel.bgbilling.kernel.network.radius.RadiusListenerWorker.run(RadiusListenerWorker.java:218)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
at ru.bitel.common.worker.WorkerThread.run(WorkerThread.java:40)

Причем далеко не на все пакеты, на какие именно - отдебажить не получается. При малых объемах ошибок нет.

Со вчерашнего вечера вместо предыдущей на аккаунтинг появилось следующее на все.
Нагрузка увеличилась - авторизироваться стала только часть клиентов. Большая часть отбиваются как неавторизованные. Т.е. проблема такая-же как и в 5.0 - при большой нагрузке падает авторизация(нагрузка на сервере минимальна - проблема не в железе).

radius 08-09/13:54:59 ERROR [radiusListener-p-4-t-10] RadiusListenerWorker -
java.lang.NullPointerException
radius 08-09/13:55:00 ERROR [radiusListener-p-4-t-94] RadiusListenerWorker -
java.lang.NullPointerException
radius 08-09/13:55:01 ERROR [radiusListener-p-4-t-100] RadiusListenerWorker -
java.lang.NullPointerException
radius 08-09/13:55:03 ERROR [radiusListener-p-4-t-14] RadiusListenerWorker -
java.lang.NullPointerException
radius 08-09/13:55:05 ERROR [radiusListener-p-4-t-32] RadiusListenerWorker -
java.lang.NullPointerException
radius 08-09/13:55:05 ERROR [radiusListener-p-4-t-45] RadiusListenerWorker -
java.lang.NullPointerException
radius 08-09/13:55:06 ERROR [radiusListener-p-4-t-42] RadiusListenerWorker -
java.lang.NullPointerException
radius 08-09/13:55:07 ERROR [radiusListener-p-4-t-35] RadiusListenerWorker -
java.lang.NullPointerException

Покажите скрипт предобработки запросов. И параметры определения типа звонка.

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

Ошибка пропала. Но авторизация так и пропадает при более менее нагрузке.
Хотя странно что 40-60 линий вызывают проблемы.

По настройкам в радиусе вроде все норм.
db.maxIdle=60
db.maxActive=500

auth.thread.count=400
acct.thread.count=100
auth.thread.must.be.free.count=20
acct.thread.must.be.free.count=20

статус радиуса при очередном зависании авторизации, может увидите что чего мы не видим



[root@billing BGRadiusVoip]# ./radius_status.sh
version 5.1 build 143 from 11.08.2010 12:54:12
26.08.2010 14:22:38
Request accounts per minute: 124
Request auths per minute accept: 517; reject: 3
Ignore per minute auth: 0
Waiting connections: 615
Started: 23.08.2010 22:24:47 Uptime: 2 d 15:57:50
Memory total: 159 383 552; max: 954 466 304; free: 29 354 832
Memory pools:
Non-heap memory[Code Cache]: max: 50 331 648; used: 5 676 352; peek: 5 718 016
Heap memory[PS Eden Space]: max: 355 008 512; used: 12 054 672; peek: 113 180 672
Heap memory[PS Survivor Space]: max: 1 245 184; used: 1 228 968; peek: 21 188 680
Heap memory[PS Old Gen]: max: 715 849 728; used: 116 745 936; peek: 144 270 824
Non-heap memory[PS Perm Gen]: max: 88 080 384; used: 22 648 648; peek: 22 651 648
Thread count: 519
Trees in cache: 32
Connections pool to Master status Idle: 1; Active: 218; maxActive: 500; maxIdle: 60
Connections pool to Trash "<trash_id>" status Idle: 0; Active: 0; maxActive: 100; maxIdle: 1



сильно скачет значение актив в мастер, но более 350 ниразу не видел. как висяки пропадают, актив сразу стабильно 0.

А что при этом с базой данных? Радиус и БД на одной машине? Какая нагрузка в это время на БД? Какие скрипты предобработки запросов?

Да вот в том то и дело что нагрузки нет никакой ни там где радиус ни там где база ни там где биллинг(все на разных машинах, в одной сети, которая так же прошла проверку на работоскопосбность).
Машины меняли уже неск раз, эксперементировали с переносом базы на разные машины отдельно от биллинга, вместе с биллингом, переставляли системы и все нужные компоненты и тд и тп - не помогало. Сейчас сменили биллинговую машину - вроде получше стало, но по теории не совсем понято почему, база то осталась на старой.. Или просто трафика стало меньше. Мониторим. Но если проблема осталась - вариантов решения у нас больше нет. Все перебрали. Базу если только с нуля пересобрать.