BiTel

ID события: radius.dialup.error.session.drop
Время регистрации события: 16.06.2012 16:36:45

Не удалось разорвать сессию: NASID=4; LOGIN: login1032; START: 15.06.2012 16:15:04 после 10 попыток сброса. Количество попыток сброса настраивается переменной 'nas.inspector.kill.max_messages' конфигурации NASа, интервал между попытками в секундах - 'nas.inspector.sleep_time'.

в конфигурации прописаны
nas.inspector.kill.max_messages
nas.inspector.sleep_time
может их убрать? или почему это вообще

решение в том что запросы на отключение шли не туда (не на тот порт)

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

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

нормальная, не видел таких, можно взглянуть?

Посмотрите радиусный connection.log там ясно видно какие атрибуты уходят и что приходит в ответ при разрыве.
У нас такая вертушка часто бывает когда сессии не совпадают на радиусе и на брасе. Биллинг их хочет сбросить, а брас говорит что нечего сбрасывать. Так они и друг с другом общаются пока нам не надоест или в биллинге сессию не закроет кто-нибудь.

zavndw Конфиг наса, там где про сброс сказано

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

nas.port_time.default.*=14
nas.port_traffic.default.*=1:RADIN;13:RADOUT
netflow.receive.from=127.0.0.1
card.activate.service=0
callback.support=0
month.break=1
month.break.period=3600
nas.inspector.sleep_time=3600
nas.inspector.kill.max_messages=10
nas.inspector.class=bitel.billing.server.processor.PoDNASConnectionInspector
nas.inspector.pod.port=1700
nas.inspector.pod.attributes=User-Name;Acct-Interim-Interval;Acct-Input-Gigawords;Acct-Input-Gigawords;Acct-Input-Octets;Acct-Output-Octets

nas.inspector.radius.attributes=Acct-Session-Id
а такой строчки нет?

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

нет, вставил щас посмотрю как будет себя вести.
но все ровно переваливает за лимит думаю менять режим
режим работы радиуса
#1 - режим UPDATE - пересчёт во время прохождения UPDATE пакетов
#2 - режим CHECKER - пересчёт по таймеру, UPDATE пакеты используются для получения информации о трафике
dialup.workmode=1
может надо в CHECKER

пипец довел до порога и уже в 2 раза больше упал и не вылетел

Это вам решать, это на сброс не влияет

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

вот этого вообще не понял

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

поставил порог -100 дошел до этого порога и сидел в инете пока сам не отключился и проверил закрытие сессии и сброс ни чего не работает

руками сессию скидывать что в логах?

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

radius 06-19/17:05:42 ERROR [radiusListener-p-4-t-6] DialUpNasConnection - Stop without start!
radius 06-19/18:03:34 ERROR [radiusListener-p-4-t-13] DialUpNasConnection - Stop without start!

эт кажись нето

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Покажет контекст сброса сесси руками через кнопку сброс.

Говорили же:

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

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

разобрались с тех поддержкой что не на тот порт запросы отправлялись для разрыва

У меня все отправляется на тот порт, но ошибка, порой, присутствует.

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

баланс у абонента скажем -190, лимит -200 и в 00:00 часов следующего дня - Восстановление лимитов, после чего договор переходит в статус приостановлен.

радиус отсылает Disconnect-Request на nas (mikrotik):



Не удалось разорвать сессию: NASID=1; LOGIN: login1480; START: 14.07.2012 00:05:21 после 3 попыток сброса. Количество попыток сброса настраивается переменной 'nas.inspector.kill.max_messages' конфигурации NASа, интервал между попытками в секундах - 'nas.inspector.sleep_time'.

вручную сбрасывать - тоже самое.

И такое, пока, только с одним абонентом!
Да, и еще в модуле dialup, в монитор соединений, у этого абонента время выхода 13.07.2012 23:59:55, даже если я посмотрел 14.07.2012 00:30:23 - галочка висит.
А абонент в это время сидит в интернете - на NAS-е сессия не разорвана.

И еще, в конфигурации NAS-а стоит параметр month.break=1 и все договора сбрасываются кроме этого и еще нескольких.

В конце-концов приходится сбрасывать прямо на NAS-е.

Что такое?

Конфиг НАСа:
nas.inspector.class=bitel.billing.server.processor.PoDNASConnectionInspector
nas.inspector.pod.port=1700
nas.inspector.pod.attributes=User-Name;Framed-IP-Address;Acct-Session-Id
nas.port_traffic.default.*=1:COLLECTOR;2:COLLECTOR;3:COLLECTOR;4:COLLECTOR
nas.port_time.default.*=5
netflow.receive.from=192.168.100.100
drop.sleep.timeout=3600
dialup.workmode=1
month.break=1

_________________
Версия 6.2

а какой нас сервер?, скорее всего порт не тот указан.

NAS - микротик
настройки NAS я выложил выше
порт в микротике такой же как и в настройках dialup NAS - 1700
Потом, практически все договора сбрасываются без проблем с первого запроса.
Только этот и еще несколько ни в какую не хотят сбрасываться.

_________________
Версия 6.2

nas.inspector.pod.attributes=User-Name;Framed-IP-Address;Acct-Session-Id
оставьте тока nas.inspector.pod.attributes=Acct-Session-Id
возможно остальнео не верно передается

_________________

Код:

  Клиент: вер. 6.2.714 / 25.05.2015 17:27:15
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45
  Сервер: вер. 6.2.881 / 22.05.2015 17:56:55
    os: Linux; java: Java HotSpot(TM) 64-Bit Server VM, v.1.8.0_45

Помощь по администрированию bgbilling в jabber конференции или Группа в telegram
Стиль программирования - пьяный мастерстер
Разработка мобильных приложений

Вот именно из за таких, совершенно непонятных "не сбрасываний" в ночь на первое число месяца я сбрасываю юзеров простым, как мычание, но рабочим способом - отключаю РРРоЕ как сервис.

• в случае с MPD - каждый день, в нужное время (например в 23:55), запускаем вот такой скрипт:
  
  Код:
  #!/bin/sh
  if [ `date -v +1d +%d` = "01" ]; then
      /usr/local/etc/rc.d/mpd5 stop
  fi
  
  
  1-го числа, опять же в нужное время (например в 00:05), запускаем вот такой скрипт:
  
  Код:
  /usr/local/etc/rc.d/mpd5 start
  
  
• в случае с MT:
  
  Код:
  interface pppoe-server set <список> disabled=yes
  
  
  Код:
  interface pppoe-server set <список> disabled=no
  
  
• в случае с циской:
  
  • так:
    
    Код:
    interface <имя> <слот>/<номер>.<vlan>
     no pppoe enable
    
    
    
    Код:
    interface <имя> <слот>/<номер>.<vlan>
     pppoe enable
    
  • или так:
    
    Код:
    interface <имя> <слот>/<номер>
     vlan-id dot1q <vlan id>
      no pppoe enable
     vlan-id dot1q <vlan id>
      no pppoe enable
     vlan-id dot1q <vlan id>
      no pppoe enable
    
    
    
    Код:
    interface <имя> <слот>/<номер>
     vlan-id dot1q <vlan id>
      pppoe enable
     vlan-id dot1q <vlan id>
      pppoe enable
     vlan-id dot1q <vlan id>
      pppoe enable
    
• в случае с ...:
  
  Код:
  put your code here

Как один из самых простых вариантов - тупо ребутить РРРоЕ сервер в нужное время, только перед этим не забудьте засечь время загрузки, чтобы он у Вас не загрузился раньше, чем наступит 1-е число месяца

nas.inspector.pod.port=1700 неправильный http://bgbilling.ru/v5.1/doc/ch16s12s13.html
скорее всего не 1700 а 22

1700 - стандартный цисковский порт для CoA/PoD - туда биллинг шлет RADIUS пакеты.
22 - стандартный порт ssh - через этот порт биллинг управляет "шлюзом", посылая целые портянки комманд, в то время как в случа с CoA/PoD отправляется один маленький пакет

Когда я принудительно сбрасываю в логах радиуса:

и в логах микротика:
Jul/22/2012 10:48:07 radius,debug,packet received Disconnect-Request with id 107 from 192.168.100.101:47866

вручную пока, только этот договор не сбрасывается

_________________
Версия 6.2

dilaup не любит числовых алиасов, вроде как.

Ловлю аналогичные грабли. из настроек есть


В итоге как наступает 1е число (уже который раз) получаю на почту тысячи писем из первого поста. НАС-ы микротики, как выяснилось они недоступны в этот момент, вот биллинг и фигачит всю ночь PODы, но активных сессий, которые радиус потыется оборвать - нету. После ребута радиуса всё успокаивается ровно на месяц. Это так и должно быть ? Как-то напрягает получать каждый месяц по 3000 писем. и их всё больше и больше каждый раз.

Кстати, когда отваливается НАС среди месяца, то радиус пытается несколько раз скинуть юзера ( больше чем в конфиге nas.inspector.kill.max_messages=3 ) пока сессия не отваливается по таймауту, потом сообщения перестают идти. А на границе месяца они идут до тех пор, пока не перезапустишь радиус. Может тут все таки есть баги, которые можно исправить ?