Не поднимается сетевой интерфейс linux

Не поднимаются сетевые карты при загрузке системы.

Ситуация такая,не поднимаются сетевые карты при загрузке системы (миниУбунту 13.04,без гуя).Такая ситуация была на рабочей машине с Минтом 16,когда пробовал через консоль подключиться по АДСЛ.Там всё решилось редактированием /etc/network/interfaces auto lo iface lo inet loopback

Тут это не срабатывает.На мамке 2 сетевые карты ,плюс скрещенные WI-FI+BT. Карты обозначаются как р2р1 и р3р1. Покажу как это выглядит на рабочей системе ,на не рабочей консоль выдаёт тоже самое. ifconfig -a на рабочей системе

eth0 Link encap:Ethernet HWaddr d4:3d:7e:4e:46:46 inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::d63d:7eff:fe4e:4646/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1217687 errors:0 dropped:0 overruns:0 frame:0 TX packets:701012 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1736259330 (1.7 GB) TX bytes:57633920 (57.6 MB)

lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:7280 errors:0 dropped:0 overruns:0 frame:0 TX packets:7280 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1058119 (1.0 MB) TX bytes:1058119 (1.0 MB)

Команда ifconfig -a (на рабочей системе отключена сетевая карта командой ifconfig eth0 down).В примере будет только одна сетевая карта,т.к. в рабочей машине она всего одна (в не рабочей их две,но суть от этого не меняется).

eth0 Link encap:Ethernet HWaddr d4:3d:7e:4e:46:46 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:1218374 errors:0 dropped:0 overruns:0 frame:0 TX packets:701747 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1736676079 (1.7 GB) TX bytes:57755189 (57.7 MB)

lo Link encap:Локальная петля (Loopback) inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:7752 errors:0 dropped:0 overruns:0 frame:0 TX packets:7752 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1093144 (1.0 MB) TX bytes:1093144 (1.0 MB)

На не рабочей же системе при попытке поднять сеть (р2р1 например),выдаёт вот это:

p2p1 Link encap:Ethernet HWaddr MACaddres inet6 addr:fe80::d63d:7eff:fef5:a13c/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:0 TX bytes:398 (398 B)

Судя по выводу этому у меня не устанавливается адрес ,вот такого вида (к примеру):

inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0

При этом в файле /etc/network/interfaces на не рабочей системе сейчас прописано:

auto lo iface lo inet loopback

auto p2p1 iface p2p1 inet dhcp

Прописывал и manual с адресом,маской и гетвеем.Толку ноль. Как быть.

Источник

После перезагрузки серва с Debian через раз поднимаются сетевые интерфейсы..

Доброго времени суток!

Уже больше года есть домашний сервер-роутер на Debian сначала 6, сейчас 7.1, эта проблема с самого начала возникла. Почем-то после перезагрузки или выключения/включения, НЕ ВСЕГДА нормально поднимаются интерфейсы, чаще всего смотрящий в инет, но очень редко смотрящий локалку. Пробовал даже менять сетевые платы местами, и на другую, правда на ту же модель — то же самое. В линуксах начал разбираться с нуля дома, уровень beginner)

Инфа по системе: мать Asrock H61Del с последним биосом 2.0 сетевые платы: 2 дешёвые TP-LINK TG-3468, проц у них Realtek RTL8168B, думаю для домашнего сервера норм вариант, в 10 раз дороже intel без особой необходимости желания покупать нет.

Настройки interfaces, iptables..

iptables (скрипт выполняется при загрузке системы, нашёл в инете, настроил под себя):

Тут вроде всё хорошо, да и с несколько другими настройками на прошлой системе то же самое было.

/etc/init.d/networking restart приводит к падению доступа в инет и ругани:

Когда, после ребута, один из интерфейсов не работает, при попытке поднятия его на сервере командой ifup eth0/eth3 выдаёт снова это «RTNETLINK answers: File exists».

Почему так? Что это за хрень, извините))? Ведь настроек не меняю, выкл,вкл и уже работает (или не работает)..надоело. В чём может быть дело? Что за «RTNETLINK answers: File exists»?

Как временно приемлемый вариант, я бы сделал скрипт, проверяющий состояние обоих интерфейсов, и в случае неполадок, отправляющий серв в ребут (потому что бывает не из дома подключаюсь, напр. из другого города). Только как его написать, кто бы помог))

Состояние интерфейсов можно посмотреть командой ip link Адреса IP можно посмотреть командой ip addr Маршруты — ip route

RTNETLINK answers: File exists мне обычно вылетало когда маршрут/ip-адрес из конфликтующих подсетей уже был прописан.

Проверьте чтоб у вас интерфейсы не конфликтовали.

с настройками интерфейсов и состоянием сейчас вроде всё ок, работает.. непонятно то, почему с перезагрузкой через раз нормально восстанавливается работа интерфейсов.. подскажите, куда обратить внимание, что может вызывать конфликт.. так вроде основные настройки выложил.

У меня встроенная: 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)

Иногда после перезагрузки/включения не включается, в ip li пишет флаг NO-CARRIER.

Я подозреваю скрипты инициализации, которые иногда не в том порядке или не так выполняются, в результате чего поднятие интерфейса не срабатывает.

(На всякий случай) Что у тебя в /etc/udev/rules.d/70-persistent-net.rules ? Карты и интерфейсы совпадают?

Устройства при запуске не переименовываются? Ничего в сислоге нет?

завтра уже попробую ip li, сегодня не буду возиться. Я тоже подозреваю, что где-то какие-то скрипты по разному отрабатывают.. но почему так, и если бы кто знал где и какие же конкретно могут к такому приводить.

вот что выдаёт (всё верно, в системе побывало 4 сетевые карты), совпадает.. в сислоге завтра поковыряюсь.

Да, но теперь обрати внимание на то, какие интерфейсы будут у тех, что стоят. Видишь в этом файле есть MAC-адрес, а последний параметр — это интерфейс. Можешь сопоставить.

НЕ ВСЕГДА нормально поднимаются интерфейсы

очень похоже на гонки (aka race), ядро определяет карточки одновременно, потому какая из них станет eth0 предсказать невозможно.

Take a look at /etc/udev/rules.d/70-persistent-net.rules and verify that the rule for your card (check its MAC) is consistent with the naming scheme you want.

You can easily edit that file or even remove it if you want to regenerate it from scratch.

от себя добавлю, что посмотреть на это можно в dmesg

в сислоге нашёл момент определения карточек,

почистил файл /etc/udev/rules.d/70-persistent-net.rules, сгенерировался по новой, посмотрю что будет, но по-моему проблема не решена, т.к. только что, сразу после регенерации, изменения настройек и ребута, инета снова не было, пришлось второй раз ребутить.

dmesq по идее с момента первого появления интерфейсов, в этом случае инет не поднялся: http://www.ex.ua/289682750771

Поменяй allow-hotplug на auto :

А мне кажется, проблема в драйвере r8169 (не всегда корректно работает с некоторыми карточками)

Есть ещё r8168-dkms, пробовали его?

У меня кстати та же хня на centos-е, так и не победил, успокоился — не так часто я на на нем сетку дергаю, чаще просто выключаю и включаю.

А где auto в настройках интерфейсов?

Правила iptables подгружают в /etc/network/interfaces командой pre-up

echo «1» > /proc/sys/net/ipv4/ip_forward

echo «1» > /proc/sys/net/ipv4/ip_dynaddr

устанавливают тут /etc/sysctl.conf

Зачем шлюзу указывать шлюз. Эта строка лишняя:

dmesq по идее с момента первого появления интерфейсов, в этом случае инет не поднялся: http://www.ex.ua/289682750771

там глянь какие-же получаются в итоге MAC в рабочем и в не рабочем случае. Сами интерфейсы вроде не переименовывает как я думал.

Проблемы с /etc/udev/rules.d/70-persistent-net.rules возникают только при замене или добавлении карточек

Зачем ты указываешь 2 гейтвея? Видимо, через раз то один раньше устанавливается, то другой. Когда правильный — работает, когда неправильный — не работает.

при попытке поднятия его на сервере командой ifup eth0/eth3 выдаёт снова это «RTNETLINK answers: File exists»

Это ерунда, это означает, что такой адрес или маршрут уже назначен на интерфейс. Это сообщение не должно вести к проблемам.

Сравините вывод команд: ip link; ip addr; ip route для случая работающией и не работающей сетёвки. Если они одинаковые, то значит проблема не в ifup.

Посмотрите, в случае не работающей сетёвки, работает ли arping и tcpdump на этом интерфейсе. Если tcpdump на локальном интерфейсе, то с другого компьютера запустите пинг сервера, если на интерфейсе провайдера, то там обычно в сети достаточно много пакетов летает.

Ну ещё можно сравнить вывод ″ethtool eth0″ для работающего и не работающего случаев, попробовать в неработающем случае переключить сетёвку в 10 Мбит Half-duplex.

убери gateway 192.168.0.1

Есть ещё r8168-dkms, пробовали его

спасибо за подсказку, нет, не пробовал.. на счёт драйвера конечно мысль пробегала, но как его переустановить, не знаю..поможете? Думаю там пара команд..

Правила iptables подгружают в /etc/network/interfaces командой pre-up

echo «1» > /proc/sys/net/ipv4/ip_forward echo «1» > /proc/sys/net/ipv4/ip_dynaddr устанавливают тут /etc/sysctl.conf

это знаю, в прошлой системе не помню, как именно правила подгружались, а ip_forward было указано в /etc/sysctl.conf, и тот же результат, ip_dynaddr мне по идее вообще не нужен, просто ещё не убрал. Выход в инет же с сервера пропадает, а не только с локалки, так что не от сюда проблема, думаю. По поводу правил iptables, просто в таком скрипте мне их проще редактировать, а разве принципиально, откуда они будут грузиться?

убрал и вот уже пятый раз успешный ребут. Это конечно не 100% показатель, вчера подряд раз 10 так и потом снова. Проверяю дальше.. Если проблема в этом, то это я здорово тупанул..

следующий вариант, если последний не сработал)

— правила iptables должны загружаться до поднятия интерфейсов и в приведенных правилах есть некоторые косяки, загружают их из файла, путем команды pre-up /etc/skript/iptables, указанной в /etc/network/interfaces

— запись в кроне */5 * * * * root ifup eth1 > /dev/null 2>&1 аналогична команде allow-hotplug

Проблемы скорее всего были из-за двух гейтвеев по умолчанию

Сравините вывод команд: ip link; ip addr; ip route для случая работающией и не работающей сетёвки. Если они одинаковые, то значит проблема не в ifup

1. Не работает.. (со стороны инета -> eth1)

2. Инет работает..

Вижу NO-CARRIER у неработающего интерфейса; так же в этом случае ему не назначается ipv6 адрес (мне в принципе не нужен, но..). Что это может быть.

нет, не в гейтвеях была.. на седьмой раз снова интерфейс не поднялся.

А что в маршрутах netstat -rn ?

Можно попробовать перенести настройки c eth3 на eth1, и c eth1 на eth3. Чтоб инетовски интерфейс запускался первым.

Вот такая же проблема, решена сменой сетевухи как настроить PPPoE в Debian?

запись в кроне */5 * * * * root ifup eth1 > /dev/null 2>&1 аналогична команде allow-hotplug

этого я не понимаю..))

/etc/network/interfaces привёл в вид:

убрал скрипт с настройками iptables firewall.sh из автозапуска, в /etc/sysctl.conf раскомментировал net.ipv4.ip_forward=1.

Можно попробовать перенести настройки c eth3 на eth1, и c eth1 на eth3. Чтоб инетовски интерфейс запускался первым.

уже менял, дело в том, что раньше было наоборот, сначала инет, потом сеть, а это изменённый вариант, как видно из настроек, которые выкладываю.

Источник

Заметки Лёвика

web программирование, администрирование и всякая всячина, которая может оказаться полезной

Ubuntu не получает адрес, не поднимается сетевой интерфейс, не работает DHCP

При подключении кабелем к сети (роутеру) старого компьютера странным образом выяснилось, что “не работает”.. Хотя.. “раньше работало”.
Проверки работоспособности кабеля (подключение к компу с Windows) неполадок не выявили.

Ubuntu Network Speed and full or half duplex LAN

DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 32
DHCPDISCOVER on eth1 to 255.255.255.255 port 67 interval 19
No DHCPOFFERS recieved

auto lo
iface lo inet loopback
#
auto eth0
iface eth0 inet dhcp

auto eth0
iface eth0 inet manual
pre-up ip link set dev «$» up
pre-up dhclient -nw -pf /var/run/dhclient.»$«.pid -lf /var/lib/dhcp3/dhclient.»$«.leases «$»
#
pre-down dhclient -pf /var/run/dhclient.»$«.pid -lf /var/lib/dhcp3/dhclient.»$«.leases -r «$»
pre-down ip link set dev «$» down

Редактирование /etc/nework/interfaces (помимо строчек про lo — установка DHCP для eth0). а также редактирование /etc/dhcp3/dhcp — прописанный MAC-адрес — результата не дали.
Не помогли.. Светодиод на сетевой карте не подавал признаков жизни.

Если индикатор сетевой карты не светится, это может говорить о следующем:

1. Компьютер или коммутатор не включены.
2. Неисправна сетевая карта.
3. Неисправен порт коммутатора.
4. Возможно плохой контакт в коннекторе, или коннектор вставлен в гнездо не до конца.
5. Поврежден кабель.
6. Перепутаны провода при обжиме коннекторов.

Как ни банально, реальной причины в этом списке не было.

For example, a network card with a solid green LED or light usually indicates that the card is either connected or receiving a signal. If the green light is flashing, this is an indication of data being sent or received. The picture to the right is an example of a LAN port with two LED indicators next to the RJ-45 port. With this port, one LED will light up if connected properly and the other will flash when transmitting data.

Светодиод на сетевой карте не горит и не мигает
На световой карте в зависимости от конфигурации
Зелёный показывал питание, оранжевый — подключение 10Мбит, красный — 100Мбит. Либо зелёный — 100мбит.
“Моргающие” светодиоды означают передачу данных

Стоят нужные драйвера, сетевуха определяется в диспетчере устройств, а сетевой кабель не видит, причем светодиоды на кабеле также не мигают.

Предположительная проблема — если на одном из устройств (роутер или компьютер) установлена неподдерживаемая другим скорость передачи данных.

sudo apt-get install ethtool net-tools

Далее — смотрим вывод
sudo ethtool eth0 Но, поскольку сети не было, пришлось разбираться, Как установить sudo apt-get install ethtool без интернета.. В общем-то, не так уж сложно скачать с официального сайта пакет ethtool.deb и открыть его при помощи менеджера пакетов.

ethtool -s eth0 autoneg on

Устанавливаем режим 100Мбит полный дуплекс

ethtool -s eth0 speed 100 duplex full autoneg off

Опубликовано Вторник, Март 10, 2015 в 15:39 в следующих категориях: Без рубрики. Вы можете подписаться на комментарии к этому сообщению через RSS 2.0. Вы можете оставить комментарий. Пинг отключен.

Автор будет признателен, если Вы поделитесь ссылкой на статью, которая Вам помогла:
BB-код (для вставки на форум)

html-код (для вставки в ЖЖ, WP, blogger и на страницы сайта)

ссылка (для отправки по почте)

1 комментарий к записи “Ubuntu не получает адрес, не поднимается сетевой интерфейс, не работает DHCP”

ethtool -s eth0 speed 100 duplex full autoneg off

Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full

Источник