[kayot]

В etc/rc.d/rc.local данную команду добавить.

[s.lobanov]

В некоторых дистрибутивах предусмотрено что-то типа ETHTOOL_OPTIONS в конфигурационном файле интерфейса.

[morfair]

Скажите, что делать, некоторые роутеры не подключаются, User-Error. Вроде бы как это DIR-300 с оранжевой прошивкой.

[replicant]

Скажите, что делать, некоторые роутеры не подключаются, User-Error. Вроде бы как это DIR-300 с оранжевой прошивкой.

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

[KSS_DIGGER]

…посмотрим что это за оранжевая прошивка…

Все DIR до модификации NRU

[replicant]

Все DIR до модификации NRU

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

 

Хотя это мелочи по сравнению с тем как вообще описана проблема.

[purecopper]

Тестируем accel-ppp ipoe с freeradius. Вылезла проблема - неправильно отдается маска клиенту:

Конфиг accel-ppp:

 

 

[ipoe]

mode=L2

shared=0

ifcfg=0

start=dhcpv4

verbose=5

lease-time=600

max-lease-time=3600

interface=eth2.100

attr-dhcp-client-ip=DHCP-Client-IP-Address

attr-dhcp-router-ip=DHCP-Router-IP-Address

attr-dhcp-mask=DHCP-Mask

username=ifname

 

 

 

radtest eth2.100 '' 127.0.0.1 1812 testing123

 

 

Sending Access-Request of id 16 to 127.0.0.1 port 1812

User-Name = "eth2.100"

User-Password = ""

NAS-IP-Address = 127.0.1.1

NAS-Port = 1812

rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=16, length=38

DHCP-Client-IP-Address = 192.168.200.168

DHCP-Mask = 255.255.252.0

DHCP-Router-IP-Address = 192.168.200.1

 

 

 

accel-ppp.log

 

 

info: eth2.100: send [DHCPv4 Ack xid=93b89d09 ciaddr=192.168.200.168 yiaddr=192.168.200.168 chaddr=00:18:f3:3f:37:cd <Message-Type Ack> <Server-ID 192.168.200.1> <Lease-Time 600> <Router 192.168.200.1> <Subnet 255.255.255.255> <DNS 192.168.200.1>]

 

 

[morfair]

Скажите, что делать, некоторые роутеры не подключаются, User-Error. Вроде бы как это DIR-300 с оранжевой прошивкой.

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

 

А что тут подробнее написать? Пользователь подключается, адрес выдается, сессия длится пару секунд и соединение обрывается с Acct-Terminate-Cause User-Error. При помощи тех. поддержки удалось выяснить, что это "D-Link с оранжевой прошивкой". напрямую с компьютера все работает...

 

[2013-03-05 10:13:53]:  info: ppp158: send [RADIUS(1) Access-Request id=1 <User-Name "login"> <NAS-Identifier "nas4"> <NAS-IP-Address xx.xx.xx.xx> <NAS-Port 158> <NAS-Port-Type Virtual> <Tunnel-Type PPTP> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.171.92"> <Called-Station-Id "yy.yy.yy.yy"><Microsoft MS-CHAP-Challenge ><Microsoft MS-CHAP2-Response >]
[2013-03-05 10:13:53]:  info: ppp158: 171092: authentication succeeded
[2013-03-05 10:14:03]:  info: ppp158: send [RADIUS(1) Accounting-Request id=1 <User-Name "login"> <NAS-Identifier "nas4"> <NAS-IP-Address xx.xx.xx.xx> <NAS-Port 158> <NAS-Port-Type Virtual> <Tunnel-Type PPTP> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.171.92"> <Called-Station-Id "yy.yy.yy.yy"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "07101cdcd74e7bc9"> <Acct-Session-Time 0> <Acct-Input-Octets 0> <Acct-Output-Octets 0> <Acct-Input-Packets 0> <Acct-Output-Packets 0> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address X.X.X.X>]
[2013-03-05 10:14:08]:  info: ppp158: send [RADIUS(1) Accounting-Request id=1 <User-Name "login"> <NAS-Identifier "nas4"> <NAS-IP-Address xx.xx.xx.xx> <NAS-Port 158> <NAS-Port-Type Virtual> <Tunnel-Type PPTP> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "10.0.171.92"> <Called-Station-Id "yy.yy.yy.yy"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "07101cdcd74e7bc9"> <Acct-Session-Time 15> <Acct-Input-Octets 444> <Acct-Output-Octets 124> <Acct-Input-Packets 15> <Acct-Output-Packets 10> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Framed-IP-Address X.X.X.X> <Acct-Terminate-Cause User-Error>]

 

На стандартный pptpd коннектятся без проблем.

Изменено 5 марта, 2013 пользователем morfair

[purecopper]

А конфиг accel-ppp покажете?

[Cramac]

а я думал у меня одного такое, периодически, роутер заглючивает и делает 20-50 соединений подряд по 2-3 сек

[replicant]

а я думал у меня одного такое, периодически, роутер заглючивает и делает 20-50 соединений подряд по 2-3 сек

Я таких в iptables в минутный отстойник кидаю, чтобы остыли в "бане". Потом снова здорово и снова в отстойник. И так пока в саппорт не стукнутся. Там уже начинают разбор полетов.

 

Причем не только D-Link, но и какие-то Asus вроде RT-G32 были "больные на всю голову" таким симптомом.

[Cramac]

replicant

а если их банить, они вообще не повиснут (роутеры)? т.к. у нас кто оплатить не успел, роутер не включается в день оплаты (т.е. на 1 отрубило, 2 оплатили а коннект не поднимается), заметили только на длинках. С самих роутеров логи не снимали, а accel говорит что клиент сам разорвал.

[kayot]

Поймал сегодня хитрый баг для ipoe.

Клиент подключен по L2(vlan per user, vlan=2021). Все работает, клиент получает ip, стартует сессия, строится маршрут.

Берем еще одну машину, и перетыкаем сетевой кабель. И тут обычно вылезает глюк. Accel для новой машины(мак сменился) запускает новую сессию, но старая остается, и может завершаться как до старта новой, так и после. Если сессия для нового мака стартует раньше чем убивается старая - при прибивании старой удаляется и маршрут на клиента.

Лог такой ситуации:

[2013-03-05 18:38:21]:  info: eth1.2021: send [RADIUS(1) Accounting-Request id=2 <User-Name "2021">
[2013-03-05 18:38:21]:  info: eth1.2021: send [DHCPv4 relay Request xid=9947cd72
[2013-03-05 18:38:21]:  info: eth1.2021: recv [DHCPv4 relay Ack xid=9947cd72
[2013-03-05 18:38:21]: error: libnetlink: RTNETLINK answers: File exists
[2013-03-05 18:38:21]:  warn: eth1.2021: ipoe: failed to add route to interface 'eth1.2021'
[2013-03-05 18:38:21]:  info: eth1.2021: send [RADIUS(1) Accounting-Request id=1 <User-Name "2021">
[2013-03-05 18:38:21]:  info: eth1.2021: recv [RADIUS(1) Accounting-Response id=2]
[2013-03-05 18:38:21]:  info: eth1.2021: recv [RADIUS(1) Accounting-Response id=1]
[2013-03-05 18:38:21]: debug: eth1.2021: ipoe: session started
[2013-03-05 18:38:21]: debug: eth1.2021: ipoe: session finished
[2013-03-05 18:38:21]:  info: eth1.2021: send [DHCPv4 Ack xid=9947cd72 yiaddr=10.12.94.21 
[2013-03-05 18:38:21]:  info: eth1.2021: send [DHCPv4 relay Release xid=f7a80c3a ciaddr=10.12.94.21 
[2013-03-05 18:38:51]:  info: eth1.2021: recv [DHCPv4 Request xid=9947cd72 ciaddr=10.12.94.21 
[2013-03-05 18:38:51]:  info: eth1.2021: send [DHCPv4 relay Request xid=9947cd72 ciaddr=10.12.94.21

accel-ppp# show sessions
 ifname   | username |    calling-sid    |     ip      | type | comp | state  |  uptime
-----------+----------+-------------------+-------------+------+------+--------+----------
eth1.2021 | 2021     | 90:f6:52:bc:05:51 | 10.12.94.21 | ipoe |      | active | 01:11:55

[root@dl380 accel-ppp]# ip r show
...маршрута нет...

Клиент в таком состоянии может находиться бесконечно долго, в логе выше - висит уже час. Лиза обновляется, сессия висит, трафик не бегает. Помогает принудительное обновление ip на клиенте, или выдергивание шнурка на время, достаточное для отмирания сессии.

 

По идее нужно или вообще сессии не дергать - клиент ведь тот же, какая разница какой там мак. Или отслеживать такие ситуации и принудительно завершать старую сессию при старте новой. Второй вариант логичнее.

Изменено 5 марта, 2013 пользователем kayot

[Abram]

kayot,

У меня похожая проблема на lISG. Лечу кроном раз в минуту. Костыль, конечно же.

[kayot]

Abram

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

[Abram]

kayot,

Конкретно у Вас это баг биллинга ;).

[kayot]

Abram

А какое отношение вообще биллинг имеет к ipoe-BRASу? Биллинг обо всех этих сессиях и маках знать не знает.

[s.lobanov]

kayot

А у вас биллинг не используется? Речь идёт о том, что новая сессия должна отбиваться биллингом(как правило, ставят лимит одна сессия на учётную запись)

[kayot]

Можно конечно и на отлуп настроить, но как-то это с точки зрения ipoe нелогично.

Я специально радиусу добавил заглушку, всегда возвращающую положительную авторизацию. А дальше уже дело dhcp-сервера, нормальному клиенту выдастся белый ip, должнику серый из одного блока(с редиректом на дай денег), неклиенту - серый из другого(редирект на авторизацию). Почему биллинг должн заботиться перетыкальщиками не ясно :)

Изменено 6 марта, 2013 пользователем kayot

[s.lobanov]

kayot

Почему вы считаете что IPoE это что-то особенное и у него должны быть всё по другому по сравнению с PPPoE? Разница лишь в отсутсвии дополнильной инкапсуляции, всё остальное(в нормальных сетях) одинаково - а именно наличие сессии.

Проще говоря, перетыкание(смена мак-адреса) должна приводить к зависанию сессии на небольшой интервал времени(1-2 минуты). В момент "зависания" вторая сессия не должна создаваться(если только абонент не платит за мультилогин)

Выделенный DHCP-сервер вообще ненужная сущность в IPoE. DHCP-сервером должны быть BRAS, раздавая IP из пула(ов) или из радиус-аттрибута.

[kayot]

s.lobanov

Ну это уже больше вопрос философии. Сейчас как раз таки PPPoE со своими сесиями, хотел при смене типа доступа избавиться от одной головной боли :)

Для протухания сессии за 1-2 минуты lease time должен выдаваться на те же 2 минуты максимум, правильно?

Изменено 6 марта, 2013 пользователем kayot

[s.lobanov]

Для протухания сессии за 1-2 минуты lease time должен выдаваться на те же 2 минуты максимум, правильно?

 

Да, нужен маленький lease time для этого. Есть ещё второй способ - arp keepalive(юникастом), но его accel-ppp не умеет

Есть даже третий способ - icmp keepalive, но в IRL им пользоватья нельзя, ибо фаерволы повсюду.

[kayot]

С другой стороны - accel все же полноценный BRAS все-в-одном, те же сессии у него свои, никак не связанные с радиусом и внешними биллингами. В отличии от pppd, который просто тоннель поднимает..

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

Изменено 7 марта, 2013 пользователем kayot

[zarguni]

Тестирую ipoe. Возникло два вопроса.

1. Пробую mode=L3 и start=up, но что-то сессия не поднимается, в логах:

[2013-03-09 01:54:07]: info: eth2: send [RADIUS(1) Access-Request id=1 <User-Name "10.0.0.100"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 127.0.0.1> <NAS-Port-Type Ethernet> <Calling-Station-Id "10.0.0.100"> <Called-Station-Id "10.0.0.255"> <User-Password >]

[2013-03-09 01:54:07]: info: eth2: recv [RADIUS(1) Access-Accept id=1 <Session-Timeout 79553>]

[2013-03-09 01:54:07]: error: eth2: can't determine Server-ID

Конфиг:

 

 

[modules]

log_file

ipoe

radius

sigchld

shaper

net-snmp

logwtmp

 

[core]

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

thread-count=4

 

[ipoe]

verbose=5

username=ifname

#unit-cache=1000

shared=1

ifcfg=0

mode=L3

start=up

local-net=10.0.0.0/24

interface=eth2

l4-redirect-table=4

l4-redirect-on-reject=300

 

[client-ip-range]

10.0.0.0/8

 

 

 

2. Как убивается зависшая сессия, например когда пользователь выключил компьютер, при старте сессии по неклассифицированному пакету. Не ждать же пока сессия по Session-Timeout отвалится (или таки ждать)?

Изменено 9 марта, 2013 пользователем zarguni

[replicant]

Имеется лабораторный сервер, на котором есть accel-ppp 1.7.3. Никаких radius'ов, баз данных и прочего нет. Голый Linux и голый accel.

Авторизация по логину-паролю из chap-secret. Создается туннель ppp# и поднимается ip адрес, согласно chap опять же.

 

Возникла задача в определенный момент времени инициировать разрыв соединения, т.е. прибить ppp# туннель и удалить соответствующий dev, чтобы в ifconfig его не было.

 

ifconfig ppp# down не работает ... туннель остается жив.

 

Вопрос: Как именно (просто, эффективно и легко) можно убить нужный ppp# интерфейс так, чтобы у клиента порвалось соединение?