2012/5/14 Eugene Berdnikov <[email protected]>: > On Mon, May 14, 2012 at 04:15:22PM +0300, Gary Trotcko wrote: >> Мммм.... Но почему при _выключенном_hostapd_ сессия на рвётся? > > Это меня тоже занимало, продолжал чесать репу после того как > написал последнее письмо. И нашёл признаки того, что у клиента > поломан ip-шный стэк. Видно по этому фрагменту: > >> 13:29:55.739405 IP 192.168.120.184.56438 > 192.168.117.211.1723: Flags >> [.], ack 21, win 3650, options [nop,nop,TS val 32812773 ecr >> 654458210], length 0 > >> 13:30:46.979768 IP 192.168.117.211.1723 > 192.168.120.184.56438: Flags >> [F.], seq 21, ack 16, win 62, options [nop,nop,TS val 654463334 ecr >> 32812773], length 0 > >> 13:30:46.980456 IP 192.168.120.184.56438 > 192.168.117.211.1723: Flags >> [P.], seq 16:32, ack 22, win 3650, options [nop,nop,TS val 32825584 >> ecr 654463334], length 16: pptp CTRL_MSGTYPE=CCRQ CALL_ID(0) > > Здесь такая нестыковка: после прихода от сервера пакета нулевой длины > на клиенте счётчик байтов смещается на 1 (с ack=21 на ack=22). > IMHO, это бага. > > Как реагирует на это ядро сервера -- неизвестно, но вполне вероятно, > что оно начинает дропать все дальнейшие пакеты от клиента (которые > выбежали за границу окна передачи), но при этом считать, что FIN остался > без подтверждения. Если это так, то пачка FINов от сервера является > простыми ретрансмиссиями первого, что похоже на правду, поскольку > у них всех ecr=32812773. > > Ниже нашлась ещё одна фигня со строны клиента: > >> 13:30:47.188877 IP 192.168.120.184.56438 > 192.168.117.211.1723: Flags >> [.], ack 22, win 3650, options [nop,nop,TS val 32825636 ecr >> 654463355,nop,nop,sack 1 {21:22}], length 0 > > Сочетание ack=22 и sack={21:22} нелепо, таких пакетов быть не должно. > > В общем, похоже что включение hostapd приводит к поломке ip-стэка. > Правда, я всё-таки не вижу причину для первоначального FINа от сервера. > Но дамп неполный, не исключено, что коннекция сломалась задолго до того, > как был запущен tcpdump, и первый FIN -- окончание процесса умирания > по таймауту. Тогда никакие "злоумышленники" не при чём, конечно. :)
Приблизительно такую причину я и предполагал (эмпирически :)), Вот решил поиграться с опциями pptp - обратил внимание что выключена буферизация опцией --nobuffer. Запустил без неё - рабтает уже больше 4-х часов. Ждём-с... -- Best Regards, Gary Trotcko
