PPTP out-of-order пакеты от провайдера не проникают на pptp интерфейс

werter

@forumlike
У пф в настройках есть про DF bit. Покрутите ее.

forumlike

DF бит насколько я понимают это не дропать фрагментированные пакеты с DF битом.

у меня пинги отправляются и возвращаются без DF бита, так что не вижу перспективы в этом направлении.

но попробовал все-таки

не помогло

werter

@forumlike

http://netwild.ru/pptp/

MTU
Не менее важный вопрос для протокола — это вопрос MTU.
Так как PPTP — это полезная нагрузка + заголовок PPP+ GRE + заголовок IP. MTU Ethernet = 1500 байт, header IP = 20 байт, GRE = 4 байта. 1500-20-4 = 1476 байт.

Что говорит ping -f -l 1476 -t <ip-addr> на Win? И уменьшайте размер до момента прохождения пакета.
Может на одном из концов туннеля у провайдера иной размер mtu?
Вроде ж у пф есть возможность уменьшить MTU на pptp-интерфейсе. Попробуйте до 1300 уменьшить.

forumlike

я же писал что пинги (пакеты) то в принципе ходят, но фрагментация на уровне GRE не позволяет им "появиться" на PPTP

может это по моей проблеме?:

Представим себе, что недалеко от точки приёма такого трафика возникают неподконтрольные нам перестановки пакетов - то есть, все пакеты доставляются без потерь, но очень часто соседние пакеты приходят переставленными местами .............. И даже если использовать PPP-туннель без шифрования/компрессии, мы получаем огромный процент потерь внутри туннеля, потому что GRE вынужден дропать "опоздавшие" фреймы PPP, так как не имеет права доставлять их с нарушением порядка (дропать - имеет право).

Но если обучить GRE восстанавливать порядок пакетов, то PPP/MPPE даже и не узнают, что были проблемы с доставкой (пока не начнутся настоящие потери). Для ноды ng_pptpgre(4), которую использует mpd при создании PPtP-туннелей, сделал патч. Update 07.09.2016: обновление (information text)

Патч даёт возможность управлять глубиной очереди ожидания переупорядоченных пакетов через sysctl net.graph.pptpgre.reorder_max (ноль отключает восстановление порядка) и таймаутом ожидания "опоздавших" пакетов (в милисекундах) через net.graph.pptpgre.reorder_timeout. Тесты показали хороший результат при reorder_max=16 и таймаутом в 1ms, когда точка переупорядочивания близко к нам и в 50ms, если далеко. Изменять значения этих параметров можно "на лету", без переустановки туннелей. В итоге CCP даже не дергается, если низлежащий GRE успешно восстанавливает порядок.

взято отсюда https://dadv.livejournal.com/tag/pptpgre

там сказано что есть патч для ng_pptpgre.ko но в итоге придется пересобирать ядро, так вообще делают с pfSense?

что же делать?

werter

@forumlike

Сменить провайдера.
Узнать у провайдера о др. типах подключения.

Не надо велосипедить.

Konstanti

@forumlike
Здр
Если проблема именно в том , что Вы описали
Возможно стоит дождаться версии PF 2.4.5 , насколько вижу , в этой версии этот патч уже присутствует.
Или пойти по пути , который советует Werter

werter

@forumlike
Или пользовать 2.4.5 не дожидаясь релиза )

@Konstanti
https://redmine.pfsense.org/projects/pfsense/roadmap ничего по pptp нет и по ppp не вижу (
Нашел из похожего только https://redmine.pfsense.org/issues/10222
Можно ссылку?

forumlike

2.4.5-RC - проблема исчезла! радости нет предела

добавили вышеназванный патч
параметры на скрине

net.graph.pptpgre.reorder_timeout: 1
net.graph.pptpgre.reorder_max: 1

ради любопытства сделал
sysctl -w net.graph.pptpgre.reorder_max=0
и получил те самые 100.0% packet loss

sysctl -w net.graph.pptpgre.reorder_max=1
и тогда супер

Konstanti

@werter
Ссылки на официальные доки нет
Есть ссылка на исходники freebsd , собственно там все и было найдено

werter

@Konstanti
Принял, спасибо.