Все об Arch Linux

Arch Linux будет тем, что вы из него сделаете!

Realtek уходит в downshift: скорость падает до 100 Мбит

Проводное подключение падает до 100 Мбит, сеть отваливается и возвращается только после нескольких попыток? В журнале видно Link is Up - 100Mbps/Full (downshifted) и череда Link is Downdhcp4: state changed no lease? Причина физическая: деградировавший кабель или коннектор. Гигабиту нужны все четыре пары жил, а при плохом контакте чип Realtek снижает скорость до 100 Мбит. Если контакт совсем скверный, даже 100 Мбит не держатся. Плюс конфликт двух менеджеров сети мешает DHCP завершиться.

Почему Realtek уходит в downshift: физика вопроса

При старте чип r8169 поднимает гигабит. Ядро проверяет качество линии и видит: одна или несколько пар не работают. PHY снижает скорость до 100 Мбит (ему хватает двух пар). Но контакт настолько плохий, что линк флейпует: Link is Up сменяется Link is Down через секунду. Каждый обрыв отменяет DHCP-транзакцию. Система пытается, обрывается, пытается снова. Иногда сеть «ловится» с пятой-шестой попытки, иногда не ловится вообще.

Типичная картина в journalctl:

Link is Up - 100Mbps/Full (downshifted)
Link is Down
dhcp4 (enp42s0): state changed no lease
Link is Up - 100Mbps/Full (downshifted)
Link is Down

Прогрессия 100M нестабилен → держится только 10M означает линию, которая ухудшается. Тянуть с заменой кабеля нельзя.

Как диагностировать downshift проводной сети

Смотрим историю загрузок

Список последних бутов покажет, когда проблема появлялась:

journalctl --list-boots --no-pager | tail -4

Ищем строки с сетевым интерфейсом в прошлом буте

Забираем логи предыдущей загрузки и фильтруем по имени интерфейса или драйверу:

journalctl -b -1 --no-pager | grep -iE 'enp42s0|r8169'

Если в выводе видны downshifted, Link is Down, check cabling! … корневая причина на поверхности. Проблема физическая, а не программная.

Проверяем скорость линии мимо приложений

Быстрый тест через curl к Cloudflare. Данные гоняются по проводу напрямую, минуя браузер и его расширения:

curl -s -o /dev/null -w "%{speed_download}" --max-time 10 \
  "https://speed.cloudflare.com/__down?bytes=80000000"

Результат в байтах/сек. Делим на 1 000 000, получаем мегабайты. Норма для гигабита: ~100–110 МБ/с. Если видите 10–12 МБ/с … линия держит 100 Мбит. Если ещё ниже … 10 Мбит, линия умирает.

Как исправить: замена кабеля и один менеджер сети

Шаг 1. Замените патч-корд

Это физика, и софтом её не почините. Берёте Cat5e или Cat6, меняете кабель ПК → роутер. Запасного нет? Переткните оба конца, попробуйте другой порт на роутере. Часто помогает именно переподключение.

Шаг 2. Оставьте один менеджер сети

На многих Arch-системах одновременно работают NetworkManager и systemd-networkd. Они конфликтуют за DHCP-сокет. Когда линк флейпует, оба хватают интерфейс, и ни один не завершает транзакцию нормально.

Оставляем NetworkManager и глушим systemd-networkd со всеми юнитами:

sudo systemctl disable --now systemd-networkd.service \
    systemd-networkd.socket systemd-networkd-resolve-hook.socket \
    systemd-networkd-varlink.socket systemd-networkd-varlink-metrics.socket \
    systemd-networkd-persistent-storage.service systemd-networkd-wait-online.service

⚠️ Ловушка. Если отключить только systemd-networkd.service, сокеты останутся активными. Статус activating на сокете продолжит мешать. Гасить нужно все юниты одним списком, как выше.

Шаг 3. Проверяем результат

systemctl is-active systemd-networkd   # inactive
nmcli -f DEVICE,STATE device
ping -c2 8.8.8.8

systemctl is-active покажет inactive, nmcli покажет состояние интерфейса, ping подтвердит, что пакеты ходят.

Типичные ошибки при диагнозе

«Попробую переустановить драйвер». Драйвер r8169 живёт в ядре, его не надо переустанавливать. Проблема не в нём.

«Настрою static IP, чтобы DHCP не отваливался». Статика уберёт гонку за DHCP, но не решит флейпинг линка. Интерфейс по-прежнему будет падать в Link is Down.

«Пропишу скорость вручную через ethtool». Форсирование скорости не заставит PHY игнорировать плохой контакт. Ядро сбросит обратно на автоматический выбор.

Частые вопросы

Как понять, что проблема именно в кабеле, а не в драйвере?

Строка check cabling! в выводе journalctl -b -1 | grep -iE 'enp42s0|r8169' однозначно указывает на физический уровень. Драйвер r8169 в ядре стабилен, проблемы с ним бывают крайне редко.

Можно ли проверить скорость линии без браузера?

Конечно. Команда curl -s -o /dev/null -w "%{speed_download}" --max-time 10 "https://speed.cloudflare.com/__down?bytes=80000000" гоняет данные по проводу напрямую. Результат покажет реальную пропускную способность линии.

Что значит (downshifted) в логе ядра?

Чип Realtek сообщает: «хотел гигабит, но линия не тянет, переключился на 100 Мбит». Если скорость продолжает падать до 10 Мбит, кабель нужно менять срочно.

Два менеджера сети в системе … это нормально?

Нет. NetworkManager и systemd-networkd конфликтуют за управление интерфейсами и DHCP. Выберите один. Проверить текущую ситуацию: nmcli -f DEVICE,STATE device и systemctl is-active systemd-networkd.

Заключение

Downshift на Realtek r8169 почти всегда физика: кабель, коннектор, порт роутера. Замена патч-корда на Cat5e/Cat6 решает проблему в большинстве случаев. Параллельно убедитесь, что в системе работает только один менеджер сети, а не два одновременно. Команды из статьи помогут отличить аппаратную проблему от программной за пару минут.

Полезные ресурсы



Не получилось? Поможем настроить

Задай вопрос в чате — отвечаем быстро, по делу и без воды.

Читайте также

Комментарии

Загрузка…

Откроется GitHub: создайте новый issue с вашим комментарием (кнопка «Submit new issue»). После отправки обновите эту страницу — комментарий появится ниже.

Telegram Max