grandrew/linux-mptcp

linux-mptcp's Issues

2) Прозрачный Tinyproxy (проверка)

Построить схему для агрегировани HTTP трафика. Схем работы: блок с прозрачным(хотя для проверки можно и не прозрачный) tinyproxy через iptables указываем в нем upstream host:port прокси на сервере.

2.5)Отваливаются или не подключаются подпотоки

Есть 4 интерфейса на клиенте. Есть ssh, скажем 4 инстанса (4 сессии ssh к одному серверу). Есть сервер ssh c одним внешним интерфейсом. Проблема:
После подключения должно создаваться 16 сокетов: (1 "реальный" + 3 mptcp, по одному на каждый интерфейс) * 4 (ибо 4 сесси ssh), но они не создаются или создаются не всегда. Например может открыться только 12 сокетов. Далее: допустим подключилось 16 сокетов, но в случае если один интерфейс отвалился, а потом поднялся - сокеты опять-таки не создаются или создаются но не в полном объеме. Например может подключиться только два или три, вместо 4-х.
Проблема менее заметна или почти отсутствует на малом количестве интерфейсов. Например на двух. На двух модемах вроде как работало все четко. Но не уверен, надо проверить.

1.1) Тест на вирт машине 16 подпотоков вместо 64 (проверить зависание)

Зависит от #2

2.1) Принудительное кол-во подпотоков.

• Найти в ядре для path manager'а fullmesh где принимается решение об установки того или иного колличества соединений и вписать принудилельное значение(не больше и не меньше).
• Убрать зажержку на установление подпотоков для короткоживущих соединений. Или по крайней мере уменьшить паузу для каналов с большым latency.

1.3) Тест на железе

После сборки Openwrt #4 проверить на зависание ядра с 16-ю подпотоками на реальном железе.

1.2) Пропатчить и собрать на Openwtr mptcp ядро 16 подпотоков

Если выполнено #3 #2

1) Выключить ipv6

выключить ipv6 на сапсановском блоке и проверить пропадут ли нерабочие подпотоки.

2.4)Добавать проверку при запуске subflow_monitor_worker

Если такой процесс уже есть в очереди то не запускать его повторно, во избежание гонок. Зависит от #1

2.2) Не появляются дополнительные подпотоки

Бывают случаи когда не появляются дополнительные подпотоки, хотя адреса добавлены. Существует механизм повторного соединения судя по комментарию 1 раз, на основе delayed_work_pending Влияет на #1.

2.3 При проблеме в middle box'e поток не отваливается

Не отвалисается подпоток если на маршруте происходит обрыв без пропадания соединения. Влияет на #1.

0) Статистика для модемов(и не только) по сапсану

Собрать статистику для понимания есть ли проблема с модемами или нет. Скорее всего она есть нужно понять что мы можем сделать, может нужно привлеч кого-то для решения этой проблемы.

2.1) Прозрачный tcp proxy aka pep proxy

По результатам проверки #9 принять решение в каком виде делать, Может даже есть смысл оставить tinyproxy.

1) Сделать ограничение в 16 подпотоков вместо 64

После добавления возможности создания 64 подпотоков появился баг связанный с полным зависанием сетевой подсистемы. Сделано сдесь commit 0a32cdd