Проблема с Сетевым соединением Ethernet во время запуска в Ubuntu 18.04
Иногда Ubuntu 18.04 не соединяется с Сетью во время запуска. Я должен перезагрузить 1 или 2 раза для соединения правильно. Проводное соединение Ethernet.
Какое-либо предложение о том, как разрешить эту проблему без перезапуска?
sudo lshw -C network
[sudo] password for user:
*-network
description: Ethernet interface
product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
vendor: Realtek Semiconductor Co., Ltd.
physical id: 0
bus info: pci@0000:08:00.0
logical name: enp8s0
version: 07
serial: 00:13:3b:2f:54:58
size: 100Mbit/s
capacity: 1Gbit/s
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress msix vpd bus_master cap_list ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=2.3LK-NAPI duplex=full firmware=rtl8168e-3_0.0.4 03/27/12 ip=1xx.1xx.1.2 latency=0 link=yes multicast=yes port=MII speed=100Mbit/s
resources: irq:19 ioport:a000(size=256) memory:fe400000-fe400fff memory:d0000000-d0003fff
ifconfig
Command 'ifconfig' not found, but can be installed with:
sudo apt install net-tools
cat /etc/netplan/*.yaml
# Let NetworkManager manage all devices on this system
network:
version: 2
renderer: NetworkManager
ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:13:3b:2f:54:58 brd ff:ff:ff:ff:ff:ff
inet 1xx.1xx.1.2/24 brd 1xx.1xx.1.255 scope global dynamic noprefixroute enp8s0
valid_lft 85762sec preferred_lft 85762sec
inet6 2a02:2149:8671:6c00:95d5:5075:c66d:a36e/64 scope global temporary dynamic
valid_lft 70680sec preferred_lft 27480sec
inet6 2a02:2149:8671:6c00:b5ed:32e1:2fd2:2ee/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 70680sec preferred_lft 27480sec
inet6 fe80::c3c:4354:23e7:410f/64 scope link noprefixroute
valid_lft forever preferred_lft forever
tracepath www.google.com
1?: [LOCALHOST] 0.010ms pmtu 1492
1: 2a02:2149:816a:5400:a6b1:e9ff:fe30:d40 1.069ms
1: 2a02:2149:816a:5400:a6b1:e9ff:fe30:d40 1.061ms
2: bbras-llu-kln-15L500.forthnet.gr 46.737ms
3: Te-0-0-0-7.distr-kln-02.forthnet.gr 24.145ms
4: BE3.core-kln-03.forthnet.gr 24.236ms
5: Xe2-0-1.core-lsf-09.forthnet.gr 32.092ms
6: xgei0-2-0-5.core-tpn-01.forthnet.gr 38.102ms
7: no reply
8: no reply
9: no reply
10: no reply
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
Too many hops: pmtu 1492
Resume: pmtu 1492
2 ответа
После долгого согласования с ISP заключение состоит в том, что проблема низкой скорости происходит из-за технических причин с их стороны. Интернет-скорость увеличилась немного, но это все еще далеко от оптимального уровня VDSL.
Однако это остается тем, что Ubuntu 18.04.2, которую LTS не подключает повторно автоматически к Сети, в случае, если интернет-соединение будет уволенный по различным причинам. Так, я нашел, что обходное решение постаралось не перезапускать, когда Интернет разъединяется. Я открываю меню в верхнем правом из экрана и выбираю "Проводное соединение". Я нажимаю "Turn off" и затем "Подключение". Таким образом, интернет-соединение вернулось.
Я вижу три возможных проблемы...
1. У Вас есть сетевая плата 1G, которую это только подключает в (speed=100Mbit/s). Это обычно - кабельная проблема, но это могла быть проблема с маршрутизатором/модемом (в Вашем случае).
Вытяните РАЗЪЕМ ПИТАНИЯ и от маршрутизатора/модема И ОТ ПК. Количество к 15. Включите маршрутизатор/модем назад в питание переменным током. Количество к 30. Включите ПК назад в питание переменным током. Выйдите sudo lshw -C network команда, и наблюдает speed значение. Это должна быть 1G (не 100Mbits/s). Если это - 1G, повторите свой Интернет и посмотрите, работает ли это правильно.
Если это не решит проблему, то мы должны будем попробовать кабель Ethernet DIFFERNET. Затем подвергните циклу включения и выключения питания все снова и перетест, как выше.
2. Ваш MTU = 1500, который может быть неправильным при VDSL. Во-первых, свяжитесь со своим ISP и спросите, что они рекомендуют для настроек MTU. Я буду также включать процедуру так, чтобы можно было определить для себя..., и можно соответствовать ей информации ISP.
Вы захотите протестировать свое соединение путем попытки достигнуть различных веб-сайтов, и также путем выполнения тестирования скорости сети (http://speedtest.net), прежде и после изменения MTU.
У Вас может быть проблема с установкой MTU для Вашего соединения VDSL.
Существует установка MTU в конфигурации сети Ubuntu и установка WAN MTU в Вашем маршрутизаторе.
Для DSL общая установка MTU является 1492. Просто разрешение и попытка, которую видит это значение сначала и доступны ли Ваши веб-сайты теперь.
Для определения корректной установки запустите со всех настроек MTU = 1500 и VPN = прочь. (VPN требует другого тестирования).
В терминале:
ping [-c count] [-M do] [-s packet_size] [host]
Используемые опции:
c count: количество раз для проверки с помощью ping-запросовM hint: Избранный Путь стратегия Исследования MTU. может быть такжеdo(запретите фрагментацию, даже локальную),want(сделайте исследование PMTU, фрагмент локально, когда размер пакета будет большим), илиdont(не устанавливайте флаг DF).s packet_size: Указывает число байтов данных, которые будут отправлены.
Необходимо всегда запускать в 1472 и прокладывать себе путь вниз к 10 каждым разам. После того как Вы получаете ответ, поднимаетесь на 1, пока Вы не получаете фрагментированный пакет. Примите, который значение (длятся хорошее значение) и добавляет 28 к значению для составления различных заголовков TCP/IP. Например, скажем, тот 1452 был надлежащим размером пакета (где Вы сначала получили ответ ICMP на свой ping). Фактический размер MTU был бы 1480, который является оптимумом для сети, с которой мы работаем.
ping -c 4 -M do -s 1472 8.8.8.8 # this will probably show fragmentation
ping -c 4 -M do -s 1462 8.8.8.8 # may show fragmentation
ping -c 4 -M do -s 1452 8.8.8.8 # no fragmentation?
ping -c 4 -M do -s 1453 8.8.8.8 # still no fragmentation?
ссылка: Как определить надлежащий размер MTU с ping ICMP
3. Вы используете r8169 драйвер (driver=r8169), и мы, возможно, должны переключиться на r8168-dkms драйвер. Больше информации незаконченные результаты шага № 1.