Перейти до

UBilling NAS Mikrotik по API проблема с стабильностью отработки OnConnect


Рекомендованные сообщения

Добрый день!

Давно используем на небольшой сети в пару тысяч человек Ubilling в связке с NAS Mikrotik по API. В какой момент появилась проблема что каждое первое число, после того как по отключает должников, не всех оплативших услугу (либо поставивших кредит) в течении дня подключает назад, точнее в самом биллинге все хорошо, не переключается в статус enabled правило адрес-листе на микротике. Таких невезучих +/- пару десятков на пару сотен должников, системности никакой нету, учетные записи разные. Происходит только первого числа и примерно где только в первой половине дня, потом все отрабатывает нормально до конца месяца. Ручной ресет такого "невезучего" исправляет ситуацию. После чего появилась проблема уже сказать невозможно, уже долгое время в ручном режиме исправляем проблему.
При анализе stargazer.log никаких аномалий, по таким абонентам нету, а от уже в allconnect.log у таких абонентов тишина, вызовов OnConnect после оплаты нету, как и каких либо ошибок.

Собственно вопрос куда можно копать дальше и сталкивался ли кто с такой проблемой? 

Ubilling стоит на FreBSD 13.1 (виртуалка) версии 1.3.7

 

Ссылка на сообщение
Поделиться на других сайтах
15 часов назад, raven405 сказал:

Добрый день!

Давно используем на небольшой сети в пару тысяч человек Ubilling в связке с NAS Mikrotik по API. В какой момент появилась проблема что каждое первое число, после того как по отключает должников, не всех оплативших услугу (либо поставивших кредит) в течении дня подключает назад, точнее в самом биллинге все хорошо, не переключается в статус enabled правило адрес-листе на микротике. Таких невезучих +/- пару десятков на пару сотен должников, системности никакой нету, учетные записи разные. Происходит только первого числа и примерно где только в первой половине дня, потом все отрабатывает нормально до конца месяца. Ручной ресет такого "невезучего" исправляет ситуацию. После чего появилась проблема уже сказать невозможно, уже долгое время в ручном режиме исправляем проблему.
При анализе stargazer.log никаких аномалий, по таким абонентам нету, а от уже в allconnect.log у таких абонентов тишина, вызовов OnConnect после оплаты нету, как и каких либо ошибок.

Собственно вопрос куда можно копать дальше и сталкивался ли кто с такой проблемой? 

Ubilling стоит на FreBSD 13.1 (виртуалка) версии 1.3.7

 

Копать в сторону multigen, переделать все по нормальному. 

Проблема API нерешаема, тыкать ресет будете и дальше. 

Ссылка на сообщение
Поделиться на других сайтах

Спасибо за ответы, в сторону радиуса с кучагеном и так смотрим, хотелось просто узнать это какой то конкретно наш косяк или кривость API метода.

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від GMelик
      Вітання! Наперед вибачаюсь з тупі питання! Але мені потрібна допомога з вирішенням проблеми роботи wifi. Загалом ситуація наступна: є офіс куди заведений інтернет, роль маршрутизатора виконує Mikrotik hap ac2 з вимкненими wifi інтерфейсами до якого через кабель підключено кілька пк підмережа та до нього ж підключена точка доступу Mikrotik cAP ax (з своїм dhcp) до якої і підключається більшість ноутбуків/телефонів та інших пристроїв з підтримкою wifi. Проблема наступна: регулярно відбуваються збої в роботі інтернету на пристроях які підключені до точки доступу, інколи просто вилітає віддалений робочий стіл (підключений через vpn), а інколи техніка переключається з 5г мережі на 2г. Спроби пінгувати точку показують що є регулярні стрибки пінга від 1-2 мс до 400-500-600+ мс (міряв як через cmd так і pingplotter) на різних пк, через netmonitor видно що стрибає якість сигналу від 40 до 70-80 і назад, при тому що телефон не переміщається і знаходиться за 2-3м від точки. 



      Спочатку думав на налаштування точки - перепробував різні частоти, нічого не змінилось. Переміщав точку в різні місця - результату 0. Вмикав wifi інтерфейс на прихідному тіку, картина та ж що і на точці. 
      І на 2г і на 5г ситуація плюс мінус однакова. 

      Допоможіть зрозуміти, що може спричиняти такі збої та головне як з цим боротись?
    • Від Люкс Мобил
      Нові з гарантією 12 міс
      Маршрутизатор MikroTik CCR2004-1G-12S+2XS
      Комутатор керований рівня 3 Mikrotik CRS518-16XS-2XQ-RM
      Комутатор MikroTik CRS326-24S+2Q+RM (24xSFP+, 2xQSFP+, USB, 1хRJ45)
      Комутатор MikroTik CRS312-4C+8XG-RM (8xGE PoE, 4xCombo, USB, 1хRJ45)
      Комутатор MikroTik CRS504-4XQ-IN
      Комутатор керований MikroTik CRS510-8XS-2XQ-IN
       
      0674400029 Роман (viber, telegram)
    • Від GekaPeka
      mikrotik RB 40111GS+RM новый, 7500 грн.
    • Від DjBodya
      Вітаю.
      Одразу попереджу, що з мікротіками не новачок. Знаю, як з ними поводитись і налаштовувати.
      Купив собі це диво. І не можу налаштувати. 
      Скидаю в нуль, або просто включаю, без різниці. Буває вдається навіть підключитися по winbox. Потім вилітає в помилку.
      Зазвичай одразу System LED переходить в режим блимаючого червоного і все. 
      DHCP не роздає. По МАС підключитися не вдається.
    • Від mac
      Глюк в тому, що один (так - тільки один) mac адрес onu існує в білінгу у вигляді строки. Це трохи заважає.
      olt - bdcom gepon.
      Наскільки зрозумів, це виключно проблема реалізації snmpwalk у freebsd, де snmpwalk може на свій розсуд віддати mac адресу не як hex-string, а як звичайний string.
      Можливо snmpwalk тригериться на якомусь символі, мені невідомо.
       
      # tcpdump -vv -i em0 udp port 161 and host olt and host ub | grep "3320.101.10.4.1.1.241 ... olt.snmp > ub.47940: [udp sum ok] { SNMPv2c C="*****" { GetResponse(44) R=93278354 E:3320.101.10.4.1.1.241="8LO"W*" } } ub.47940 > olt.snmp: [udp sum ok] { SNMPv2c C="*****" { GetNextRequest(34) R=93278355 E:3320.101.10.4.1.1.241 } } snmpwalk -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = STRING: "8LO\"W*" snmpwalk -Ox -c***** -v2c -t5 olt .1.3.6.1.4.1.3320.101.10.4.1.1 SNMPv2-SMI::enterprises.3320.101.10.4.1.1.241 = Hex-STRING: 38 4C 4F 22 57 2A  
      Це стосується таких параметрів у snmp конфізі bdcom
       
      [signal] MACINDEX=".1.3.6.1.4.1.3320.101.10.4.1.1" [misc] ONUINDEX=".1.3.6.1.4.1.3320.101.11.1.1.3"  
      За для усунення глюку спробував трошки змінити код і завдати тип snmp параметру явно у ./api/libs/api.ponbdcom.php у function collect()
      Це працює. Мабуть станеться у нагоді:
       
      # diff api.ponbdcom.php{.new,.bak} 37c37 < $onuIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); --- > $onuIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $onuIndexOid, self::SNMPCACHE); 91c91 < $macIndex = $this->snmp->walk('-Ox ' . $oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE); --- > $macIndex = $this->snmp->walk($oltIp . ':' . self::SNMPPORT, $oltCommunity, $macIndexOID, self::SNMPCACHE);  
      P.S. Створив тему, а зараз міркую: а може це глюк у ПЗ olt. Оновлю фірмваре olt та перевірю...
       

×
×
  • Створити нове...