abills.net.ua

Итак Abills 0.36b отлично работает под FreeBSD 5.5-RELEASE на одном серваке, в связке

Exppp_asm-0.2.4 + FreeRADIUS 1.1.6 + MySQL 4.1.22 + Apache/1.3.37



Сейчас мучаюсь с 0.40b взятой с сайта т.е. релиз как я понял ( из cvs версию ещё не мучал ) под FreeBSD 7.0 в связке

Exppp_asm-0.2.4 + FreeRADIUS 1.1.7 + MySQL 4.1.22 + Apache/2.2.9

Проблема вот какая. Пользователи авторизуются, ip присваиваются, скорость зарезается пока всё хорошо. Если авторизован один пользователь у него есть инет всё замечательно, но стоит авторизоваться второму пользователю как начинается расколбас.

У первого пользователя по прежнему инет есть, а второй даже ip адрес серверной стороны в VPN тунели пингануть не может (

Думал может exppp я неправильно поправил для 7.0 фряхи, попробовал этот http://code.google.com/p/exppp/source/checkout и само собой словарик RADIUS который шёл в комплекте эффект тот же.

Вот сами интерфейсы

tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1490
inet 172.22.22.1 --> 172.22.22.207 netmask 0xffffff00
Opened by PID 82044
tun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1490
inet 172.22.22.1 --> 172.22.22.45 netmask 0xffffff00
Opened by PID 82202


Из аномалий я вижу, что

1. Маршруты

172.22.22.45 172.22.22.1 UGH 0 0 tun0
172.22.22.95 172.22.22.1 UGH 0 0 tun0
172.22.22.128 172.22.22.1 UGH 0 0 tun0
172.22.22.207 172.22.22.1 UGH 0 0 tun0

172.22.22.1 - это у меня серверная сторона в VPN тунели. Как видно маршруты все почему-то цепляются к tun0 хотя каждый должен цепляться к своему tun.

Постепенно, даже при корректном отключение VPN соединения, таблица заполняется такими записями, ну и понятно tun0 же не отключается. Допустим пользователь test0 сидит на tun0, test1 сел на tun1. После дисконнекта test1, сам фейс tun1 отключается, а маршрут остаётся висеть привязанным к tun0.

2. В логе /var/log/ppp.log

Jan 11 11:37:53 MegaSRV ppp[82202]: tun1: Warning: tun1: DIFADDR 172.22.22.1/24 -> 172.22.22.71 returns 0
Jan 11 11:37:53 MegaSRV ppp[82202]: tun1: Warning: tun1: AIFADDR 172.22.22.1/24 -> 172.22.22.45 returns

что-то ему тут не нравится...

Обновился до current версии 0.41b, что в cvs грабли теже. В логах RADIUS наткнулся

rlm_acct_unique: WARNING: Attribute NAS-Port was not found in request, unique ID MAY be inconsistent

Этот варнинг вылезает только при использование exppp который взят тут http://code.google.com/p/exppp/source/checkout, с Exppp_asm-0.2.4
его нету, а атрибут NAS-Port присваивается.

Поробовал current версию с оригинальным NAS Exppp_asm-0.2.4 взятым из soft папочки Abills эфект прежний.


Может быть кто сталкивался с такой засадой ??? А то как-то откатываться на старую версию ОС и биллинга.

Заранее благодарю всех отозвавшихся.

Тем временем продолжая рыть доки, логи, форум и вспоминаю первую настройку abills =)

Exppp_asm-0.2.4 не работает с 7 фрей


нужно брать форк с гугла

~AsmodeuS~, огромное спасибо за ответ ! С гугла форк я пробовал ситуация таже. Теперь от меня 5 копеек.

Завёл конфигурацию : FreeBSD 7.0 + Exppp_asm-0.2.4 ( оригинальный, тот что идёт с abills в папке soft ) + FreeRADIUS 1.1.7 + MySQL 4.22 + Apache/2.2.9 + Abills 0.41b из CVS-са

1. По поводу глюков с маршрутами, нашёл вот такую информацию
https://kerneltrap.org/mailarchive/free ... 15/4419024
к сожилению я ktrace-сить не умею ( Там человек предлогает решение, для нашего случие оно видоизменяется таким образом.

# cat /etc/ppp/ppp.linkup

MYADDR:
!bg /usr/abills/libexec/linkupdown up INTERFACE USER HISADDR
!bg /sbin/route del HISADDR
!bg /sbin/route add HISADDR -iface INTERFACE

После этого маршруты принимают такой вид.

172.22.22.38 tun0 UHS 0 234 tun0
172.22.22.150 tun1 UHS 0 0 tun1

Как видим флажка G больше нет и всё работает.

2. Проблема с linkupdown при запуске оно выводило такую хрень

# /usr/abills/libexec/linkupdown up tun1 test3 172.22.22.169 debug
DBD::mysql::st execute failed: Unknown column 'tp.postpaid_fee' in 'field list' at /usr/abills/libexec/../Abills/mysql/main.pm line 178.
Error: User not exist ([2] ERROR_NOT_EXIST)

Не видит оно колонку, только вот почему tp сокращённо как-то ?

Т.к. у меня версия 0.41b, в её базе т.е. в файле abills.sql поля postpaid_fee нет в таблице tarif_plans =) Понятно почему скрипт орёт, зато есть postpaid_daily_fee, postpaid_monthly_fee согласно changelog в которые были перенесены данные из postpaid_fee

ALTER TABLE tarif_plans ADD COLUMN postpaid_daily_fee tinyint(1) unsigned NOT NULL default '0';
ALTER TABLE tarif_plans ADD COLUMN postpaid_monthly_fee tinyint(1) unsigned NOT NULL default '0';
UPDATE tarif_plans SET postpaid_daily_fee=postpaid_fee, postpaid_monthly_fee=postpaid_fee;

Но как я понимаю эти изменения не были учтены ( В итоге linkupdown не пашет. Понятно что linkupdown не сам получает информацию о пользователе, а использует /usr/abills/Abills/mysql/Dv.pm в котором как раз и есть этот запрос.

96 $self->query($db, "SELECT dv.uid, dv.tp_id,
97 tp.name,
98 dv.logins,
99 INET_NTOA(dv.ip),
100 INET_NTOA(dv.netmask),
101 dv.speed,
102 dv.filter_id,
103 dv.cid,
104 dv.disable,
105 dv.callback,
106 dv.port,
107 tp.gid,
108 tp.month_fee,
109 # !!!
110 # tp.postpaid_fee,
111 tp.payment_type,
112 dv.join_service,
113 dv.turbo_mode

Вкуривать как оно работает пока не стал, а просто закоментил это поле, не спорю это не решения, это workaround. Да и люди хотят инета.

Как могу предполагать поле postpaid_fee относится к Periodic payments в тарифах, а у меня это не используется. Хотя потом планируется. А может ошибаюсь нужно разбираться.

Такая команда мне показала где ещё используются это старое поле вместо 2х новых, на придмет может не всё так просто. Iptv у нас нету =)

# grep -Rn postpaid_fee /usr/abills/*
/usr/abills/Abills/mysql/Dv.pm:110:# tp.postpaid_fee,
/usr/abills/Abills/mysql/Iptv.pm:89: tp.postpaid_fee,

После этих фиксов скрипт стал нормально отрабатывать положенное.

Но есть всё таки один вопрос по его работе, сами pipe из правил фаервола удаляются после дисконекта пользователя, но следы остаются вот, что я имею введу

# ipfw show

00500 23830 1801127 divert 8668 ip from 172.22.22.0/24 to any via re1
00600 195130 83518268 divert 8668 ip from any to 192.168.1.1 via re1
03000 4347 297656 pipe 3000 ip from any to any via tun0 in
03001 4411 700000 pipe 3001 ip from any to any via tun0 out
65535 424576 149043575 allow ip from any to any

# ifconfig tun0
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1490
inet 172.22.22.1 --> 172.22.22.38 netmask 0xffffff00
Opened by PID 86900

В данный момент подключен только абонент с tun0 и ip 172.22.22.38

# ipfw pipe show
03000: 128.000 Kbit/s 0 ms 12 KB 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
0 udp 172.22.22.12/137 255.255.255.255/137 4401 303659 0 0 0
03001: 128.000 Kbit/s 0 ms 12 KB 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
0 udp 213.180.204.8/53 172.22.22.205/55249 4424 701014 0 0 9
03002: 128.000 Kbit/s 0 ms 12 KB 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
0 udp 172.22.22.150/68 255.255.255.255/67 32 4408 0 0 0
03003: 128.000 Kbit/s 0 ms 12 KB 1 queues (1 buckets) droptail
mask: 0x00 0x00000000/0x0000 -> 0x00000000/0x0000
BKT Prot ___Source IP/port____ ____Dest. IP/port____ Tot_pkt/bytes Pkt/Byte Drp
0 icmp 172.22.22.1/0 172.22.22.150/0 1 60 0 0 0

А тут всё просто пестрит чем-то, но ip-шки 172.22.22.38 которая привязана к интерфейсу tun0, на который навешан pipe нету ? Хотя может это так ipfw pipe работают.

Ещё раз благодарю всех кто отозвался =)))

Отлов глюков с Exppp_asm-0.2.4 продолжается, иногда описанный мой workaround для ришения проблем с маршрутами почему-то не срабатывает и в итоге наблюдается такая картина

172.22.22.196 tun0 UGHS 0 216 tun0

Т.е. видно, что маршрут стал статическим ( значет команды по его пересозданию выполнились ) , но флажок G всеровно присутствует, реконнект либо ручное удоление и прописование решает проблему.

Наверно можно написать ещё какой-то wathdog который в неком интервале по крону будет следить за появлением таких маршрутов и править их.

Дубляж какой-то.

пайпы без направленых в них пакетов ничего не делают


а направляются они через ipfw show

и нужно там искать что куда + идёт шейпер не по ип, а по интерфейсу

Спасибо за разъяснение !

Связка к сожалению пока не стабильна, при мониторинге таблицы маршрутизации в логах появляется вот такая херь

Мониторится такой строчкой по крону

*/1 * * * * root netstat -rn | grep UGH >> /var/log/route_monitor.log

# cat /var/log/route_monitor.log
172.22.22.159 tun2 UGHS 0 20 tun2
172.22.22.159 tun2 UGHS 0 92 tun2
172.22.22.159 tun2 UGHS 0 140 tun2
172.22.22.159 tun2 UGHS 0 176 tun2
172.22.22.159 tun2 UGHS 0 212 tun2
172.22.22.159 tun2 UGHS 0 220 tun2
172.22.22.159 tun2 UGHS 0 220 tun2
172.22.22.252 tun2 UGHS 0 138 tun2
172.22.22.252 tun2 UGHS 0 428 tun2
172.22.22.27 tun4 UGHS 0 14 tun4
172.22.22.27 tun4 UGHS 0 392 tun4
172.22.22.202 tun1 UGHS 0 58 tun1
172.22.22.236 tun1 UGHS 0 64 tun1
172.22.22.236 tun1 UGHS 0 156 tun1
172.22.22.236 tun1 UGHS 0 230 tun1
172.22.22.210 tun6 UGHS 0 128 tun6
172.22.22.210 tun6 UGHS 0 180 tun6
172.22.22.210 tun6 UGHS 0 180 tun6
172.22.22.210 tun6 UGHS 0 180 tun6

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

Будем думать как это поправить, можно написать скриптец который будет ходить на pptpctrl по телнету и дропать пользователя если маршрут не правельно прописался. Хотя писать не нуна, взять функционал с билинга =)

Может там корректно можно маршрут пересоздать, нужно смотреть.

Да ещё как всё чудит ( Я наблюдаю за маршрутами. И вот что с ними творится.

Fri Jan 23 20:59:00 UTC 2009

172.22.22.159 tun2 UGHS 0 20 tun2
172.22.22.159 tun2 UGHS 0 92 tun2
172.22.22.159 tun2 UGHS 0 140 tun2
172.22.22.159 tun2 UGHS 0 176 tun2
172.22.22.159 tun2 UGHS 0 212 tun2
172.22.22.159 tun2 UGHS 0 220 tun2
172.22.22.159 tun2 UGHS 0 220 tun2
172.22.22.252 tun2 UGHS 0 138 tun2
172.22.22.252 tun2 UGHS 0 428 tun2
172.22.22.27 tun4 UGHS 0 14 tun4
172.22.22.27 tun4 UGHS 0 392 tun4
172.22.22.202 tun1 UGHS 0 58 tun1
172.22.22.236 tun1 UGHS 0 64 tun1
172.22.22.236 tun1 UGHS 0 156 tun1
172.22.22.236 tun1 UGHS 0 230 tun1
172.22.22.210 tun6 UGHS 0 128 tun6
172.22.22.210 tun6 UGHS 0 180 tun6
172.22.22.210 tun6 UGHS 0 180 tun6
172.22.22.210 tun6 UGHS 0 180 tun6
172.22.22.243 tun9 UGHS 0 158 tun9
172.22.22.243 tun9 UGHS 0 244 tun9
172.22.22.243 tun9 UGHS 0 244 tun9
172.22.22.243 tun9 UGHS 0 244 tun9
172.22.22.243 tun9 UGHS 0 244 tun9
172.22.22.93 tun3 UGHS 0 0 tun3
172.22.22.93 tun3 UGHS 0 0 tun3
172.22.22.93 tun3 UGHS 0 0 tun3
172.22.22.93 tun3 UGHS 0 0 tun3
172.22.22.93 tun3 UGHS 0 0 tun3

По таким строкам видно, что маршрут даже пересозданый таким способом, всеровно может содержать флаг G.

# cat /etc/ppp/ppp.linkup

MYADDR:
!bg /usr/abills/libexec/linkupdown up INTERFACE USER HISADDR
!bg /sbin/route del HISADDR
!bg /sbin/route add HISADDR -iface INTERFACE


Или вот один туннель как начнёт чюдить (


172.22.22.7 172.22.22.1 UGH 0 0 tun0
172.22.22.17 172.22.22.1 UGH 0 0 tun0
172.22.22.31 172.22.22.1 UGH 0 0 tun0
172.22.22.32 172.22.22.1 UGH 0 0 tun0
172.22.22.81 172.22.22.1 UGH 0 0 tun0
172.22.22.142 172.22.22.1 UGH 0 0 tun0
172.22.22.153 172.22.22.1 UGH 0 0 tun0
172.22.22.156 172.22.22.1 UGH 0 0 tun0
172.22.22.168 172.22.22.1 UGH 0 0 tun0
172.22.22.173 172.22.22.1 UGH 0 0 tun0
172.22.22.220 172.22.22.1 UGH 0 0 tun0
Fri Jan 23 21:00:00 UTC 2009
172.22.22.7 172.22.22.1 UGH 0 0 tun0
172.22.22.17 172.22.22.1 UGH 0 0 tun0
172.22.22.31 172.22.22.1 UGH ^C
172.22.22.220 172.22.22.1 UGH 0 0 tun0
Fri Jan 23 21:03:00 UTC 2009
172.22.22.7 172.22.22.1 UGH 0 0 tun0
172.22.22.17 172.22.22.1 UGH 0 0 tun0
172.22.22.31 172.22.22.1 UGH 0 0 tun0
172.22.22.32 172.22.22.1 UGH 0 0 tun0
172.22.22.81 172.22.22.1 UGH 0 0 tun0
172.22.22.142 172.22.22.1 UGH 0 0 tun0
172.22.22.153 172.22.22.1 UGH 0 0 tun0
172.22.22.156 172.22.22.1 UGH 0 0 tun0
172.22.22.168 172.22.22.1 UGH 0 0 tun0
172.22.22.173 172.22.22.1 UGH 0 0 tun0
172.22.22.220 172.22.22.1 UGH 0 0 tun0

Fri Jan 23 21:04:00 UTC 2009
172.22.22.7 172.22.22.1 UGH 0 0 tun0
172.22.22.17 172.22.22.1 UGH 0 0 tun0
172.22.22.31 172.22.22.1 UGH 0 0 tun0
172.22.22.32 172.22.22.1 UGH 0 0 tun0
172.22.22.81 172.22.22.1 UGH 0 0 tun0
172.22.22.142 172.22.22.1 UGH 0 0 tun0
172.22.22.153 172.22.22.1 UGH 0 0 tun0
172.22.22.156 172.22.22.1 UGH 0 0 tun0
172.22.22.168 172.22.22.1 UGH 0 0 tun0
172.22.22.173 172.22.22.1 UGH 0 0 tun0
172.22.22.220 172.22.22.1 UGH 0 0 tun0

viewtopic.php?t=4011&highlight=

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

А я забил на exppp. После того как поборол глюк с маршрутами

# cat /etc/ppp/ppp.linkup

MYADDR:
!bg /usr/abills/libexec/linkupdown up INTERFACE USER HISADDR
!bg /sbin/route del HISADDR
!bg /sbin/route add HISADDR -iface INTERFACE

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

В итоге перешёл на MPD

# mpd5 -v
Version 5.2 (root@MegaSRV 16:00 5-Mar-2009)

И о чудо сразу всё заработало как часы ! PPTP подключение с Linux-а которое до этого почему-то не проходило, прошло с первого раза.

Так что х.з. что за грабли с exppp, с MPD работает как часы !

с 7 версией mpd тоже нормально не работает (связано с shed_ule и другими серьезными изменениями). Ставьте 6.4 с net.inet.ip.dummynet.io_fast=1 и net.inet.ip.fastforwarding=1 - производительность увеличивается в разы.

У меня 7.0-RELEASE-p12 i386, perl v5.8.8, FreeRADIUS 1.1.7, mpd5.2 Работоет нормално,проблем нет. ядро с options SCHED_4BSD.

fregl писал(а):2. Проблема с linkupdown при запуске оно выводило такую хрень

# /usr/abills/libexec/linkupdown up tun1 test3 172.22.22.169 debug
DBD::mysql::st execute failed: Unknown column 'tp.postpaid_fee' in 'field list' at /usr/abills/libexec/../Abills/mysql/main.pm line 178.
Error: User not exist ([2] ERROR_NOT_EXIST)

Не видит оно колонку

это поле было добавлено ещё в версии 0.3

ченжлог писал(а): *
02.03.2007 - доработка тарифных планов

MySQL

ALTER TABLE tarif_plans add column reduction_fee tinyint(1) unsigned NOT NULL default '0';
ALTER TABLE tarif_plans add column postpaid_fee tinyint(1) unsigned NOT NULL default '0';
ALTER TABLE dhcphosts_hosts add column comments varchar(250) NOT NULL default '';