Cramac Опубликовано 3 февраля, 2011 · Жалоба совпадают, у меня еще версия с пптп...странно конечно но седня крутанулось, хотя ничего не менял... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lexab Опубликовано 4 февраля, 2011 · Жалоба Добрый день. Подскажите пожалуйста как общаться с cli консолью accel`ля через tcp ? В конфиге есть cli tcp 127.0.0.1 2001 на все комманды аналогчные telnet cli получаю show stat command unknown Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ates Опубликовано 4 февраля, 2011 · Жалоба Добрый день.Подскажите пожалуйста как общаться с cli консолью accel`ля через tcp ? В конфиге есть cli tcp 127.0.0.1 2001 на все комманды аналогчные telnet cli получаю show stat command unknown echo "show stat" | nc -q1 localhost 2001 uptime: 6.06:33:29 cpu: 0% mem(rss/virt): 1368/77792 kB core: mempool_allocated: 219206 mempool_available: 173370 thread_count: 4 thread_active: 1 context_count: 7 context_sleeping: 0 context_pending: 0 md_handler_count: 13 md_handler_pending: 0 timer_count: 6 timer_pending: 0 ppp: starting: 0 active: 2 finishing: 0 pptp: starting: 0 active: 2 radius: auth sent: 29 auth lost(total/5m/1m): 0/0/0 auth avg query time(5m/1m): 0/0 ms acct sent: 54 acct lost(total/5m/1m): 0/0/0 acct avg query time(5m/1m): 0/0 ms interim sent: 12824 interim lost(total/5m/1m): 0/0/0 interim avg query time(5m/1m): 4/4 ms Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lexab Опубликовано 4 февраля, 2011 · Жалоба Хм А чем отличается от echo "show sessions username,calling-sid,ip"|nc -tCq1 localhost 2000 Кстати не рушится ли в корку, особенно при частых обращениях с ошибками ? у меня бывает, но воспроизвести не могу... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 4 февраля, 2011 · Жалоба а ничего с win 98 не прояснилось? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aran Опубликовано 6 февраля, 2011 · Жалоба в конфиге в секции [pppoe] есть интересная опция mac-filter=filename,type Specifies mac-filter filename and type, type maybe allow or deny насколько я понимаю это для фильтрации/разрешения запросов с определённых маков? хотелось бы узнать формат этого файла и допустимы ли там какие-нить шаблоны Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 6 февраля, 2011 · Жалоба формат простой - в каждой строчке по маку, шаблонов нет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nickmas Опубликовано 6 февраля, 2011 (изменено) · Жалоба Заметил, что в cli не изменяется скорость командой: shaper change ppp0 1152:1152 Приходиться делать terminate if ppp0 Версии accel-ppp version 57ec76a3e15006c94e579662ce710bfd3f032331 и accel-ppp version 38077f9b9d9e86f4a7d2317b3697ea4370889999 Хотя в accel-pptp скорость менялась на лету через cli. Изменено 6 февраля, 2011 пользователем nickmas Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aran Опубликовано 7 февраля, 2011 (изменено) · Жалоба формат простой - в каждой строчке по маку, шаблонов нета означает ли, что если указана опция mac-filter=filename,allow то будут разрешены только маки, указанные в файле и наоборот в случае deny? и как оно себя будет вести в случае указания нескольких опций mac-filter? ;) ЗЫ: да, и ещё... deny можно рассматривать по разному... сервер будет игнорировать абсолютно все фреймы с указанных маков или всё же как-то будет отвечать например на PADI-пакеты? я почему пристаю... если в канальном сегменте несколько пппое концентраторов то в принципе клиенты цепляются случайным образом на любой из них. таким образом осуществляется балансировка нагрузки между ними, резервирование, балансировка внешних каналов etc. так вот если сервер, на котором клиент будет блокирован по мак-филтер всё же ответит на его ПАДИ фрейм, то у клиента будут проблемы подключения через концентраторы, на которых клиент не блокирован Изменено 7 февраля, 2011 пользователем aran Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 7 февраля, 2011 · Жалоба означает ли, что если указана опция mac-filter=filename,allow то будут разрешены только маки, указанные в файледа и как оно себя будет вести в случае указания нескольких опций mac-filter?считает только один из них сервер будет игнорировать абсолютно все фреймы с указанных маковда Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 7 февраля, 2011 · Жалоба Заметил, что в cli не изменяется скорость командой:shaper change ppp0 1152:1152 fixed Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aran Опубликовано 8 февраля, 2011 · Жалоба пппое сервер при завершении акселя не освобождает сетевой ифейс который слушает (ну который указан в опции interface в [pppoe]). Ну может в случае "чистого" изернета и освобождает - нет щас возможности проверить сплошные виланы, так вот в случае вилана точно не освобождает. Это приводит например к тому, что при перезагрузке сервера ядро навсегда зависает вот на этом: unregister_netdevice: waiting for vlan5 to become free. Usage count = 1 помогает только ресет... ну и подругим причинам это нехорошо. Проверено на версиях 1.3.4 и 38077f9b9d9e86f4a7d2317b3697ea4370889999 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aran Опубликовано 8 февраля, 2011 · Жалоба поднимаем пптп ppp0: 1d2f01c080edd5f9: ipcp_layer_started ppp0: 1d2f01c080edd5f9: pptp: ppp started ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 3352255a>] ppp0: 1d2f01c080edd5f9: recv [PPTP Echo-Reply <Identifier 3352255a>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=2 <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: recv [LCP EchoRep id=2 <magic 3e55d907>] ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 109cf92e>] ppp0: 1d2f01c080edd5f9: recv [PPTP Echo-Reply <Identifier 109cf92e>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=3 <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: recv [LCP EchoRep id=3 <magic 3e55d907>] ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier ded7263>] ppp0: 1d2f01c080edd5f9: recv [PPTP Echo-Reply <Identifier ded7263>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=4 <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: recv [LCP EchoRep id=4 <magic 3e55d907>] на этом месте выдёргиваем кабель ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 7fdcc233>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=5 <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 1befd79f>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=6 <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 41a7c4c9>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=7 <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 6b68079a>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=8 <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 4e6afb66>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=9 <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 25e45d32>] ppp0: 1d2f01c080edd5f9: send [LCP EchoReq id=a <magic 140e0f76>] ppp0: 1d2f01c080edd5f9: send [PPTP Echo-Request <Identifier 519b500d>] ppp0: 1d2f01c080edd5f9: lcp: no echo reply ppp0: 1d2f01c080edd5f9: ppp_terminate ppp0: 1d2f01c080edd5f9: lcp_layer_free ppp0: 1d2f01c080edd5f9: auth_layer_free ppp0: 1d2f01c080edd5f9: ccp_layer_free ppp0: 1d2f01c080edd5f9: ipcp_layer_free ppp0: 1d2f01c080edd5f9: ppp destablished ppp0: 1d2f01c080edd5f9: pptp: ppp finished ppp0: 1d2f01c080edd5f9: send [PPTP Call-Disconnect-Notify <Call-ID c0> <Result 3> <Error 0> <Cause 0>] ppp0: 1d2f01c080edd5f9: send [PPTP Stop-Ctrl-Conn-Request <Reason 0>] ppp0: 1d2f01c080edd5f9: pptp: disconnect ppp0: 1d2f01c080edd5f9: disconnected на этом месте кернел паник. постоянно. всегда accel-ppp version a2fe6bb78b048a0214a2c3e02e26105179ec4c3a Linux billing 2.6.37-6-server-billing #19 SMP Sun Feb 6 00:34:08 EET 2011 i686 i686 i386 GNU/Linux Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
marikoda Опубликовано 8 февраля, 2011 (изменено) · Жалоба Хотим попробовать внедрить accel ppp для pppoe, сейчас пользуемся mpd на freebsd Есть вопросы 1) Есть ли возможность отдавать радиусу счётчики трафика по ip зонам, как в mpd ? 2) Хотим шейперы на ppp интерфейсе к абоненту, скорость тоже хочется резать по зонам, возможно ли? Как запускаете шейпер? В if-up ? 3) Какой дистрибутив наиболее безглючно работает с accel ppp ? Или может быть какая-то определенная версия ядра нужна? Изменено 8 февраля, 2011 пользователем marikoda Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 8 февраля, 2011 · Жалоба 1) Есть ли возможность отдавать радиусу счётчики трафика по ip зонам, как в mpd ?нет 2) Хотим шейперы на ppp интерфейсе к абоненту, скорость тоже хочется резать по зонам, возможно ли? Как запускаете шейпер? В if-up ?по зонам можно, через ip-up 3) Какой дистрибутив наиболее безглючно работает с accel ppp ? Или может быть какая-то определенная версия ядра нужна?с пппое вроде особых проблем нет, так что подойдёт любой более менее свежий дистрибутив, вообще замечена наиболее стабильная связка 3.6.35 ядро и интеловские карты с интеловскими дровами, ядра 2.6.36-37 лучше не использовать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
aran Опубликовано 9 февраля, 2011 (изменено) · Жалоба пппое сервер при завершении акселя не освобождает сетевой ифейс который слушает (ну который указан в опции interface в [pppoe]). Ну может в случае "чистого" изернета и освобождает - нет щас возможности проверить сплошные виланы, так вот в случае вилана точно не освобождает. Это приводит например к тому, что при перезагрузке сервера ядро навсегда зависает вот на этом:unregister_netdevice: waiting for vlan5 to become free. Usage count = 1помогает только ресет... ну и подругим причинам это нехорошо. Проверено на версиях 1.3.4 и 38077f9b9d9e86f4a7d2317b3697ea4370889999 Удалось проверить на "чистом" изернете - там этой проблемы нет. Так что дело именно в виланах. К слову, у пппое сервера из пакета rp-pppoe, собранного с поддержкой кернел моуд, и запускаемого в этом режиме на вилане тоже этой проблемы нет. Так что можно ковырнуть евойные сырцы на тему виланов. Вощем надо шось робыты... А то отказываться от акселя только из-за этого не хотелось бы :( ЗЫ: что характерно... если я просто запускаю аксель пппое на вилане, но при этом никто не логинится, завершаю аксель, затем прибиваю вилан - он прибивается без проблем. но если после запуска акселя на вилане залогинится и и отлогинится, потом завершить аксель и попытаться прибить вилан - начинается вот эта ситуёвина: вышеупомянутое сообщение во все консоли и невозможность перезагрузки системы ЗЫ2: подобная тема (про unregister_netdevice: waiting for vlan...) не раз поднималась в инете... но то были косяки ведра которые уже пофикшены... здесь дело не в ведре потому как: 1. это начинается только после работы через аксель 2. после работы через pppoe-server от rp такого не происходит Изменено 9 февраля, 2011 пользователем aran Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lost Опубликовано 11 февраля, 2011 (изменено) · Жалоба внедряю bgbill в качестве пппое - accel из GITa, [2011-02-12 01:37:29]: msg: accel-ppp version 53f22bd8a8cd4a407b7eb9c9b034b215e2299e30 (в файле accel-ppp.log почему то на 10 метров в начале все в точках) в январе где то собирал. когда сервер стали вводить в рабочий режим, завели договора и логины - обнаружилось что один только логин нормально работает без разрыва. остальные договора с логинами начали рвать связь каждые 35 секунд ровно. написал разрабам bg, там молчат. пока молчат решил проверить подключением с винды через пппое с клиентского логина. что интересно - работает без разрывов. выходит что с модема кто коннектится - связь рвёт, если пппое поднят на винде (в случае моего теста в7) то не рвет. что это может быть? как объяснить поведение accel ? и он ли виноват? вот лог ассел: [2011-02-12 02:41:43]: error: ppp1: lcp:echo: magic number size mismatch [2011-02-12 02:41:43]: info: ppp1: send [RADIUS Accounting-Request id=2 <User-Name "in-2357927"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 1> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:1d:6a:37:5c:1e"> <Called-Station-Id "40:61:86:c4:85:b8"> <Acct-Status-Type Stop> <Acct-Authentic RADIUS> <Acct-Session-Id "06d1df4da157d630"> <Acct-Session-Time 31> <Acct-Input-Octets 54> <Acct-Output-Octets 58> <Acct-Input-Packets 3> <Acct-Output-Packets 4> <Acct-Input-Gigawords 0> <Acct-Output-Gigawords 0> <Acct-Delay-Time 0> <Framed-IP-Address 195.238.105.46> <Acct-Terminate-Cause User-Error>] [2011-02-12 02:41:43]: info: ppp1: recv [RADIUS Accounting-Response id=2] [2011-02-12 02:41:43]: info: ppp1: connect: ppp1 <--> pppoe(00:1d:6a:37:5c:1e) [2011-02-12 02:41:43]: info: ppp1: disconnected [2011-02-12 02:41:43]: info: ppp1: send [RADIUS Access-Request id=1 <User-Name "in-2357927"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 1> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:1d:6a:37:5c:1e"> <Called-Station-Id "40:61:86:c4:85:b8"> <User-Password >] [2011-02-12 02:41:43]: info: ppp1: recv [RADIUS Access-Accept id=1 <Acct-Interim-Interval 60> <Service-Type Framed-User> <Framed-Protocol PPP> <Traffic-Shape-in 256>] [2011-02-12 02:41:43]: info: ppp1: in-2357927: authentication successed [2011-02-12 02:41:43]: info: ppp1: send [RADIUS Accounting-Request id=1 <User-Name "in-2357927"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 1> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:1d:6a:37:5c:1e"> <Called-Station-Id "40:61:86:c4:85:b8"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "06d1df4da157d631"> <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> <Acct-Delay-Time 0> <Framed-IP-Address 195.238.105.47>] [2011-02-12 02:41:43]: info: ppp1: recv [RADIUS Accounting-Response id=1] и так по кругу каждые 35 сек. если я под этим логином войду с винды - всё будет ок. и что означает "lcp:echo: magic number size mismatch"? в каких случаях так выдает? p.s. обновил версию [2011-02-12 03:12:08]: msg: accel-pptp version 2fdf3586c13a72c36f9530084962e29d57dc0329 ничего не изменилось. пппое с модемов рвёт, с винды работает :( з.ы. что интересно, у сотрудника тоже в модеме пппое поднимается. его аккаунт работает без разрывов. [2011-02-12 03:12:24]: msg: accel-pptp version 2fdf3586c13a72c36f9530084962e29d57dc0329 [2011-02-12 03:13:39]: info: ppp0: connect: ppp0 <--> pppoe(00:02:cf:82:8a:38) [2011-02-12 03:13:39]: info: ppp0: send [RADIUS Access-Request id=1 <User-Name "alexandr"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:02:cf:82:8a:38"> <Called-Station-Id "40:61:86:c4:85:b8"> <User-Password >] [2011-02-12 03:13:39]: info: ppp0: recv [RADIUS Access-Accept id=1 <Acct-Interim-Interval 60> <Service-Type Framed-User> <Framed-Protocol PPP> <Traffic-Shape-in 256>] [2011-02-12 03:13:39]: info: ppp0: alexandr: authentication successed [2011-02-12 03:13:39]: info: ppp0: send [RADIUS Accounting-Request id=1 <User-Name "alexandr"> <NAS-Identifier "accel-ppp"> <NAS-IP-Address 10.10.100.12> <NAS-Port 0> <NAS-Port-Type Virtual> <Service-Type Framed-User> <Framed-Protocol PPP> <Calling-Station-Id "00:02:cf:82:8a:38"> <Called-Station-Id "40:61:86:c4:85:b8"> <Acct-Status-Type Start> <Acct-Authentic RADIUS> <Acct-Session-Id "06d1df4da157d5c1"> <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> <Acct-Delay-Time 0> <Framed-IP-Address 195.238.105.32>] [2011-02-12 03:13:39]: info: ppp0: recv [RADIUS Accounting-Response id=1] а у остальных рвёт :( Изменено 11 февраля, 2011 пользователем lost Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 11 февраля, 2011 · Жалоба [2011-02-12 02:41:43]: error: ppp1: lcp:echo: magic number size mismatchи что все клиенты с таким сообщением обрываются ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lexab Опубликовано 12 февраля, 2011 · Жалоба C magic это бсд- у нее какойто свой путь расчета у клиента с роутером m0n0wall вылечили добавлением в конфиг mpd set link disable check-magic похожая проблема есть с клиентами MacOs Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lost Опубликовано 12 февраля, 2011 (изменено) · Жалоба и что все клиенты с таким сообщением обрываются ?да, все. но насколько все - не знаю. днем тестировать нельзя, а то клиенты приедут ногами колотить за отсутствие тырнетов. пытался ночью перевести когда в онлайне остается 4-5 клиентских модемов (у нас фирмы и организации). примерно за час тщетной попытки перевести: [root@bgbill accel-ppp]# grep -a magic accel-ppp.log |wc -l 399 C magic это бсд- у нее какойто свой путь расчетау меня линукс fc14 [root@bgbill accel-ppp]# uname -a Linux bgbill.infonet.uz 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux я ещё что думаю, может это происходит на уровне модем-аццел? раз с винды пппое нормально отрабатывает.. ну скажем модем криво передает пакеты на пппое сервер. (хотя нет у модемов особеннойтсей в настройке пппое - лог и пасс да и несколько параметров всяких) сегодня ночью теста ради попробую на rp-pppoe стандартный натравить юзеров. посмотрим как поведут себя в этом случае коннекты. как ещё можно подебажить, какие логи показать? Изменено 12 февраля, 2011 пользователем lost Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 12 февраля, 2011 · Жалоба днем тестировать нельзя, а то клиенты приедут ногами колотить за отсутствие тырнетов Если это поднимается в качестве 2-го сервера - то можно, т.к. проблемы будут ловиться только у вновь коннектящихся - а их не так и много. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lost Опубликовано 12 февраля, 2011 · Жалоба это выглядит странно, но у меня в сети два пппое сервера - rp-pppoe через icradius, и accel через bgbill так вот вновь подключаемые ниразу не попали на accel. если rp-ppoe потушить то все уже бегут на аццел. хотя оба пппое сервера в одной сети только на разных серверах. еще есть третий на виртуалбоксе в офисе, но их разделяет linux рутер в качестве рутера, но туда пакеты не релеятся даже если pppoe-relay включаю. но это неважно. мне бы баг отловить и исправить... xeb что то призадумался :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lexab Опубликовано 12 февраля, 2011 · Жалоба у меня линукс fc14 [root@bgbill accel-ppp]# uname -a Linux bgbill.infonet.uz 2.6.35.10-74.fc14.x86_64 #1 SMP Thu Dec 23 16:04:50 UTC 2010 x86_64 x86_64 x86_64 GNU/Linux Я говорил про клиентов. Внутри некоторых роутеров тоже можно встретить МПД Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lost Опубликовано 12 февраля, 2011 · Жалоба Я говорил про клиентов. Внутри некоторых роутеров тоже можно встретить МПДа ясно, речь идёт о модемах-рутерах?если кривой мпд скажем в модеме, то может аццел както можно приспособить к кривому ппп клиенту? может там параметры покрутить в конфиге или патч наложить... хотя если бы были баги с мпд как вы сказали, то наверное я бы был не первый с такой траблой... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lost Опубликовано 12 февраля, 2011 · Жалоба ну как и предполагал. натравил rp-pppoe на bgbill, юзера работают без дисконнектов. выходит аццел имеет какой то необъяснимый баг? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...