TCP Dup ACK/ ретрансляция, неправильная конфигурация?

Я в настоящее время расследует сетевые проблемы друзей локальной сети (снова). Подключение к интернету очень медленное и ненадежное, и иногда сервисы просто не работают.

я контролировал трафик в течение некоторого времени с помощью Wireshark. Я наконец-то придумал воспроизводимую проблему,git pull over ssh это не сработало. Вот то, что журнал Wireshark из git pull выглядел так:

wireshark log

повторные передачи TCP всегда запускаться при инициализации обмена ключами. Либо сервер не получает пакет от моей машины и моя машина не получает ответа. У меня есть ощущение, что причина этого также является причиной всех других сетевых проблем локальной сети.

одна вещь, которую я придумал-это длина пакета 1514, в то время как не фрагментируйте набор битов, всех плохих пакетов здесь, но маршрутизатор LANs настроен для MTU 1492. Не удается настроить маршрутизатор для MTU большего размера чем 1500. Могут ли пакеты быть слишком большими, чтобы они застряли на маршрутизаторе?

кроме того, в основном безопасные соединения (https, ssh), кажется, затронуты, но они всегда могут потребовать больших размеров пакетов.

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

редактировать: только что git pull снова работает нормально. Конфигурация MTU не может быть причина возникновения проблем...

5
задан Community
20.02.2023 6:34 Количество просмотров материала 3062
Распечатать страницу

2 ответа

большие пакеты с "не фрагментировать" нормальные. Вот как ОС выполняет обнаружение MTU – вместо того, чтобы позволить сети спокойно фрагментировать пакеты, она ожидает, что ICMP" фрагментация требуется " ошибка будет возвращена (который будет иметь правильный MTU).

Если вы видите, что большие пакеты ретранслируются, это означает, что какой-то маршрутизатор в середине неправильно настроен и либо блокирует пакеты ошибок ICMP, либо не отправляет их при необходимости.

1
отвечен grawity 2023-02-21 14:22

Я думаю, что дубликат ack происходит только когда получатель видит пробел в порядковых номерах, это означает, что пакет был отброшен по пути к нему; поэтому проблема начинается в направлении от 192.168.0.8 до удаленного сервера. Тот факт, что нет никаких ACK (даже не дублирующих ACK) назад, несмотря на несколько повторных передач, вероятно, означает, что что-то полностью ввернуто в этом направлении. (Это может означать, что удаленная сторона не может отправить, но это не согласуется с дубликата ack ранее, ни с fin-ack позже. Это означает, что есть 2 проблемы вместо 1.)

вот несколько идей:

  • если соединение через плохой общественный Wi-Fi или 3G, то вы можете получить краткие периоды 100% падения пакета. Проверьте, используя другую службу в то же время и посмотреть, если он влияет на отключение слишком.
  • существуют межсетевые экраны, поддерживающие протоколы, которые могут занять некоторое время, чтобы понять, что вы делаете, прежде чем они решат отбросить пакеты конкретное соединение. Ваш друг использует экзотический брандмауэр, который можно отключить? Есть ли у провайдера некоторые правила использования?
  • попробуйте обновить драйверы или загрузиться с live CD linux и посмотрите, произойдет ли то же самое. Попробуйте изменить другие аспекты соединения, используя другие сервисы, чтобы сузить, что не так.
1
отвечен snoopy 2023-02-21 16:39

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх