theMIROn

из дампа в telegram видно, что это были роутеры tp-link, у которых ClientID (DUID LLT) меняется с каждым запросом. первый Client ID запоминается, а дальше следующие запросы выглядят для сервера в той-же сессии другими клиентами, на что получают отлуп.

из-за mtu == 0. патч тут http://pastebin.com/raw.php?i=rCY5cGdu

Начиная с версии bind 9.6-esv-r11. Немного подробнее тут https://deepthought.isc.org/article/AA-01113/0/Case-Insensitive-Response-Compression-May-Cause-Problems-With-Mixed-Case-Data-and-Non-Conforming-Clients.html Если в роутере используется древний dns релей dproxy, то проблема проявляется. Более того, dproxy еще и шлет запросы с 53 порта, слушает ответы на нем же. На старых моделях асуса (520/500) оно точно применялось, возможно и у других вендоров тоже. Решается или сменой прошивки на альтернативную, или прописыванием доп. DNS для выдачи клиентам в настройках роутера.

zyxel/dlink используют протухшую uclibc, которая не переваривает большое количество хостов gethostbyname() и со сжатием (host1.domain.tld host2.domain.tld *.domain.hld) тоже могут возникать проблемы так что ppp демон не при чем, дело в системной *libc.

по идее оно нужно для оверрайда mtu на линке, для ppp mtu согласуется по lcp, то есть как бы не обязательно, плюсом не должно быть меньше 1280 ошибаюсь?

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

192.168.0.1 = второй, опечатка? не все роутеры переваривают адрес vpn сервера на туннеле, совпадающий с шлюзом на физ. интерфейсе. ну это ж клиент тупит, а не accel. разница, как минимум в адресах 1.6 и 1.7.2

Ещё интереснее было б это обойти :) 2мя строчками в pppd

req - это "слышь пир, ты не против, что я для себя это заюзаю?", передача для одобрения второй стороной, но не передача для этой второй стороны. как еще то объяснить?.. если не сложно, было бы интересно, на каком этапе клиент вспоминает о dns. все в норме, за исключением того, что сервер за каким-то невнятным смыслом просит для себя dnsы у клиентов, ни разу не получая и удлинняя процесс согласования. забыт usepeerdns в конфиге на сервере? mpd5, win2k3, win2k8, pppd без usepeerdns такой ерундой не занимаются. 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, только таймаут. Вреда больше, чем пользы. *

ответный ack содержит только то, что было во входящем req. есть ли возможность глянуть лог где такому глюкавому клиенту pppd умудряется передать dns? (пару страниц назад - неполный)

ну, на момент 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

ну хз, в жабе офлайн мессаг не было, в почте тоже пусто. угу, особенно таких здоровых. dibbler ~ 1Mb весит один. попробуй к своему bb прикрутить, может и допилишь что еще, всяко полезнее, чем просто ждать

first of all, author of dhcpv6 porting is lly, not me, second - there's no garantee that dhcpv6 will be included, but we will try, of course p.s а чо не на мове? :D

Поздравляю :)

xeb, патч поправляющий сборку на 2.4. плюсом у меня спортирован gre.c на 2.4 + завязка на CONFIG_GRE + патч на ip_gre, дооформлю передам fixed_2.4_build.patch.gz