Ubuntu: как исправить ошибку snap «unexpected HTTP status code 408» и почему виснет ssh

Доброго дня. Представляю очередной небольшой детектив с внезапной развязкой.

В какой-то момент у меня перестала работать установка приложений через snap install или snap refresh. Вываливалась ошибка:

$ sudo snap refresh
ошибка: cannot refresh: cannot query the store for updates: got unexpected HTTP
              status code 408 via POST to "https://api.snapcraft.io/v2/snaps/refresh"

Это явно таймаут. При этом некоторые другие команды снапа (вроде поиска) работали.

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

На офисном компе с такой же ОС со снапом проблем никаких нет. Это косвенно подтверждало сетевые проблемы дома, коих не было на старом провайдере, но никаких явных подтверждений не было. Где искать причину и как она может выглядеть тоже непонятно.

Были изучены следующие материалы:

• https://forum.snapcraft.io/t/error-http-status-code-408-snap-store/28980
• https://forum.snapcraft.io/t/snap-cannot-communicate-with-server/4700
• https://forum.snapcraft.io/t/unable-to-install-any-application-from-snap-store/29028
• https://forum.snapcraft.io/t/snapd-not-connecting-to-the-store-what-to-test-do/7190
• https://forum.snapcraft.io/t/unable-to-install-any-application-from-snap-store/29028
• https://forum.snapcraft.io/t/unable-to-contact-snap-store/16107

Вообще. Всё. В молоко. Полезной инфы около нуля, какие-то подсказки и решения не помогали. Разве что получилось собрать в кучу всякое отладочное: https://pastebin.com/yKdfqj8b

Пока версия была только в транспорте, потому что некоторые из узлов *.he.net (видны в выводе mtr по ссылке выше) определяются только через секунд 15 и потери там почти полные. Таймаут 408 логичен. Я полагал, что можно было бы изменить этот таймаут где-то в конфигах снапа, но нет. На проблему подзабил, т.к. не горело.

---

Однажды, я приводил в порядок некоторые настройки на домашнем сервере и решил зайти на него по ssh со своего компа. Коннекта не было.

Выполнил ssh с ключом -v и увидел как вывод остановился на строчке

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Дальше только ^C. Пинг до машины есть, машина в сети, конфиги ssh мной не менялись очень давно. Видимо, проблемы с домашней сетью или доступом к ней. Пффф….

Гуглёж этой строчки указал на необходимость смены MTU на сетевом интерфейсе тачки. Кому-то помогает значение 1200, кому-то 1400. На моём роутере значение по дефолту 1500.

Я наугад проверил оба предлагаемых значения и ssh заработал на обоих.

На авось я решил проверить починился ли snap refresh. И таки да, починился. Та ошибка тоже была связана с MTU.

---

Ниже скриншоты гуйни где это можно настроить.

Изменение MTU в своём роутере я нашёл только на уровне соединения с провайдером, но его применение требует перезагрузки проутера, так что временно я на самих машинах задал 1200 ручками. Задал по сути наугад, но после перепроверок значение 1200 для меня (пока) вполне подходит. Может на досуге ещё поизучаю и скорректирую на роутере.