PPTP out-of-order пакеты от провайдера не проникают на pptp интерфейс
-
@forumlike
У пф в настройках есть про DF bit. Покрутите ее. -
DF бит насколько я понимают это не дропать фрагментированные пакеты с DF битом.
у меня пинги отправляются и возвращаются без DF бита, так что не вижу перспективы в этом направлении.
но попробовал все-таки
не помогло
-
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 уменьшить. -
я же писал что пинги (пакеты) то в принципе ходят, но фрагментация на уровне 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?
что же делать?
-
-
@forumlike
Здр
Если проблема именно в том , что Вы описали
Возможно стоит дождаться версии PF 2.4.5 , насколько вижу , в этой версии этот патч уже присутствует.
Или пойти по пути , который советует Werter -
@forumlike
Или пользовать 2.4.5 не дожидаясь релиза )@Konstanti
https://redmine.pfsense.org/projects/pfsense/roadmap ничего по pptp нет и по ppp не вижу (
Нашел из похожего только https://redmine.pfsense.org/issues/10222
Можно ссылку? -
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 losssysctl -w net.graph.pptpgre.reorder_max=1
и тогда супер -
@werter
Ссылки на официальные доки нет
Есть ссылка на исходники freebsd , собственно там все и было найдено -
@Konstanti
Принял, спасибо.