Re: debian + hostapd + pptp = pptp random disconnect
2012/5/14 Eugene Berdnikov <bd4@protva.ru>:
> 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
Reply to: