теперь не удается получить IP-адрес от DHCP на модеме - что изменилось?
У меня есть DSL-модем, который делает DHCP, который кажется здоровым, потому что я могу подключить к нему другие хосты и получить IP-адреса, но не мой обычный компьютер.
После выхода на неделю, при загрузке, он не смог получить IP-адрес. Затем я попробовал все это, и у меня получился IP-адрес, однако он был очень медленным или удалял большинство пакетов, и я не мог использовать его для просмотра в Интернете.
Дальнейшие перезагрузки, а циклы ifdown / ifup просто прекращаются прямо сейчас.
Я знаю, что это не модем или кабель, потому что могут подключаться другие ПК.
Я не думаю, что это сетевой адаптер, потому что у меня есть второй сетевой адаптер, который также не получит IP-адрес.
Я тоже отключил брандмауэр, который не помог.
Он работает 16.04.3
Мое единственное предположение, что я обновил сетевой пакет, который теперь требует некоторой настройки - возможно, dhclient. Я не управляю сетевым менеджером, это довольно простая конфигурация.
В журналах ничего нет, кроме чего-то по этим линиям (скопировано с экрана вручную):
Sep 8 23:40:27 gondor kernel: [ 495.11235] e1000e: enp0s25 NIC Link is Up 100 Mbps Full Duplex, Flow Control: Rx/Tx
Sep 8 23:40:27 gondor kernel: [ 495.11235] e1000e: enp0s25 NIC Link is Down
, который повторяется несколько раз, в то время как ifup работает.
Могу ли я повредить конфигурацию сети, установив или обновив пакет?
/ etc / network / interfaces:
auto lo
iface lo inet loopback
auto enp0s25
allow-hotplug enp0s25
iface enp0s25 inet dhcp
[UPDATE] lshw -C network вывод в соответствии с запросом:
*-network
description: Ethernet interface
product: 82567LF Gigabit Network Connection
vendor: Intel Corporation
physical id: 19
bus info: pci@0000:00:19.0
logical name: enp0s25
version: 03
serial: 00:01:80:76:c5:39
size: 100Mbit/s
capacity: 1Gbit/s
width: 32 bits
clock: 33MHz
capabilities: pm msi bus_master cap_list ethernet physical tp 10bt 10bt-fd 100bt 100bt-fd 1000bt-fd autonegotiation
configuration: autonegotiation=on broadcast=yes driver=e1000e driverversion=3.2.6-k duplex=full firmware=1.8-3 ip=86.139.80.140 latency=0 link=yes multicast=yes port=twisted pair speed=100Mbit/s
resources: irq:25 memory:fdfc0000-fdfdffff memory:fdfff000-fdffffff ioport:fe00(size=32)
3 ответа
Ваша проблема связана с настройкой MTU для вашего DSL-соединения.
Для DSL общий параметр MTU - 1492. Просто попробуйте это сначала и посмотрите, доступны ли ваши веб-сайты.
Чтобы определить правильную настройку, начните со всех настроек MTU = 1500 и VPN = выключите. (VPN требует другого тестирования).
В терминале:
ping [-c count] [-M do] [-s packet_size] [host]
Используемые параметры:
c count: количество раз для пинга M hint: Выберите Path MTU Discovery. может быть либо do (запретить фрагментацию, даже локальную), want (сделать обнаружение PMTU, фрагмент локально, когда размер пакета велико), или dont (не устанавливать флаг DF). s packet_size: Указывает количество отправляемых байтов данных.Вы всегда должны начинать с 1472 и каждый раз прокладывать свой путь на 10. Как только вы получите ответ, поднимитесь на 1, пока не получите фрагментированный пакет. Возьмите это значение (последнее хорошее значение) и добавьте 28 к значению для учета различных заголовков TCP / IP. Например. скажем, что 1452 был правильным размером пакета (где вы впервые получили ответ ICMP на ваш пинг). Фактический размер 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 с помощью ICMP-пингов
-
1Спасибо, что у вас есть время & amp; терпение придерживаться меня на этом! Просто просмотрел несколько старых писем, чтобы понять, почему я установил MTU на 1500, в первую очередь & amp; обнаружил, что старый модем, который я сейчас использую, имеет внутреннюю настройку iptables в своем ядре linux, привязывая MTU к модему к 1450. Несколько вопросов, которые действительно сделают ваш ответ идеальным: (1) каково максимальное значение MTU? Сначала вы говорите, что начинаются с 1500, тогда вы говорите, начинаете с 1472. Могу ли я начать все выше? Каков причинный фактор здесь? (2) Почему это предотвращает обнаружение DHCP? Никогда раньше это не вызывало других проблем, но не этого. – Adam 10 September 2017 в 18:31
-
21) максимальный MTU - это то, что может поддерживать ваш DSL-модем и интернет-провайдер. 1500 является стандартом для не DSL-соединений. Если вы заметили разницу между 1500 и 1472, это 28 ... число, которое вы добавляете к последней рабочей команде ping. И пинг при 1472 должен потерпеть неудачу, если ваш модем привязан к 1450. 2) Я не могу сказать точно. Возможно, что-то в сетевом программном обеспечении Ubuntu изменилось, или они, возможно, обновили прошивку в вашем исходном модемом. – heynnema 10 September 2017 в 18:42
-
3Не могли бы вы хотя бы попробовать адаптировать свой ответ к специфике задаваемого вопроса? Может быть, добавить небольшой пояснительный текст? Как изменить эти настройки? Что-то , которое мешает системе помечать их? Мы уже закончили это и да, я вижу, как это отвечает на оба вопроса, но, пожалуйста, приложите немного усилий, чтобы убедиться, что они настроены по каждому вопросу. – terdon♦ 11 September 2017 в 19:20
Ваша проблема связана с настройкой MTU для вашего DSL-соединения.
Для DSL общий параметр MTU - 1492. Просто попробуйте это сначала и посмотрите, доступны ли ваши веб-сайты.
Чтобы определить правильную настройку, начните со всех настроек MTU = 1500 и VPN = выключите. (VPN требует другого тестирования).
В терминале:
ping [-c count] [-M do] [-s packet_size] [host]
Используемые параметры:
c count: количество раз для пинга M hint: Выберите Path MTU Discovery. может быть либо do (запретить фрагментацию, даже локальную), want (сделать обнаружение PMTU, фрагмент локально, когда размер пакета велико), или dont (не устанавливать флаг DF). s packet_size: Указывает количество отправляемых байтов данных.Вы всегда должны начинать с 1472 и каждый раз прокладывать свой путь на 10. Как только вы получите ответ, поднимитесь на 1, пока не получите фрагментированный пакет. Возьмите это значение (последнее хорошее значение) и добавьте 28 к значению для учета различных заголовков TCP / IP. Например. скажем, что 1452 был правильным размером пакета (где вы впервые получили ответ ICMP на ваш пинг). Фактический размер 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 с помощью ICMP-пингов
Ваша проблема связана с настройкой MTU для вашего DSL-соединения.
Для DSL общий параметр MTU - 1492. Просто попробуйте это сначала и посмотрите, доступны ли ваши веб-сайты.
Чтобы определить правильную настройку, начните со всех настроек MTU = 1500 и VPN = выключите. (VPN требует другого тестирования).
В терминале:
ping [-c count] [-M do] [-s packet_size] [host]
Используемые параметры:
c count: количество раз для пинга M hint: Выберите Path MTU Discovery. может быть либо do (запретить фрагментацию, даже локальную), want (сделать обнаружение PMTU, фрагмент локально, когда размер пакета велико), или dont (не устанавливать флаг DF). s packet_size: Указывает количество отправляемых байтов данных.Вы всегда должны начинать с 1472 и каждый раз прокладывать свой путь на 10. Как только вы получите ответ, поднимитесь на 1, пока не получите фрагментированный пакет. Возьмите это значение (последнее хорошее значение) и добавьте 28 к значению для учета различных заголовков TCP / IP. Например. скажем, что 1452 был правильным размером пакета (где вы впервые получили ответ ICMP на ваш пинг). Фактический размер 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 с помощью ICMP-пингов