[hsvt]

Господа, не поделитесь конфигом (секцией) под LANBilling + IPoE ?

[pashaumka]

на днях поставил сервак на дебиане 8.1

 

полезла вот такая хрень

 

 

[271615.963660] kernel tried to execute NX-protected page - exploit attempt? (uid: 0)

[271615.963683] BUG: unable to handle kernel paging request at ffff88021425f9e0

[271615.963705] IP: [<ffff88021425f9e0>] 0xffff88021425f9e0

[271615.963729] PGD 1af4067 PUD 1af7067 PMD 214212063 PTE 800000021425f163

[271615.963753] Oops: 0011 [#1] SMP

[271615.963768] Modules linked in: arc4 ecb ppp_mppe act_police cls_u32 sch_ingress sch_tbf cls_flow sch_htb ifb xt_nat ip6table_filter pppoe pppox ppp_generic slhc ip6_tables xt_TCPMSS xt_tcpudp iptable_mangle iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_filter ip_tables x_tables nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc 8021q garp stp mrp llc joydev coretemp pcspkr kvm evdev iTCO_wdt iTCO_vendor_support serio_raw i2c_i801 i5100_edac i2c_core ioatdma dca edac_core lpc_ich button mfd_core shpchp processor thermal_sys autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid hid sg sd_mod crc_t10dif crct10dif_generic crct10dif_common ata_generic ata_piix libata uhci_hcd ehci_pci ehci_hcd e1000e scsi_mod ptp usbcore pps_core usb_common

[271615.964129] CPU: 6 PID: 1313 Comm: accel-pppd Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt11-1+deb8u2

[271615.964150] Hardware name: Supermicro X7DCA-L/X7DCA-L, BIOS 1.0a 05/29/2008

[271615.964167] task: ffff8800dac9f330 ti: ffff8802162a8000 task.ti: ffff8802162a8000

[271615.964185] RIP: 0010:[<ffff88021425f9e0>] [<ffff88021425f9e0>] 0xffff88021425f9e0

[271615.964243] RSP: 0018:ffff8802162abe00 EFLAGS: 00010246

[271615.964277] RAX: ffff8800cdc39b70 RBX: ffff8802162abe68 RCX: ffff8802162abe68

[271615.964327] RDX: ffff8802162abee0 RSI: ffff8802162abe18 RDI: ffff8800cdc39c00

[271615.964378] RBP: 0000000000000000 R08: ffff880213669a98 R09: 0000000000000002

[271615.964428] R10: 0000000000000000 R11: 0000000000000000 R12: 00000000015fabc0

[271615.964478] R13: ffff8802162abee0 R14: ffff880216292b80 R15: ffff880213669a98

[271615.964537] FS: 00007fc69609c700(0000) GS:ffff88021fd80000(0000) knlGS:0000000000000000

[271615.964589] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b

[271615.964621] CR2: ffff88021425f9e0 CR3: 0000000036617000 CR4: 00000000000007e0

[271615.964671] Stack:

[271615.964694] ffffffff811e7bf2 ffff8800dac9f330 ffff880216292be0 0000000000000000

[271615.964751] 0000000080000019 ffffffff811e7b50 ffff8802162abe68 0000000000000000

[271615.964808] ffff8802162abee0 ffff880216292be0 ffff880216292b80 ffffffff811e838a

[271615.964865] Call Trace:

[271615.964894] [<ffffffff811e7bf2>] ? ep_send_events_proc+0xa2/0x1b0

[271615.964928] [<ffffffff811e7b50>] ? ep_read_events_proc+0xc0/0xc0

[271615.964962] [<ffffffff811e838a>] ? ep_scan_ready_list.isra.7+0x8a/0x1c0

[271615.964996] [<ffffffff811e85f3>] ? ep_poll+0x113/0x340

[271615.965028] [<ffffffff81096920>] ? wake_up_state+0x10/0x10

[271615.965060] [<ffffffff811e9bc4>] ? SyS_epoll_wait+0xb4/0xe0

[271615.965094] [<ffffffff8151158d>] ? system_call_fast_compare_end+0x10/0x15

[271615.965127] Code: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ea ff ff 01 00 00 00 03 00 03 00 05 00 f8 02 00 ea ff ff <b7> 1e 00 00 00 00 00 00 b8 9b c3 cd 00 88 ff ff 5b db a9 ad 00

[271615.965341] RIP [<ffff88021425f9e0>] 0xffff88021425f9e0

[271615.965373] RSP <ffff8802162abe00>

[271615.965399] CR2: ffff88021425f9e0

[271615.965658] ---[ end trace 814ff7434a041a43 ]---

[Asatiany]

Приветствую!

Являюсь сотрудником провайдера "последней мили". Раздаем Интернет через VPN (PPTP) + NAT.

Есть проблема, которую решить сам уже не в силах. Суть вот в чем.

Есть сервер биллинга (Ideco ICS, RADIUS-server) и NAS (AltLinux Server, PPTP на accel-ppp). Недавно обновили биллинг до более свежей версии. Сразу же после обновления стали отваливаться клиенты, использующие роутеры фирм Asus, Zyxel, D-Link. Владельцы Tp-Link'ов и те, кто сидит на "прямом" подключении, проблему не заметили. Обнаружили вот какую особенность.

Большинство проблемных клиентов имеют роутеры Asus (RT-N12_VP). При настройках, рекомендованных нами, а именно "Параметры PPTP - Без шифрования", "Дополнительные параметры pppd - nomppe nomppc", Интернет-соединения нет. В логах роутеров указано так:

Aug 5 10:30:37 pptp[2215]: Connect: ppp0 <--> pptp (10.90.1.1)

Aug 5 10:30:39 pptp[2215]: MS-CHAP authentication failed: ^M^JYou are already logged in - access denied^M^J^J

Aug 5 10:30:39 pptp[2215]: CHAP authentication failed

Aug 5 10:30:39 pptp[2215]: Connection terminated.

Aug 5 10:30:50 pptp[2215]: Connect: ppp0 <--> pptp (10.90.1.1)

Aug 5 10:30:50 pptp[2215]: CHAP authentication succeeded

Aug 5 10:30:53 pptp[2215]: Connection terminated.

Aug 5 10:30:53 pptp[2215]: Modem hangup

Aug 5 10:31:04 pptp[2215]: Connect: ppp0 <--> pptp (10.90.1.1)

Aug 5 10:31:06 pptp[2215]: MS-CHAP authentication failed: ^M^JYou are already logged in - access denied^M^J^J

Aug 5 10:31:06 pptp[2215]: CHAP authentication failed

Aug 5 10:31:06 pptp[2215]: Connection terminated.

И так циклично. Если наши рекомендации поставить в дефолтные значения - Интернет появляется, но всегда на одной и той же скорости (~18Mbit/s), не зависимо от выставленной в биллинге! Пытались решить так:

1) убрали использование шифрования на биллинг-сервере (в консольном меню);

2) меняли версии (что за версии??? нигде не нашел описания, но пробовали и 1-ую (на ней упоминание о MS-CHAP пропадает), и 5-ую, и 6-ую) там же во вкладке "RADIUS-сервер";

3) техподдержка Asus кивает на нас;

4) техподдержка разрабов биллинга кивает в сторону нашего NAS-сервера (хотя никакие настройки на нем не меняли, да и проблемы начались после обновления биллинга);

5) убивали сессии принудительно (скриптом);

6) вот accel-ppp.conf

[modules]

#path=/usr/local/lib/accel-ppp

log_file

#log_tcp

#log_pgsql

pptp

#pppoe

l2tp

auth_mschap_v2

#auth_mschap_v1

#auth_chap_md5

#auth_pap

#connlimit

radius

#ippool

sigchld

pppd_compat

#shaper_tbf

#chap-secrets

 

[core]

log-error=/var/log/accel-ppp/core.log

thread-count=4

stack-size=2097152

 

[ppp]

verbose=1

min-mtu=1280

mtu=1460

mru=1460

#ccp=0

#sid-case=upper

#check-ip=0

#single-session=replace

#mppe=require

ipv4=require

#ipv6=allow

#ipv6-intf-id=0:0:0:1

#ipv6-peer-intf-id=0:0:0:2

#ipv6-accept-peer-intf-id=1

lcp-echo-interval=30

lcp-echo-failure=10

lcp-echo-timeout=300

seq-file=/var/run/accel-ppp/seq

 

[pptp]

#echo-interval=30

verbose=1

 

[l2tp]

#dictionary=/usr/local/share/accel-ppp/l2tp/dictionary

#hello-interval=60

#timeout=60

#rtimeout=5

#retransmit=5

dir300_quirk=1

host-name=l2tp-vpn

verbose=1

 

[dns]

dns1=10.90.0.2

dns2=10.90.0.3

 

[radius]

#dictionary=/usr/local/share/accel-ppp/radius/dictionary

nas-identifier=nas1

nas-ip-address=62.33.93.11

gw-ip-address=10.128.0.128

server=62.33.93.5,radnas1

dae-server=62.33.93.11:2002,otkl57

verbose=1

timeout=15

max-try=3

#acct-interim-interval=3600

#force-acct-interim-interval=1

interim-verbose=1

#fail-time=1

acct-timeout=180

#acct-delay-time=0

 

[client-ip-range]

10.90.0.0/16

 

[log]

log-file=/var/log/accel-ppp/accel-ppp.log

log-emerg=/var/log/accel-ppp/emerg.log

log-fail-file=/var/log/accel-ppp/auth-fail.log

#log-debug=/dev/stdout

#log-tcp=127.0.0.1:3000

copy=1

#color=1

#per-user-dir=per_user

#per-session-dir=per_session

#per-session=1

level=3

#log-tcp=127.0.0.1:3000

 

[pppd-compat]

ip-pre-up=/etc/ppp/ip-pre-up

ip-up=/etc/ppp/ip-up

ip-down=/etc/ppp/ip-down

ip-change=/etc/ppp/ip-change.sh

radattr-prefix=/var/run/radattr

verbose=1

 

#[connlimit]

#limit=10/m

#burst=3

#timeout=60

 

[cli]

telnet=0.0.0.0:2000

tcp=0.0.0.0:2001

#password=123

 

#[snmp]

#master=0

#agent-name=accel-ppp

Тут пробовали менять:

single-session=replace

mppe=deny

#dae-server=62.33.93.11:2002,otkl57

timeout=15 меняли на 10 с и на 20 с

Все наши действия не помогли!

Вот radiusd.conf с NAS:

# -*- text -*-

 

prefix = /usr

exec_prefix = /usr

sysconfdir = /etc

localstatedir = /var

sbindir = /usr/sbin

logdir = ${localstatedir}/log/radius

raddbdir = ${sysconfdir}/raddb

radacctdir = ${logdir}/radacct

 

name = radiusd

 

confdir = ${raddbdir}

run_dir = ${localstatedir}/run/${name}

 

db_dir = ${raddbdir}

 

libdir = /usr/lib64/freeradius

 

pidfile = ${run_dir}/${name}.pid

 

#chroot = /path/to/chroot/directory

 

user = radiusd

group = radiusd

 

max_request_time = 30

 

cleanup_delay = 5

 

max_requests = 1024

 

listen {

type = auth

ipaddr = *

# ipv6addr = :: # any. ::1 == localhost

port = 0

# interface = eth0

# clients = per_socket_clients

}

 

listen {

ipaddr = *

# ipv6addr = ::

port = 0

type = acct

# interface = eth0

# clients = per_socket_clients

}

 

hostname_lookups = no

 

allow_core_dumps = no

 

regular_expressions = yes

extended_expressions = yes

 

log {

destination = files

file = ${logdir}/radius.log

#requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log

syslog_facility = daemon

stripped_names = no

auth = no

auth_badpass = no

auth_goodpass = no

# msg_goodpass = ""

# msg_badpass = ""

}

 

checkrad = ${sbindir}/checkrad

 

# SECURITY CONFIGURATION

 

security {

max_attributes = 200

reject_delay = 1

status_server = yes

}

 

# PROXY CONFIGURATION

 

proxy_requests = yes

$INCLUDE proxy.conf

 

 

# CLIENTS CONFIGURATION

 

$INCLUDE clients.conf

 

 

# THREAD POOL CONFIGURATION

 

thread pool {

start_servers = 5

max_servers = 32

min_spare_servers = 3

max_spare_servers = 10

# max_queue_size = 65536

max_requests_per_server = 0

}

 

# MODULE CONFIGURATION

 

modules {

$INCLUDE ${confdir}/modules/

$INCLUDE eap.conf

# $INCLUDE sql.conf

# $INCLUDE sql/mysql/counter.conf

# $INCLUDE sqlippool.conf

}

 

# Instantiation

 

instantiate {

exec

expr

# daily

expiration

logintime

#redundant redundant_sql {

# sql1

# sql2

#}

}

 

$INCLUDE policy.conf

$INCLUDE sites-enabled/

Модификация модуля mschap также не помогла!

Запустив radius в debug-режиме (на биллинге), проблему не определили: что с "прямым", что с проблемными роутерами, что с Tp-Link'ами. Все работает нормально. name и secret NAS'а на биллинге в качестве клиента указаны верно.

А вот лог проблемного подключения:

[2015-08-10 13:09:30]: info: ppp88: send [RADIUS(1) Access-Request id=1

<User-Name "testik">

<NAS-Identifier "nas1">

<NAS-IP-Address 62.33.93.11>

<NAS-Port 88>

<NAS-Port-Type Virtual>

<Tunnel-Type PPTP>

<Service-Type Framed-User>

<Framed-Protocol PPP>

<Calling-Station-Id "10.90.16.245">

<Called-Station-Id "10.90.1.1">

<Microsoft MS-CHAP-Challenge >

<Microsoft MS-CHAP2-Response >]

[2015-08-10 13:09:30]: info: ppp88: recv [RADIUS(1) Access-Accept id=1

<Configuration-Token "100">

<Acct-Interim-Interval 300>

<Framed-IP-Address 172.19.0.200>

<Connect-Info "TYPE=unlim,UP=30000,DOWN=75000">

<Filter-Id "0">

<Microsoft MS-CHAP2-Success >

<Microsoft MS-MPPE-Recv-Key >

<Microsoft MS-MPPE-Send-Key >

<Microsoft MS-MPPE-Encryption-Policy 2>

<Microsoft MS-MPPE-Encryption-Type 4>]

[2015-08-10 13:09:30]: info: ppp88: testik: authentication succeeded

[2015-08-10 13:09:30]: info: ppp88: disconnected

И все: адрес с биллинга не получен, Интернета - кукиш!!!

Заранее благодарен за помощь!

[kayot]

А какое отношение accel имеет к вашему биллингу?

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

[Asatiany]

А какое отношение accel имеет к вашему биллингу?

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

Согласен, что на биллинге в radius'е есть косяк, но разрабы его так не считают. На accel стал грешить из-за упоминания "двойного подключения". Думал, что сессии подвисают. По таймингам и по собственной проверке выходило минут 6 после отключения туннель держался... Куда копать? Признаю, в чем-то знаний не хватает. И даже прищучить разрабов не знаю как...

[GrandPr1de]

смотреть что шлет ваш радиус

ищите что летит в radreply, я лично без понятия где и как у вас происходит авторизация - спрашивайте у разрабов биллинга, где смотреть это

ну или дампы смотреть, как сказал kayot

[hsvt]

Как можно указать ацелю передавать на RADIUS Auth Packet с атрибутом Framed-IP-Address для авторизации по IP ?

[GrandPr1de]

он не пришлет там framed-ip-address, может прислать calling-station-id но там будет или мак или ip

а так достаточно в сценарий radcheck добавить это дело и будет проверять, только выясните в каком атрибуте у вас летит ip адрес клиента

Изменено 11 августа, 2015 пользователем GrandPr1de

[hsvt]

он не пришлет там framed-ip-address, может прислать calling-station-id но там будет или мак или ip

а так достаточно в сценарий radcheck добавить это дело и будет проверять, только выясните в каком атрибуте у вас летит ip адрес клиента

 

У меня LANBilling, радиус их соотвественно. Вот лог:

 

12.08.2015 10:35:00 VERBOSE     0x80280a800     [HandleRadius]  >=>=>=>=>=>=>=> Auth Packet received from 1.1.1.1, size: 121 >=>=>=>=>=>=>=>
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Authenticator: 996b775a98af194e700a2731bf1381a1
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'User-Name', value: "100.100.0.1"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'NAS-Identifier', value: "ipoe34"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'NAS-IP-Address', value: "1.1.1.1"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'NAS-Port', value: "3472"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'NAS-Port-Id', value: "1768976229"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'NAS-Port-Type', value: "15"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'Calling-Station-Id', value: "8c:89:a5:02:99:06"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'Called-Station-Id', value: "bond0.777"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseBody]     Attribute 'Password', value: "e11bca5c646208d9862d85e8586ab24c"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [ParseAttr]     User-Password = "100.100.0.1"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [TryAuthISG]    Trying to authenticate ISG with method 'ip'
12.08.2015 10:35:00 VERBOSE     0x80280a800     [CheckBlackList]        ANI '8c:89:a5:02:99:06' (User '100.100.0.1') is clean
12.08.2015 10:35:00 VERBOSE     0x80280a800     [TestPassword]  Password is match to user '100.100.0.1'.
12.08.2015 10:35:00 VERBOSE     0x80280a800     [AuthenticateFromDB]    User: '100.100.0.1', bill by traffic, unlimited session timeout (86400)
12.08.2015 10:35:00 INFO        0x80280a800     [RunAuthRequest]        Access-Accept, <100.100.0.1> [17328]
12.08.2015 10:35:00 VERBOSE     0x80280a800     [RunAuthRequest]        =============== Output attributes dump: ===============
12.08.2015 10:35:00 VERBOSE     0x80280a800     [RunAuthRequest]        Attribute 'Session-Timeout', value: "86400"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [RunAuthRequest]        Attribute 'Service-Type', value: "2"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [RunAuthRequest]        Attribute 'Framed-Protocol', value: "1"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [RunAuthRequest]        Attribute 'Class', value: "00017328"
12.08.2015 10:35:00 VERBOSE     0x80280a800     [RunAuthRequest]        Attribute 'Acct-Interim-Interval', value: "60"

 

Присылает CSID, но там МАК. Авторизацию необходимо сделать именно по IP, менять каждый раз маки в биллинге это не вариант :) При авторизации по IP, логины в текущем биллинге останутся как есть, их не придётся менять на логин вида "100.100.0.1"

 

radcheck как я понимаю относится к FreeRADIUS? Есть еще варианты?

 

http://accel-ppp.org/forum/viewtopic.php?f=4&t=442

 

для опции password добавлено специально значение csid.

csid означает Calling-Sation-Id, т.е. пароль будет такой-же как Calling-Station-Id.

В варианте использования start=up обеспечивает привязку IP/mac - IP передаётся через имя пользователя, mac через пароль.

 

Мой вариант использования как раз start=up, но вот надо бы передавать IP через дополнительный атрибут...

Изменено 12 августа, 2015 пользователем hsvt

[telecom]

К слову, не рекомендую 3.14 ядро. Во время массовых дисконнектов иногда были непонятные редкие глюки с сетевой подсистемой (похоже race condition при удалении шейперов и интерфейсов из-за чего отсыхали любые операции по созданию-удалению-получению списка интерфейсов). На 4.1 вроде полет нормальный.

....

из проверенных LTS ядер - 3.2 (аптайм пару лет был) и 4.1 (пока аптайм 2-3 недели но непоняток вроде нет). На 4.1 шустрее работает (меньше загрузка проца при той же нагрузке)

К слову, еще не факт, что 4.1 будет LTS. Как минимум все longterm-ядра четные)

А мне наоборот нравилось ядро 3.14. Глюков не замечал, работало с ноября 14 года.

Попробовал 4.1 - не понравилось.

Ушел на 3.18, пока полет нормальный.

[GrandPr1de]

что мешает переназначить в пределах радиуса логин что бы был равен ипишке? и авторизовать по ипишке

я ХЗ просто как там с вашим ЛБ дела обстоят, я просто сужу по тому как оно должно работать

у вас в юзернейм уже передается ип, только радиус нормально настройте и всё

Изменено 12 августа, 2015 пользователем GrandPr1de

[hsvt]

что мешает переназначить в пределах радиуса логин что бы был равен ипишке? и авторизовать по ипишке

я ХЗ просто как там с вашим ЛБ дела обстоят, я просто сужу по тому как оно должно работать

у вас в юзернейм уже передается ип, только радиус нормально настройте и всё

 

Ну вот саппорт утверждает что дополнительно нужен атрибут еще и с IP в запросе авторизации мол как на циске.

У нас около 12к логинов вида 111111 (префикс улицы, кв, дом) которые сейчас на PPPoE. Их и так придётся переводить на другой агент для IPoE постепенно, но вот стандартные логины хотелось бы сохранить. Может попробовать вариант с lua ? По opt82 собирать логин и еще по каким то пакетам остальное ?

radius-server attribute 8 include-in-access-req. А как можно связаться с разработчиком?

 

если авторизация происходить по произвольному пакету, значит сетевой стек клиента уже сконфигурирован и адрес известен, поэтому Framed-IP-Address может присутствовать в запросе авторизации

может, НО не обязан

Изменено 12 августа, 2015 пользователем hsvt

[GrandPr1de]

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

делаем вьюшку типа

 

CREATE OR REPLACE VIEW `radius_check` (`UserName`, `Attribute`, `op`, `Value`) AS
SELECT `ip` FROM `your_users_ip` ну и остальные параметры

 

и в радиус что-то вида

        authorize_check_query = "SELECT (@cnt := @cnt + 1) AS `id`, `UserName`, `Attribute`, `Value`, `op` \^M
         FROM `${authcheck_table}` \^M
         CROSS JOIN (SELECT @cnt := 0) AS `dummy` \^M
         WHERE `UserName` = '%{SQL-User-Name}' \^M
         ORDER BY `id`"^M

 

[NiTr0]

К слову, еще не факт, что 4.1 будет LTS. Как минимум все longterm-ядра четные)

Вроде обещали.

 

А мне наоборот нравилось ядро 3.14. Глюков не замечал, работало с ноября 14 года.

https://bugzilla.kernel.org/show_bug.cgi?id=100971

[telecom]

А мне наоборот нравилось ядро 3.14. Глюков не замечал, работало с ноября 14 года.

https://bugzilla.kernel.org/show_bug.cgi?id=100971

Печалька! У меня почти 2 года все нормально было...

Тем не менее, слез на 3.18.20, работает действительно шустрее.

[NiTr0]

Печалька! У меня почти 2 года все нормально было...

Угу. А еще больша печалька, что эта регрессия живет и в 4.1.2 :( уехал на 5 дней в отпуск - словил на 2 брасах баг.

Похоже, связано с тем что скрипты ip-down пытаются прибить шейперы, что вызывает race condition.

[telecom]

Печалька! У меня почти 2 года все нормально было...

Угу. А еще больша печалька, что эта регрессия живет и в 4.1.2 :( уехал на 5 дней в отпуск - словил на 2 брасах баг.

Похоже, связано с тем что скрипты ip-down пытаются прибить шейперы, что вызывает race condition.

Может не будем про отпуск?

У меня в последнии дни отпуска пограничник умер. Пришлось бегом через полстраны....

....

А никак нельзя это победить "костылями", например sleep 10 в ip-down в нужное место?

[NiTr0]

Уберу удаление шейпера из ip-down, посмотрю...

[Dmitry76]

Печалька! У меня почти 2 года все нормально было...

Угу. А еще больша печалька, что эта регрессия живет и в 4.1.2 :( уехал на 5 дней в отпуск - словил на 2 брасах баг.

Похоже, связано с тем что скрипты ip-down пытаются прибить шейперы, что вызывает race condition.

По-идее, если указать для accel не прибивать ppp интерфейсы (unit-cache=) то это поможет избежать проблемы.

Я в любом случае (еще со времен rp-pppoe) не удалял шейпера на выходе. При прибивании интерфейса ядром, шейпера тоже удалялись на ppp.

А при старте я в любом случае обнулял, мало-ли-чего.

Но у меня все шейпера только на ppp. Точнее, шейпер на исходе (для юзера это прием), а на входе просто полисер ingress:

 

#clear discipline

/sbin/tc qd del dev $int root >/dev/null 2>&1

/sbin/tc qdisc del dev $int handle ffff: ingress >/dev/null 2>&1

 

При такой схеме у меня сервера по три года аптайм имеют при трафике в обе стороны около 2Гбит.

 

На accel в тестовый сервер воткнул 10G карточку, запустился на 3.18.19 и зафигачил туда 5к онлайна при трафике в пиках 4G. Больше CPU не тянет (85-90%) (Xeon 1220@3.1Ггц, 4 ядра)

Пока три дня - полет нормальный. Буду смотреть.

Если всё пройдет нормально, то попробуем запуститься на xeon 1650@3.5 6 ядер. Думаю 6-8 тысяч потянет при 50-60% зугрузке что CPU, что карточки и схема выйдет более сбалансированной.

[NiTr0]

По-идее, если указать для accel не прибивать ppp интерфейсы (unit-cache=) то это поможет избежать проблемы.

Держать несколько сот туннелей? Не очень вариант.

 

Но - да, удаление стоит убрать (смысла с него я тоже не вижу, осталось по наследству).

[Dmitry76]

По-идее, если указать для accel не прибивать ppp интерфейсы (unit-cache=) то это поможет избежать проблемы.

Держать несколько сот туннелей? Не очень вариант.

 

Не вижу проблем в этом. Тем более, что сейчас все больше и больше юзеров используют роутеры, которые постоянно в онлайне пока включены и большого размаха в онлайне по суточным графикам нет.

Но дело хозяйское.

Изменено 14 августа, 2015 пользователем Dmitry76

[NiTr0]

Хм, поправил шейпер на насах, убрал удаление при убирании интерфейса - сегодня один нас покрашился, но немного по-другому...

[pashaumka]

Здравствуйте!

 

Ув. XEB..

 

очень надо для IPv6 именные пулы такие-же, как и для ipv4

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

[xeb]

Как можно указать ацелю передавать на RADIUS Auth Packet с атрибутом Framed-IP-Address для авторизации по IP ?

обязательно Framed-IP-Address нужно ?

 

commit ae822e2dc968a1d0e9985f4f864343c6684f95bc

[ipoe]

calling-sid=ip

[hsvt]

Как можно указать ацелю передавать на RADIUS Auth Packet с атрибутом Framed-IP-Address для авторизации по IP ?

обязательно Framed-IP-Address нужно ?

 

commit ae822e2dc968a1d0e9985f4f864343c6684f95bc

[ipoe]

calling-sid=ip

 

Ответ от биллинга:

 

теперь его нужно авторизовать по IP

если accel сможет при авторизации прислать в каком-то атрибуте, кроме User-Name, прислать IP, тогда логины менять не обязательно

например cisco присылает в такой же модели авторизации атрибут Framed-IP-Address

и мы юзера авторизуем не по логину, а по привязанному к УЗ адресу

можно и по маку

но это гемор

 

("в каком-то атрибуте") видимо можно и не только Framed-IP-Address, но если IP не приходит их радиус ищет его в User-Name. Сейчас проверим, большое спасибо.

Изменено 17 августа, 2015 пользователем hsvt