У системы в офисе узел тестовой сети застрял в определенном блоке.
Журналы снова и снова сообщают о «запрашивающем блоке» для одного и того же блока, и после того, как каждый из них сообщает об «ошибке приема сокета», и этот одноранговый узел отключается. Затем он подключает новый пир, и происходит то же самое. В журнале нет записей о INVALID блоках.
В результате в системе не было нового блока в течение двух дней, но все исследователи сообщают, что цепочка продолжает двигаться вперед.
Текущий блок, в котором находится этот узел, является членом лучшей цепочки, о которой сообщают исследователи, но отстает на тысячи.
Этот узел работает на Ubuntu в США. В офисной сети установлен брандмауэр sonicwall.
Обычно, когда узел зависает, это происходит из-за локального повреждения, заставляющего узел ошибочно полагать, что блок недействителен. Но в этих случаях журналы будут отражать недопустимые блоки. Вместо этого мы не видим здесь какой-либо недействительности, но узел постоянно пытается получить блок и отключается.
Такая ситуация может быть вызвана чрезмерно агрессивным антивирусом, который ложно определяет данные в блоке как вредоносные и обрывает соединение. Иногда этот тип фильтрации применяется к широкой публике путем фильтрации на уровне государства, но он также проявляется в офисных сетях и в некоторых домашних установках (например, в программном обеспечении Windows AV).
Для sonicwall вы можете увидеть отключения в журналах брандмауэра и полностью отключить фильтрацию, зайдя в настройки брандмауэра в разделе sonicwall-> управление-> службы безопасности-> шлюз-антивирус и сняв флажок «Включить антивирус шлюза», или внесив в белый список ложноположительное совпадение для конкретного хоста, о котором идет речь.
(Спасибо Кену в IRC, у которого была эта реальная проблема, и за то, что рассказал мне, как он отключил ее на sonicwall)