Автор Тема: Периодические обрывы связи с интернетом  (Прочитано 1097 раз)

Оффлайн Speccyfighter

  • Мастер
  • ***
  • Сообщений: 10 259
Глупый вопрос.
Есть ещё usb-сетевухи. Их можно втыкать по мере необходимости, т.е. отсутствующий адаптер - не означает, что он убран навсегда.

Ответ не так прост как кажется.

Это хот-плаг устройства и поднимаются они через usb-контроллер:
(все выбросы из xfce-sysv)
# lspci | grep -i 'usb controller'
00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03)

Соответственно и имя интерфейса у них другое:
# grep . /sys/devices/pci0000\:00/0000\:00\:14.0/usb*/*/*/net/usb*/uevent
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/net/usb1/uevent:INTERFACE=usb1
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/net/usb1/uevent:IFINDEX=5
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/net/usb0/uevent:INTERFACE=usb0
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/net/usb0/uevent:IFINDEX=4

В xfce на sysvinit с NM, эти устройства поднимаются через ModemManager автоматом и становятся в приоритете.
При этом, трафик идёт, через первое подключенное usb-устройство.
И в общем случае (но не всегда), оно будет иметь имя интерфейса usb0.
Т.е. ни при каких условиях, usbN не будет превышать количество устройств подключенных к usb портам минус единица. Что правильно.
Если при двух подключенных устройствах, устройству с интерфейсом usb0 выполняется реплаг, оно всё равно сядет устройством с интерфейсом usb0.
И ни о каком безумном росте usb(N+1) даже речь не идёт. И такой код правильный.
Неважно сколько будет выполнено реплагов или какое устройство будет подключено в произвольный момент. Имя интерфейса останется фиксированным, - usb0.

Но есть тонкость:
Если устройству с интерфейсом usb0 выполняется программно-аппаратгный реплаг, при двуз подключенных устройствах, то первым подключенным устройством, оно уже не будет
# grep -H . /sys/devices/pci0000\:00/0000\:00\:14.0/usb*/*/*/net/usb*/uevent
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/net/usb1/uevent:INTERFACE=usb1
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.0/net/usb1/uevent:IFINDEX=26
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/net/usb0/uevent:INTERFACE=usb0
/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2:1.0/net/usb0/uevent:IFINDEX=27

и весь трафик пойдёт через устройство с интерфейсом usb1, которое теперь уже оно окажется подключенным первым:
# sar -n DEV 1 5 | grep Среднее -A5
Среднее:     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
Среднее:        lo      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00
Среднее:      eth0      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00
Среднее:     wlan0      0,20      0,00      0,01      0,00      0,00      0,00      0,00      0,00
Среднее:      usb1    116,40     54,20    165,63      5,19      0,00      0,00      0,00      0,00
Среднее:      usb0      0,00      0,00      0,00      0,00      0,00      0,00      0,00      0,00

При этом в отношении NM в системах на sysvinit, следует помнить, что права доступа могут быть как минимум на порядок более гибкими чем в системах на systemd. И могут быть admin != netadmin. В системах с NM на sysvinit без logind, реализовано это через группу _nmconnect. И работает это только в NM на sysvinit без logind. Для реализации, требуется кастомный рулез в /etc/udev/rules.d.
Копированием /usr/share/polkit-1/rules.d/60-sysvinit-nm.rules в /etc/udev/rules.d. С заменой для правила группы wheel на группу _nmconnect.
Понятно, что права доступа для NM, опираясь на /usr/share/polkit-1/actions/org.freedesktop.NetworkManager.policy, rules для NM в /etc/udev/rules.d, можно расписать более детально и более гибко. В каждом отдельном случае, это всегда индивидуально. И это всегда баланс между безопасностью и удобством с необходимостью. Совершенно очевидно, что одного однозначного решения, на все случаи жизни, здесь нет и не будет.

Оффлайн Камиль

  • Начинающий
  • *
  • Сообщений: 9
Добавлю следующее.

Новый ноутбук, новый провайдер. При настройках по умолчанию обрывов связи с интернетом не было, тем не менее скорость как приема, так и передачи была низкой, как и при описанном мной случае годом ранее.
Вопрос решился следующей настройкой сети (без использования терминала):
автосогласование - вручную
дуплекс - полный,
скорость - 100Мб/с.
После этого скорость пришла к заявленным провайдером показателям.

Просто, может, кому-то пригодится.

Оффлайн Nicom

  • Завсегдатай
  • *
  • Сообщений: 621
При настройках по умолчанию обрывов связи с интернетом не было, тем не менее скорость как приема, так и передачи была низкой, как и при описанном мной случае годом ранее.
Что ж это за провайдеры такие, что ставят свитчи без автосогласования в 21 веке?
Может дело в кабелях, или неправильной последовательности проводов при обжимке коннекторов?
100 мегабит вполне себе работают на коротких дистанциях при использовании проводов из разных пар.

Онлайн kessys

  • Завсегдатай
  • *
  • Сообщений: 624
Эта логика тоже имеет право на существование. Поменял железки - поправь persistent-net.rules.
Мне кажется с новыми обновлениями существует действительно новая логика. Я чё-то менял видеокарту, и у меня заделся настроенный Ethernet адаптер, узнал я это очень просто - в домен не смог войти.
О подпись)
Жизнь с kde не так плоха, Но без ssd, это жестоко грустно.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 099
Эта логика тоже имеет право на существование. Поменял железки - поправь persistent-net.rules.
Мне кажется с новыми обновлениями существует действительно новая логика. Я чё-то менял видеокарту, и у меня заделся настроенный Ethernet адаптер, узнал я это очень просто - в домен не смог войти.
С вариантом с persistent-net.rules и привязкой к MAC этого не может быть. Вот если без persistent-net.rules, из расчёта на имя enp*, то сколько угодно. Хотя через persistent-net.rules можно и такое имя задать, но это уже частный случай совсем.

Онлайн kessys

  • Завсегдатай
  • *
  • Сообщений: 624
Эта логика тоже имеет право на существование. Поменял железки - поправь persistent-net.rules.
Мне кажется с новыми обновлениями существует действительно новая логика. Я чё-то менял видеокарту, и у меня заделся настроенный Ethernet адаптер, узнал я это очень просто - в домен не смог войти.
С вариантом с persistent-net.rules и привязкой к MAC этого не может быть. Вот если без persistent-net.rules, из расчёта на имя enp*, то сколько угодно. Хотя через persistent-net.rules можно и такое имя задать, но это уже частный случай совсем.
Как раз да имя уже enp* гуляет, про него и говорю.
О подпись)
Жизнь с kde не так плоха, Но без ssd, это жестоко грустно.