s.lobanov Опубликовано 3 ноября, 2016 · Жалоба 3.2 говно же. будет у вас 3-4 тысячи ppp-интерфейсов и accel начнёт загибаться при создании/удалении ppp-интерфейсов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 3 ноября, 2016 · Жалоба больше интересует 3.19+ - на них грабли начались... ни у кого в продакшне нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 3 ноября, 2016 · Жалоба 4.8.x более менее застабилизировали, но с sfq могут быть подводные камни. До 15к pppoe сессий, пашет, accel кстати перестал изредка виснуть на этом ядре (раньше бывало, не мог поймать - почему). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 3 ноября, 2016 · Жалоба ок, значит на досуге проведу экскремент... а что за подводные камни с sfq? //оффтоп, мож кому полезно будет: тут на днях сервачок (пптп+немного ната+роутинг, с FV) подкрашиваться начал, возможно - от флуда, на 3.10.101, с i82576 (igb 5.3.3.2), один раз он просто дуплил с потерями, зашел - увидел ругань на ошибки выделения памяти; похоже, были виноваты слишком накрученные буфера сетевки, т.к. поменяли все железо кроме сетевки - не особо помогло, подрезал с 4096 на 1024 - вроде попустило. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 4 ноября, 2016 · Жалоба ок, значит на досуге проведу экскремент... а что за подводные камни с sfq? В панику ядро оседало при создании-удалении интерфейсов, причину отловить так и не удалось, пришлось вынести sfq отовсюду. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 4 ноября, 2016 · Жалоба хм, по ifdown не было удаления qdisc? у меня такое наблюдалось вроде начиная с 3.14 или 3.18, причем после паники тупо вставали колом sysctl к сетевой подсистеме, сам тазик не крашился. убрал из шейпера деинициализацию по ifdown - вроде попустило, остались в основном грабли с самими pppoe... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 4 ноября, 2016 · Жалоба у меня вообще ifup/ifdown нету, стоит отдельный демон, который следит за новыми интерфейсами и добавляет шейперы, хоть и с задержкой, но зато нет проблем когда несколько тысяч юзеров логинятся в течении минуты. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pashaumka Опубликовано 4 ноября, 2016 · Жалоба у меня вообще ifup/ifdown нету, стоит отдельный демон, который следит за новыми интерфейсами и добавляет шейперы, хоть и с задержкой, но зато нет проблем когда несколько тысяч юзеров логинятся в течении минуты. а что за демон-то и какие скрипті? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 4 ноября, 2016 · Жалоба написал на C, специфический для моего биллинга. Старая версия смотрит на время создания файлов /var/run/radacct*, новая смотрит netlink, по ним определяет, что новый юзер залогинился, в биллинге сделал хак - чтобы в /var/run/radacct.pppx откладывался username, демон смотрит юзернейм в radacct (хотя можно и с биллинга по номеру порта и nas ip вытянуть, но зачем грузить его?), по юзернейму с биллинга вытягивает данные по юзеру в нормальном виде (т.к. в радиусе все таки передавать какие-то нестандартные правила - сплошной костылинг) и передает в очередь новые правила на шейперный процесс. Шейперный процесс я часть сделал на libmnl, а часть все таки iproute2/tc (с libmnl лень было разбираться в формате netlink сообщений, как формировать правила для tc filter и т.д.) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 ноября, 2016 · Жалоба Лучше бы попросила xeb-а дополить встроенный "shaper" под набор правил, чем бесконечно плодить уродские костыли с ifup/down и ещё хуже с самодельными демонами на C, отслеживающими ppp-интерфейсы и навешивающие на них правила полисинга/шейпинга я как-то попрсил sfq сделать в accel-pppd. xeb сделал и ушёл таким образом от ifup/down Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 4 ноября, 2016 · Жалоба У меня демон кроме этого делает кучу других задач - в т.ч. динамический шейпинг в зависимости от загрузки магистральных каналов(CoA усерется обновлять с такой скоростью), fair use policy(траффик считается прямо в демоне, снимается через netlink каждые 30 секунд, чтобы не загружать биллинг промежуточными значениями), статистика по каждому классу траффика в биллинге близко к реалтайму (через redis), детект дубликатов юзеров c учетом долбанных тплинков (они держат две сессии и перебороть это невозможно), и т.д. Я сейчас даже не вспомню все. Так что про xeb-а не к месту. Не стоит натягивать на accel задачи ему несвойственные. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dmitry76 Опубликовано 9 ноября, 2016 · Жалоба А скажите, какие-то подвижки в реализации session backup есть? Вроде, и исходники есть (accel-pppd/backup), но кроме упоминания, что "soft - restart daemon softly, e.g. keep existing connections if session backup is enabled (default)" нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sanchezz Опубликовано 9 ноября, 2016 · Жалоба Может кто сталкивался с проблемой задержки в 3 секунды при LCP согласовании? CCP пробовал отключить Разные версии accel собирал так же безрезультатно. [2016-11-09 18:00:06.419] recv [PPPoE PADT f4:6d:04:f8:5c:c1 => 28:92:4a:37:09:bb sid=0040] [2016-11-09 18:00:09.433] recv [PPPoE PADI f4:6d:04:f8:5c:c1 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 10000000000000001e000000>] [2016-11-09 18:00:09.433] send [PPPoE PADO 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0000 <AC-Name accel-ppp> <Service-Name > <AC-Cookie 23f4607a2e95267fff6498bd441b1a7e1fd5668357cffb26> <Host-Uniq 10000000000000001e000000>] [2016-11-09 18:00:09.433] recv [PPPoE PADR f4:6d:04:f8:5c:c1 => 28:92:4a:37:09:bb sid=0000 <Service-Name > <Host-Uniq 10000000000000001f000000> <AC-Cookie 23f4607a2e95267fff6498bd441b1a7e1fd5668357cffb26>] [2016-11-09 18:00:09.433] send [PPPoE PADS 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0001 <AC-Name accel-ppp> <Service-Name > <Host-Uniq 10000000000000001f000000>] [2016-11-09 18:00:09.434] ppp0: : connect: ppp0 <--> pppoe(f4:6d:04:f8:5c:c1) [2016-11-09 18:00:09.434] ppp0: a4c8ec8f7d90bf63: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567>] [2016-11-09 18:00:09.444] ppp0: a4c8ec8f7d90bf63: recv [LCP ConfReq id=0 <mru 1480> <magic 1c317f65> <pcomp> <accomp> < d 3 6 >] [2016-11-09 18:00:09.444] ppp0: a4c8ec8f7d90bf63: send [LCP ConfRej id=0 <pcomp> <accomp> < d 3 6 >] [2016-11-09 18:00:09.445] ppp0: a4c8ec8f7d90bf63: recv [LCP ConfReq id=1 <mru 1480> <magic 1c317f65>] [2016-11-09 18:00:09.445] ppp0: a4c8ec8f7d90bf63: send [LCP ConfAck id=1 ] [2016-11-09 18:00:12.434] ppp0: a4c8ec8f7d90bf63: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567>] [2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <mru 1400> <magic 6b8b4567>] [2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: send [MSCHAP-v2 Challenge id=1 <beeffb6a1bac5849ef31da702026cb5b>] [2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: recv [LCP Ident id=2 <MSRASV5.20>] [2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: recv [LCP Ident id=3 <MSRAS-0-ASUS1600-PC>] [2016-11-09 18:00:12.435] ppp0: a4c8ec8f7d90bf63: recv [LCP Ident id=4 <▒▒rވL▒▒bV▒▒>] [2016-11-09 18:00:12.438] ppp0: a4c8ec8f7d90bf63: recv [MSCHAP-v2 Response id=1 <a7b29c2cfdb324e5b40ab54ff9cff3a>, <983ac88ec0281ebd55f7f1d27a1318c415b2f72015be>, F=0, name=test] [2016-11-09 18:00:12.438] ppp0: a4c8ec8f7d90bf63: send [MSCHAP-v2 Success id=1 "S=54394B05B22BA850462B2287EED24A7D6E854FD2 M=Authentication succeeded"] [2016-11-09 18:00:12.438] ppp0: a4c8ec8f7d90bf63: send [iPCP ConfReq id=1 <addr 192.168.100.1>] [2016-11-09 18:00:12.438] ppp0: a4c8ec8f7d90bf63: test: authentication succeeded [2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: recv [CCP ConfReq id=5 <mppe -H -M -S -L -D -C>] [2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: send [CCP ConfReq id=1 <mppe -H -M -S -L -D -C>] [2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: send [CCP ConfAck id=5] [2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: recv [iPCP ConfReq id=6 <addr 0.0.0.0> <dns1 0.0.0.0> <wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>] [2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: send [iPCP ConfNak id=6 <addr 10.0.10.2>] [2016-11-09 18:00:12.440] ppp0: a4c8ec8f7d90bf63: recv [iPCP ConfAck id=1 <addr 192.168.100.1>] [2016-11-09 18:00:12.441] ppp0: a4c8ec8f7d90bf63: recv [CCP ConfAck id=1 <mppe -H -M -S -L -D -C>] [2016-11-09 18:00:12.441] ppp0: a4c8ec8f7d90bf63: recv [iPCP ConfReq id=7 <addr 10.0.10.2> <dns1 0.0.0.0> <wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>] [2016-11-09 18:00:12.441] ppp0: a4c8ec8f7d90bf63: send [iPCP ConfAck id=7] [2016-11-09 18:00:12.441] ppp0: a4c8ec8f7d90bf63: pppd_compat: ip-up started (pid 21139) [2016-11-09 18:00:12.538] ppp0: a4c8ec8f7d90bf63: pppd_compat: ip-up finished (0) [2016-11-09 18:00:22.320] ppp0: a4c8ec8f7d90bf63: recv [LCP TermReq id=8] [2016-11-09 18:00:22.320] ppp0: a4c8ec8f7d90bf63: send [LCP TermAck id=8] [2016-11-09 18:00:22.347] recv [PPPoE PADT f4:6d:04:f8:5c:c1 => 28:92:4a:37:09:bb sid=0001] [2016-11-09 18:00:22.348] ppp0: a4c8ec8f7d90bf63: pppd_compat: ip-down started (pid 21146) [2016-11-09 18:00:22.352] ppp0: a4c8ec8f7d90bf63: pppd_compat: ip-down finished (0) [2016-11-09 18:00:22.352] send [PPPoE PADT 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0001 <AC-Name accel-ppp> <Service-Name >] [2016-11-09 18:00:22.352] ppp0: a4c8ec8f7d90bf63: disconnected [2016-11-09 18:00:24.565] recv [PPPoE PADI f4:6d:04:f8:5c:c1 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name > <Host-Uniq 110000000000000020000000>] [2016-11-09 18:00:24.565] send [PPPoE PADO 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0000 <AC-Name accel-ppp> <Service-Name > <AC-Cookie 23f4607a2e95267fff6498bd441b1a7e805b7e5f9c9c648e> <Host-Uniq 110000000000000020000000>] [2016-11-09 18:00:24.565] recv [PPPoE PADR f4:6d:04:f8:5c:c1 => 28:92:4a:37:09:bb sid=0000 <Service-Name > <Host-Uniq 110000000000000021000000> <AC-Cookie 23f4607a2e95267fff6498bd441b1a7e805b7e5f9c9c648e>] [2016-11-09 18:00:24.565] send [PPPoE PADS 28:92:4a:37:09:bb => f4:6d:04:f8:5c:c1 sid=0040 <AC-Name accel-ppp> <Service-Name > <Host-Uniq 110000000000000021000000>] [2016-11-09 18:00:24.565] ppp0: : connect: ppp0 <--> pppoe(f4:6d:04:f8:5c:c1) [2016-11-09 18:00:24.566] ppp0: a4c8ec8f7d90bf64: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 327b23c6>] [2016-11-09 18:00:24.583] ppp0: a4c8ec8f7d90bf64: recv [LCP ConfReq id=0 <mru 1480> <magic 5d3842fa> <pcomp> <accomp> < d 3 6 >] [2016-11-09 18:00:24.583] ppp0: a4c8ec8f7d90bf64: send [LCP ConfRej id=0 <pcomp> <accomp> < d 3 6 >] [2016-11-09 18:00:24.584] ppp0: a4c8ec8f7d90bf64: recv [LCP ConfReq id=1 <mru 1480> <magic 5d3842fa>] [2016-11-09 18:00:24.584] ppp0: a4c8ec8f7d90bf64: send [LCP ConfAck id=1 ] [2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1400> <magic 327b23c6>] [2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: recv [LCP ConfAck id=1 <auth MSCHAP-v2> <mru 1400> <magic 327b23c6>] [2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: send [MSCHAP-v2 Challenge id=1 <f3278e9f159a89a832b8bf2cb6afbdca>] [2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: recv [LCP Ident id=2 <MSRASV5.20>] [2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: recv [LCP Ident id=3 <MSRAS-0-ASUS1600-PC>] [2016-11-09 18:00:27.566] ppp0: a4c8ec8f7d90bf64: recv [LCP Ident id=4 <▒KM▒/<B▒̾▒▒▒e▒>] [2016-11-09 18:00:27.570] ppp0: a4c8ec8f7d90bf64: recv [MSCHAP-v2 Response id=1 <889cbd7b42686988abd88fa0ffc1f9>, <c8e0e02448aa142866d78a498bf47e374f1d618c62c5af3>, F=0, name=test] [2016-11-09 18:00:27.570] ppp0: a4c8ec8f7d90bf64: send [MSCHAP-v2 Success id=1 "S=2AF52F2ED52836F3A2B50F6E078D7336E126BD92 M=Authentication succeeded"] [2016-11-09 18:00:27.570] ppp0: a4c8ec8f7d90bf64: send [iPCP ConfReq id=1 <addr 192.168.100.1>] [2016-11-09 18:00:27.570] ppp0: a4c8ec8f7d90bf64: test: authentication succeeded [2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: recv [CCP ConfReq id=5 <mppe -H -M -S -L -D -C>] [2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: send [CCP ConfReq id=1 <mppe -H -M -S -L -D -C>] [2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: send [CCP ConfAck id=5] [2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: recv [iPCP ConfReq id=6 <addr 0.0.0.0> <dns1 0.0.0.0> <wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>] [2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: send [iPCP ConfNak id=6 <addr 10.0.10.2>] [2016-11-09 18:00:27.571] ppp0: a4c8ec8f7d90bf64: recv [iPCP ConfAck id=1 <addr 192.168.100.1>] [2016-11-09 18:00:27.573] ppp0: a4c8ec8f7d90bf64: recv [CCP ConfAck id=1 <mppe -H -M -S -L -D -C>] [2016-11-09 18:00:27.573] ppp0: a4c8ec8f7d90bf64: recv [iPCP ConfReq id=7 <addr 10.0.10.2> <dns1 0.0.0.0> <wins1 0.0.0.0> <dns2 0.0.0.0> <wins2 0.0.0.0>] [2016-11-09 18:00:27.573] ppp0: a4c8ec8f7d90bf64: send [iPCP ConfAck id=7] [2016-11-09 18:00:27.574] ppp0: a4c8ec8f7d90bf64: pppd_compat: ip-up started (pid 21152) [2016-11-09 18:00:27.671] ppp0: a4c8ec8f7d90bf64: pppd_compat: ip-up finished (0) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nsa2006 Опубликовано 9 ноября, 2016 (изменено) · Жалоба 3.2 говно же. будет у вас 3-4 тысячи ppp-интерфейсов и accel начнёт загибаться при создании/удалении ppp-интерфейсов Интерфейсов > 3k а точнее 3.37K MAX dpkg -l "*image*" | grep ii ii linux-image-3.2.0-4-amd64 3.2.51-1 amd64 Linux 3.2 for 64-bit PCs ii linux-image-amd64 3.2+46 amd64 Linux for 64-bit PCs (meta-package) uname -r 3.2.0-4-amd64 Ничего не ложится. Использую unit-cache Изменено 9 ноября, 2016 пользователем nsa2006 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2016 · Жалоба nsa2006 c unit-кешем понятно... просто поначалу этот unit cache как-то странно работал. если сейчас он работает ок, то хорошо Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 10 ноября, 2016 · Жалоба Может кто сталкивался с проблемой задержки в 3 секунды при LCP согласовании? CCP пробовал отключить Разные версии accel собирал так же безрезультатно. Из комита https://sourceforge.net/p/accel-ppp/code/ci/d2cb39985cd33f5678cad3e68b69cca51894bd58/ ppp: discard packets with invalid id before passing it to fsm ppp: default fsm timeout increased to 3 sec. ppp: accept LCP TermReq/TermAck packets in terminating phase Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nsa2006 Опубликовано 10 ноября, 2016 (изменено) · Жалоба Может кто сталкивался с проблемой задержки в 3 секунды при LCP согласовании? Есть такое дело, где то я читал что можно timeout где то в конфигурации подсунуть минимальный 1 сек, не идеал конечно но всё же быстрее. Вот нашёл! https://accel-ppp.org/forum/viewtopic.php?t=639 На тиках довольно быстрее подключает конечно, вроде как меньше секунды, но у тиков другие болезни. И ревущий пингвин, подключается быстро. Изменено 10 ноября, 2016 пользователем nsa2006 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sanchezz Опубликовано 12 ноября, 2016 (изменено) · Жалоба проблема тут оказалось даже не в таймаутах, а в частых переотправках LCP пакетов. [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] я изменил в акселе количество попыток на большее, но не нравится сама ситуация с будто битыми пакетами GRE. вывод логов я тоже изменил [2016-11-12 18:34:33.801] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>][2016-11-12 18:34:33.802] eth3: 5fb5a404ff288410: fsm timeout 49. Restarting... [2016-11-12 18:34:33.802] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.803] eth3: 5fb5a404ff288410: fsm timeout 48. Restarting... [2016-11-12 18:34:33.803] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.804] eth3: 5fb5a404ff288410: fsm timeout 47. Restarting... [2016-11-12 18:34:33.804] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.805] eth3: 5fb5a404ff288410: fsm timeout 46. Restarting... [2016-11-12 18:34:33.805] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.806] eth3: 5fb5a404ff288410: fsm timeout 45. Restarting... [2016-11-12 18:34:33.806] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.806] eth3: 5fb5a404ff288410: fsm timeout 44. Restarting... [2016-11-12 18:34:33.806] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.807] eth3: 5fb5a404ff288410: fsm timeout 43. Restarting... [2016-11-12 18:34:33.807] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.808] eth3: 5fb5a404ff288410: fsm timeout 42. Restarting... [2016-11-12 18:34:33.808] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.809] eth3: 5fb5a404ff288410: fsm timeout 41. Restarting... [2016-11-12 18:34:33.809] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.810] eth3: 5fb5a404ff288410: fsm timeout 40. Restarting... [2016-11-12 18:34:33.810] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.811] eth3: 5fb5a404ff288410: fsm timeout 39. Restarting... [2016-11-12 18:34:33.811] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.812] eth3: 5fb5a404ff288410: fsm timeout 38. Restarting... [2016-11-12 18:34:33.812] eth3: 5fb5a404ff288410: send [LCP ConfReq id=1 <auth MSCHAP-v2> <mru 1492> <magic 643c9869>] [2016-11-12 18:34:33.813] eth3: 5fb5a404ff288410: fsm timeout 37. Restarting... примерно так валит иногда с 1й попытки, иногда с 15й Linux billing 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux Изменено 12 ноября, 2016 пользователем Sanchezz Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 13 ноября, 2016 · Жалоба иногда с 1й попытки, иногда с 15й Покажите ppp секцию, попробую у себя на стенде. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 13 ноября, 2016 · Жалоба Добавил возможность указания нескольких service-name, плюс опционально можно изменить логику сервера, чтобы решения о подключении к service-name принимал клиент, а сервер принимал всех даже при указанном service-name. Если xeb добавит, у себя протестил :) Прошу взглянуть, если есть очевидные ошибки https://github.com/xebd/accel-ppp/pull/7 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 13 ноября, 2016 · Жалоба Уже нашел ошибку, поправил https://github.com/xebd/accel-ppp/pull/7 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 14 ноября, 2016 (изменено) · Жалоба Добавил возможность указания нескольких service-name, плюс опционально можно изменить логику сервера, чтобы решения о подключении к service-name принимал клиент, а сервер принимал всех даже при указанном service-name. Если xeb добавит, у себя протестил :) Прошу взглянуть, если есть очевидные ошибки https://github.com/xebd/accel-ppp/pull/7 It is possible to specify multiple service names now (as in most pppoe daemons), old options are backward compatible. Also new accel-ppp verifying if service-name specified, it should strictly match on PADI and PADR packets, while old version doesn't do that. It is usual ISP scenario, where some clients has service-name specified, and some are "default". Without this patch default without service-name wont be able to connect. If service-name specified still will answer with service names, but accepts any service name in PADR request. Useful +for scenarios, where selection of PPPoE done by client, based on service names in PADO. Я извиняюсь, разве старые версии не ведут себя так же ? У меня на 30cff41b56be0d4c3e407e8aa4de5b289eef2ab0 указано #service-name= и подключаются и с пустым SN и с вписанным значением. А если указать конкретное SN на AC, то других по идее дропает. [2015-11-26 16:24:28]: info: recv [PPPoE PADI d0:27:88:6e:48:36 => ff:ff:ff:ff:ff:ff sid=0000 <Service-Name test>] [2015-11-26 16:24:28]: warn: pppoe: discarding PADI packet (Service-Name mismatch) Изменено 14 ноября, 2016 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 14 ноября, 2016 · Жалоба На стандартном pppoe сервере даже если указаны service-name - то как минимум с пустым(длина 0, т.е. не указан) на клиенте - все равно пускает. На последних accel - нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 14 ноября, 2016 · Жалоба Вот уже долгое время в голове крутится вопрос, на который я не могу найти ответ =) Используется такое: accel-ppp, radius, Q-in-Q, DHCPv4, OSPF. На lo вешаю ip root@debian:~# ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet 192.168.1.1/32 scope global lo valid_lft forever preferred_lft forever inet 192.168.2.1/32 scope global lo valid_lft forever preferred_lft forever inet 10.0.0.1/32 scope global lo valid_lft forever preferred_lft forever Я предполагаю, что производители некоторых клиентских маршрутизаторов устанавливают значение arp_ignore в 1 и поэтому клиентские маршрутизаторы на хотят отвечать на 03:27:23.393145 ARP, Request who-has 10.0.0.50 tell 192.168.1.1, length 28 Информация по arp_ignore. arp_ignore - INTEGER Define different modes for sending replies in response to received ARP requests that resolve local target IP addresses: 0 - (default): reply for any local target IP address, configured on any interface 1 - reply only if the target IP address is local address configured on the incoming interface 2 - reply only if the target IP address is local address configured on the incoming interface and both with the sender's IP address are part from same subnet on this interface 3 - do not reply for local addresses configured with scope host, only resolutions for global and link addresses are replied 4-7 - reserved 8 - do not reply for all local addresses The max value from conf/{all,interface}/arp_ignore is used when ARP request is received on the {interface} Еще есть параметр arp_announce с которым игрался целый день, но так и не достиг желаемого результата, а именно 03:27:23.393145 ARP, Request who-has 10.0.0.50 tell 10.0.0.1, length 28 Есть мысли по этому поводу, буду благодарен за любой пинок в правильном направлении. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 14 ноября, 2016 · Жалоба Dimka88 Не используйте адреса /32, и не будет проблемы. Не нужно изобретать костыли там, где они не нужны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...