[morfair]

Нет, надо вставить перед "log_daemon_msg "Starting PPtP/L2TP/PPPoE server" "accel-pppd""

 

Поменяйте значение переменной /proc/sys/kernel/core_pattern на "ZXCVBNM", а потом ищите дампы поиском - find / | grep ZXCVBNM (можно и не менять и искать find / | grep core, но обычно слишком много лишнего этот поиск даст).

 

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

Т.е., я так понял, выполняю эти действия, после /etc/init.d/accel-ppp-init start у меня появится файлик (скорее всего в той директории, откуда выполню команду), он будет расти и расти, а как упадет - его и выложить.

[s.lobanov]

нет, как упадёт - этот файлик появится

[r00tk1d1]

А производительность при этом не падает, в этом режиме вообще не нужно ни каких манипуляций с портами на коммутаторе, у меня падала поэтому жил на mode=4 (802.3ad)

никак не падает. сервер Dell R710 с 2-мя ксеонами x5560, с других сторон свитчи Extreme Networks BlackDiamond 12802 для бжп и 8810 для агрегации, так возможно просто напросто не заметили ничего. но, правда, с переходом на раунд-робин загрузка процессоров на самом брасе упала (!) эдак на 15%, правда пришлось немного повозится с расбрасыванием irq

Изменено 4 ноября, 2012 пользователем r00tk1d1

[NiTr0]

К слову, как продвигается работа над IPoE? Если что, готов стать бета-тестером (не сейчас, но в ближайшем времени).

[Cramac]

И можно ссылочку на описание работы Ипое?

Как все это должно быть завязано с биллингом, дхцп сервером

[srg555]

http://sourceforge.net/apps/trac/accel-ppp/wiki/IPoE_ru

[xeb]

К слову, как продвигается работа над IPoE? Если что, готов стать бета-тестером (не сейчас, но в ближайшем времени).

ипое не двигается

[NiTr0]

А насколько стабильна master ветка?

[xeb]

не стабильна и когда стабилизируется не известно, т.к. надо тестировать, изменения внесены существенные, не столько в функционал сколько в реорганизацию

[NiTr0]

Ну потестировать если что смогу, и на pptp, и на pppoe, и в близкой перспективе на ipoe (подумываем запустить пилотный дом, с vlan per user в течение нескольких недель если ничего не изменится).

 

P.S. коммит 1c89473 ситуацию с днс не исправил...

[taf_321]

P.S. коммит 1c89473 ситуацию с днс не исправил...

 

После этого коммита выплыли проблемы с клиентами, у которых всякие TP-Link'и и DIR-300, до этого они работали вполне нормально.

[NiTr0]

dir-300 B5/B6 в зависимости от версии прошивки по-разному работают, 1.3.0 точно днс получал после апдейта.

[theMIROn]

P.S. коммит 1c89473 ситуацию с днс не исправил...

ну, на момент send_conf_req dns_opt->addr может быть еще не инициализирован по conf_dns1/2, поэтому логика первого confreq не изменится.

а вообще, имхо, это не может ничего исправить, accel-ppp будет запрашивать dns у клиента, на что в большинстве случаев получит reject, а в меньшинстве - дроп сессии глупым ppp клиентом. на логику получения dns от accel-ppp это не влияет, т.к передать dns/wins клиенту можно только nak-ом, и то в качестве "совета", а не "приказа". клиент волен это все проигнорировать, и продолжать запрашивать ipcp опции без dns/wins.

 

p.s на 1.7 бранч

http://wl500g-repo.googlecode.com/svn/feeds/rtndev/accel-ppp/patches/200-add-wins-support.patch

http://wl500g-repo.googlecode.com/svn/feeds/rtndev/accel-ppp/patches/210-ppp-drop-useless-and-harmless-dns-wins-requests.patch

[NiTr0]

т.к передать dns/wins клиенту можно только nak-ом, и то в качестве "совета", а не "приказа". клиент волен это все проигнорировать, и продолжать запрашивать ipcp опции без dns/wins.

pppd передает его первым же ack-ом, и собссно некоторые глюкавые роутеры именно так ожидают его видеть. Ессно, клиент может проигнорить рекомендацию - но это уже его, клиента, горе.

И да, я после накатки этого патча не заметил изменений в поведении, если я коннекчусь своим pppd+rp_pppoe клиентом - никаких упоминаний о DNS в логе не было. Ни со стороны клиента ни со стороны сервера.

[theMIROn]

pppd передает его первым же ack-ом, и собссно некоторые глюкавые роутеры именно так ожидают его видеть.

ответный ack содержит только то, что было во входящем req.

есть ли возможность глянуть лог где такому глюкавому клиенту pppd умудряется передать dns? (пару страниц назад - неполный)

[NiTr0]

ответный ack содержит только то, что было во входящем req.

Сорри, опечатка, в первом же req передает.

 

есть ли возможность глянуть лог где такому глюкавому клиенту pppd умудряется передать dns?

Нужно будет найти такого глюкавого клиента. DIR-300 со старой прошивкой надо будет попробовать в частности.

В целом, pppd сообщает днс довольно забавно:

 

Nov 11 13:24:29 nas-1 pppd[30775]: sent [iPCP ConfReq id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:29 nas-1 pppd[30775]: rcvd [iPCP ConfReq id=0xc <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:29 nas-1 pppd[30775]: sent [iPCP ConfNak id=0xc <addr 91.202.133.170> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:29 nas-1 pppd[30775]: rcvd [iPCP ConfAck id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:29 nas-1 pppd[30775]: rcvd [iPCP ConfReq id=0xd <addr 91.202.133.170> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:29 nas-1 pppd[30775]: sent [iPCP ConfAck id=0xd <addr 91.202.133.170> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:32 nas-1 pppd[30852]: sent [iPCP ConfReq id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:32 nas-1 pppd[30852]: rcvd [iPCP ConfReq id=0x97 <addr 91.202.135.44> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:32 nas-1 pppd[30852]: sent [iPCP ConfNak id=0x97 <addr 91.202.133.211> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:32 nas-1 pppd[30852]: rcvd [iPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:32 nas-1 pppd[30852]: sent [iPCP ConfReq id=0x2 <addr 172.20.255.65>]
Nov 11 13:24:32 nas-1 pppd[30852]: rcvd [iPCP ConfReq id=0x98 <addr 91.202.133.211> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:32 nas-1 pppd[30852]: sent [iPCP ConfAck id=0x98 <addr 91.202.133.211> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:32 nas-1 pppd[30852]: rcvd [iPCP ConfAck id=0x2 <addr 172.20.255.65>]
.....
Nov 11 13:24:50 nas-1 pppd[469]: sent [iPCP ConfReq id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:50 nas-1 pppd[469]: rcvd [iPCP ConfReq id=0x3 <addr 91.202.134.206>]
Nov 11 13:24:50 nas-1 pppd[469]: sent [iPCP ConfAck id=0x3 <addr 91.202.134.206>]
Nov 11 13:24:50 nas-1 pppd[469]: rcvd [iPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:50 nas-1 pppd[469]: sent [iPCP ConfReq id=0x2 <addr 172.20.255.65>]
Nov 11 13:24:50 nas-1 pppd[469]: rcvd [iPCP ConfAck id=0x2 <addr 172.20.255.65>]
.....
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfReq id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfReq id=0x6 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns2 0.0.0.0> <ms-wins 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfRej id=0x6 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfReq id=0x2 <addr 172.20.255.65>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfReq id=0x7 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfNak id=0x7 <addr 91.202.133.235> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfAck id=0x2 <addr 172.20.255.65>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfReq id=0x8 <addr 91.202.133.235> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfAck id=0x8 <addr 91.202.133.235> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]

 

2-й пример - моя машина, которая не юзает днс, сообщаемый туннелем.

Т.е. - в начальном req рядом с адресом указываются "нулевые" днс, потом - приходит режект + аск от клиента (либо только аск), и уже потом сообщается nak'ом реальный днс.

[theMIROn]

Сорри, опечатка, в первом же req передает.

req - это "слышь пир, ты не против, что я для себя это заюзаю?", передача для одобрения второй стороной, но не передача для этой второй стороны.

как еще то объяснить?..

 

Нужно будет найти такого глюкавого клиента. DIR-300 со старой прошивкой надо будет попробовать в частности.

если не сложно, было бы интересно, на каком этапе клиент вспоминает о dns.

 

В целом, pppd сообщает днс довольно забавно:

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

забыт usepeerdns в конфиге на сервере? mpd5, win2k3, win2k8, pppd без usepeerdns такой ерундой не занимаются.

 

2-й пример - моя машина, которая не юзает днс, сообщаемый туннелем.

Т.е. - в начальном req рядом с адресом указываются "нулевые" днс, потом - приходит режект + аск от клиента (либо только аск), и уже потом сообщается nak'ом реальный днс.

ipcp согласование двухстороннее, сервер согласует с клиентом свое, клиент с сервером - свое, 2 параллельных процесса:

 

пример 1:

Nov 11 13:24:29 nas-1 pppd[30775]: sent [iPCP ConfReq id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:29 nas-1 pppd[30775]: rcvd [iPCP ConfAck id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]

Сервер передал свой адрес и свои 0.0.0.0 dns клиенту, клиент не обратил на dns них внимания и подтвердил адрес севрера

Nov 11 13:24:29 nas-1 pppd[30775]: rcvd [iPCP ConfReq id=0xc <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:29 nas-1 pppd[30775]: sent [iPCP ConfNak id=0xc <addr 91.202.133.170> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:29 nas-1 pppd[30775]: rcvd [iPCP ConfReq id=0xd <addr 91.202.133.170> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:29 nas-1 pppd[30775]: sent [iPCP ConfAck id=0xd <addr 91.202.133.170> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]

Клиент передал свой 0.0.0.0 адрес и dns серверу, сервер не согласился и выдал нужные, клиент перезапросил их, сервер подтвердил

 

пример 2:

Nov 11 13:24:32 nas-1 pppd[30852]: sent [iPCP ConfReq id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:32 nas-1 pppd[30852]: rcvd [iPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:32 nas-1 pppd[30852]: sent [iPCP ConfReq id=0x2 <addr 172.20.255.65>]
Nov 11 13:24:32 nas-1 pppd[30852]: rcvd [iPCP ConfAck id=0x2 <addr 172.20.255.65>]

Сервер передал свой адрес и свои 0.0.0.0 dns клиенту, клиент отказался от выдачи dns серверу, сервер передал только свой адрес, клиент подтвердил

Nov 11 13:24:32 nas-1 pppd[30852]: rcvd [iPCP ConfReq id=0x97 <addr 91.202.135.44> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:32 nas-1 pppd[30852]: sent [iPCP ConfNak id=0x97 <addr 91.202.133.211> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:32 nas-1 pppd[30852]: rcvd [iPCP ConfReq id=0x98 <addr 91.202.133.211> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:24:32 nas-1 pppd[30852]: sent [iPCP ConfAck id=0x98 <addr 91.202.133.211> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]

Клиент передал свой предыдущий адрес и dns серверу, сервер не согласился и выдал нужные, клиент перезапросил их, сервер подтвердил

 

пример 3:

Nov 11 13:24:50 nas-1 pppd[469]: sent [iPCP ConfReq id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:50 nas-1 pppd[469]: rcvd [iPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:24:50 nas-1 pppd[469]: sent [iPCP ConfReq id=0x2 <addr 172.20.255.65>]
Nov 11 13:24:50 nas-1 pppd[469]: rcvd [iPCP ConfAck id=0x2 <addr 172.20.255.65>]

Сервер передал свой адрес и свои 0.0.0.0 dns клиенту, клиент отказался от выдачи dns серверу, сервер передал только свой адрес, клиент подтвердил

Nov 11 13:24:50 nas-1 pppd[469]: rcvd [iPCP ConfReq id=0x3 <addr 91.202.134.206>]
Nov 11 13:24:50 nas-1 pppd[469]: sent [iPCP ConfAck id=0x3 <addr 91.202.134.206>]

Клиент передал свой предыдущий адрес, сервер ничего не имел против

 

пример 4:

Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfReq id=0x1 <addr 172.20.255.65> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfRej id=0x1 <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfReq id=0x2 <addr 172.20.255.65>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfAck id=0x2 <addr 172.20.255.65>]

Сервер передал свой адрес и свои 0.0.0.0 dns клиенту, клиент отказался от выдачи dns серверу, сервер передал только свой адрес, клиент подтвердил

Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfReq id=0x6 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns2 0.0.0.0> <ms-wins 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfRej id=0x6 <ms-wins 0.0.0.0> <ms-wins 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfReq id=0x7 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfNak id=0x7 <addr 91.202.133.235> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:31:12 nas-1 pppd[18971]: rcvd [iPCP ConfReq id=0x8 <addr 91.202.133.235> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]
Nov 11 13:31:12 nas-1 pppd[18971]: sent [iPCP ConfAck id=0x8 <addr 91.202.133.235> <ms-dns1 10.255.0.2> <ms-dns2 91.202.132.2>]

Клиент (windows) передал свой 0.0.0.0 адрес, dns и wins серверу, сервер отказал в выдаче wins, клиент передал только свой 0.0.0.0 адрес и dns, сервер не согласился и выдал нужные, клиент перезапросил их, сервер подтвердил

 

Во всех случаях не забыть спросить о dns/wins - ответственность клиента. сервер для себя просит dns, но получает или отказ (не поддерживают согласование dns в эту сторону) или им пофиг на dns сервера => этим ну никак не заставить клиента перезапросить/уточнить dns для себя. все что можно попытаться сделать - добавлять dns к серверному nak-у, если они отсутствуют в клиентском req, но это приведет к последствиям, если клиент все таки игнорирует dns/wins, будет куча циклов согласования req/nak/req/nak до таймаута lcp или максимального кол-ва nak. второе в accel-ppp не особо реализовано, windows клиенты тоже не ограничивают nak, только таймаут. Вреда больше, чем пользы.

*

[Justas]

Роутерщики на проводе! :)

 

Есть аccel-ppp 1.6. Есть ужас-ужас TRENDNET TEW-652BRP. Роутер подключается по pptp, служебные пакеты ходят вот так:

 

192.168.0.3 = первый сервер с аccel-ppp 1.6

192.168.0.11 = TRENDNET TEW-652BRP

 

tcpdump
17:36:37.259933 IP 192.168.0.3 > 192.168.0.11: GREv1, call 0, seq 13, length 24: LCP, Echo-Request (0x09), id 4, length 10
17:36:37.264787 IP 192.168.0.11 > 192.168.0.3: GREv1, call 2469, seq 18, ack 13, length 28: LCP, Echo-Reply (0x0a), id 4, length 10
17:36:37.315780 IP 192.168.0.11 > 192.168.0.3: GREv1, call 2469, seq 19, length 24: LCP, Echo-Request (0x09), id 3, length 10
17:36:37.316002 IP 192.168.0.3 > 192.168.0.11: GREv1, call 0, seq 14, ack 19, length 28: LCP, Echo-Reply (0x0a), id 3, length 10

 

То есть, всё отлично, эхо-запросы-ответы гуляют там где надо, роутер держит связь неделями.

 

 

Поставили accel-ppp 1.7.2. Тот же роутер с теми же настройками подключается по pptp, служебные пакеты ходят вот так:

 

192.168.0.1 = второй сервер с аccel-ppp 1.7.2

192.168.0.11 = TRENDNET TEW-652BRP

 

tcpdump
18:31:01.399751 IP 192.168.0.1 > 192.168.0.11: GREv1, call 0, seq 10, length 24: LCP, Echo-Request (0x09), id 2, length 10
18:31:01.410906 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 10, ack 10, length 66: IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 8, ack 8, length 28: LCP, Echo-Request (0x09), id 1, length 10
18:31:01.411720 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 11, ack 10, length 62: IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 9, length 24: LCP, Echo-Reply (0x0a), id 2, length 10
18:31:31.399780 IP 192.168.0.1 > 192.168.0.11: GREv1, call 0, seq 11, ack 11, length 28: LCP, Echo-Request (0x09), id 3, length 10
18:31:31.401268 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 12, ack 11, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:31:31.403318 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 13, ack 11, length 66: IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 10, ack 9, length 28: LCP, Echo-Reply (0x0a), id 3, length 10
18:31:31.429859 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 14, ack 11, length 62: IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 11, length 24: LCP, Echo-Request (0x09), id 2, length 10
18:31:31.609500 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 15, ack 11, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:31:32.029309 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 16, ack 11, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:31:32.869315 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 17, ack 11, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:31:34.549470 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 18, ack 11, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:31:37.909563 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 19, ack 11, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:31:44.629920 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 20, ack 11, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:31:58.070545 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 21, ack 11, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:32:01.399762 IP 192.168.0.1 > 192.168.0.11: GREv1, call 0, seq 12, ack 21, length 28: LCP, Echo-Request (0x09), id 4, length 10
18:32:01.401812 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 22, ack 12, length 66: IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 12, ack 10, length 28: LCP, Echo-Reply (0x0a), id 4, length 10
18:32:01.451262 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 23, ack 12, length 62: IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 13, length 24: LCP, Echo-Request (0x09), id 3, length 10
18:32:24.951967 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 24, ack 12, length 74: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [P.], seq 325:341, ack 189, win 2920, length 16: pptp CTRL_MSGTYPE=ECHORQ ID(1)
18:32:31.399765 IP 192.168.0.1 > 192.168.0.11: GREv1, call 0, seq 13, ack 24, length 28: LCP, Echo-Request (0x09), id 5, length 10
18:32:31.403218 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 25, ack 13, length 66: IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 14, ack 11, length 28: LCP, Echo-Reply (0x0a), id 5, length 10
18:32:31.416865 IP 192.168.0.11 > 192.168.0.1: GREv1, call 61263, seq 26, ack 13, length 90: IP 192.168.0.11.57114 > 192.168.0.1.1723: Flags [FP.], seq 341:373, ack 189, win 2920, length 32: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0)
^C  

 

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

 

Вопрос - что изменилось в 1.7.2 по отношению к 1.6 и фича ли это или баг?

Изменено 11 ноября, 2012 пользователем Justas

[theMIROn]

192.168.0.3 = первый сервер с аccel-ppp 1.6

192.168.0.11 = TRENDNET TEW-652BRP

192.168.0.3 = второй сервер с аccel-ppp 1.7.2

192.168.0.1 = второй, опечатка?

 

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

не все роутеры переваривают адрес vpn сервера на туннеле, совпадающий с шлюзом на физ. интерфейсе.

 

Вопрос - что изменилось в 1.7.2 по отношению к 1.6 и фича ли это или баг?

ну это ж клиент тупит, а не accel. разница, как минимум в адресах 1.6 и 1.7.2

Изменено 11 ноября, 2012 пользователем theMIROn

[Justas]

192.168.0.1 = второй, опечатка?

 

Прошу прощения, да. Поправил.

 

не все роутеры переваривают адрес vpn сервера на туннеле, совпадающий с шлюзом на физ. интерфейсе.

 

Вот я и хочу понять, почему на 1.6 переваривают, а на 1.7.2 - нет.

 

разница, как минимум в адресах 1.6 и 1.7.2

 

До вчерашнего дня на 192.168.0.1 стоял 1.6 и проблем не возникало. Проблема возникла после перехода на 1.7.2.

[theMIROn]

Вот я и хочу понять, почему на 1.6 переваривают, а на 1.7.2 - нет.

возможно, из-за расширения формат конфига, что-то недонастроено

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

возможно, клиент сменил прошивку на своем тренднете

все возможно. tcpdump показывает лишь проблемы с маршрутизацией на клиенте, который, шлет gre траффик по дефолтному маршруту на туннельны адрес сервера

решение очевидно - использовать туннельный адрес сервера, отличающийся от доступного по физике.

[Justas]

решение очевидно - использовать туннельный адрес сервера, отличающийся от доступного по физике.

 

Туннельный адрес сервера отличается.

 

 

192.168.0.3 = сервер с аccel-ppp 1.6

192.168.0.11 = TRENDNET TEW-652BRP

10.10.0.3 = шлюз по умолчанию для ppp

10.10.0.11 = IP, выданный роутеру на его ppp-интерфейс

 

ifconfig
ppp14     Link encap:Point-to-Point Protocol
         inet addr:10.10.0.3  P-t-P:10.10.0.11  Mask:255.255.255.255
         UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1

 

 

 

192.168.0.1 = сервер с аccel-ppp 1.7.2

192.168.0.11 = TRENDNET TEW-652BRP

10.10.0.1 = шлюз по умолчанию для ppp

10.10.0.11 = IP, выданный роутеру на его ppp-интерфейс

 

ifconfig
ppp29     Link encap:Point-to-Point Protocol
         inet addr:10.10.0.1  P-t-P:10.10.0.11  Mask:255.255.255.255
         UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1400  Metric:1

 

 

 

Если я сейчас поставлю на 192.168.0.3 аццель версии 1.7.2, то проблема появится и здесь. Понятно, что проблема в роутере. Вопрос в том, почему она проявилась на аццеле 1.7.2 и что сделать, чтобы всё вернуть на свои места. В опциях конфигурационного файла аццеля ничего близкого к проблематике не обнаружено.

Изменено 11 ноября, 2012 пользователем Justas

[Justas]

После нескольких перенастроек и перезагрузок роутера он стал себя проблемно вести и с 1.6 :(

 

Вопрос снят, спасибо. Буду колупать роутер.

[morfair]

Други. После неудачной предыдущей миграции на accel-ppp решил не морочатсья и настроить снуля. Может кто посоветовать, на какой версии Debian'а и с какой версией accel-ppp нормальная, без падений и глюков, работа была замечена?

[nsa2006]

Други. После неудачной предыдущей миграции на accel-ppp решил не морочатсья и настроить снуля. Может кто посоветовать, на какой версии Debian'а и с какой версией accel-ppp нормальная, без падений и глюков, работа была замечена?

Debian Squeeze 6.0.6, ядро 2.6.35.9, accel-ppp 1.6.1

На 1.7.2 после перезагрузки net-snmp, наблюдались падения на 1.6.1 нет.