Решено: Изменение номера сетавого интерфейса

[sus1n]

Установил opensuse 10.2, попытался настроить сеть и столкнулся с такой проблемой:
После настройки сетевой карты через yast появился доступ к компьютерам подсети (пинг проходит), но после перезагрузки номер сетевого интерфейса eth0 меняется на eth1 и соотв. сеть перестает работать.
После повторной настройки интерфейса (уже eth1) и последующей перезагрузки номер меняется на eth2 ну и т.д.

В чем может быть проблема?

ps
В настройках YaST редактировал настройки существующей сетевой карты.
Мат. плата Gigabyte GA-K8N51GMF (nForce6100)
nVIDIA MCP51 - LAN Controller

[Nikkes]

Посмотри, не меняется ли MAC адрес сетевухи.
Попробуй в конфиге сетевухи убрать из названия файла mac-адрес

[sash-kan]

sus1n
grep -r eth[012] /etc/udev/
?

[sus1n]

Имея ввиду что недавно пользуюсь suse и linux вообще, возможно что я не совсем понял ваши советы.
сделал

grep -r eth[012] /etc/udev/

имею следующее

/etc/udev/rules.d/30-net_persistent_names.rules:SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:20:ed:b9:8a:79", IMPORT="/lib/udev/rename_netiface %k eth0"
/etc/udev/rules.d/30-net_persistent_names.rules:SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:20:ed:af:44:9c", IMPORT="/lib/udev/rename_netiface %k eth1"
/etc/udev/rules.d/30-net_persistent_names.rules:SUBSYSTEM=="net", ACTION=="add", SYSFS{address}=="00:20:ed:b6:42:76", IMPORT="/lib/udev/rename_netiface %k eth2"

что из этого следует?

Попробуй в конфиге сетевухи убрать из названия файла mac-адрес

Если не трудно поподробней, это где?

[sash-kan]

что из этого следует?

↑

сотри все эти строки и в следующий раз первая сетевая опять станет eth0
или поменяй mac-адрес у нужной записи.

[sus1n]

Все равно ничего не понял как менять mac адрес сетевухи и откуда стирать

все эти строки

[LU™]

Все равно ничего не понял как менять mac адрес сетевухи и откуда стирать

в файле /etc/udev/rules.d/30-net_persistent_names.rules

[sus1n]

Стер...
перезагружаюсь номер интерфейса становится eth0
далее

Код: Выделить всё

# /sbin/ifconfig eth0 172.26.24.24 netmask 255.255.255.0 up
# route add -host 192.168.253.1 gw 172.26.24.1

где 172.26.24.24 мой ip
192.168.253.1 адрес vpn сервера
172.26.24.1 шлюз
Далее устанавливаю соединение посредством kvpnc (все работает)
После перезагрузки eth0 снова меняется на eth1 и соединение надо настраивать заново уже на eth1... вобщем вернулся к тому с чего начал (

[k0da]

Это не в вмваре случаем?

[sus1n]

Нет, но suse установлена как вторая ос (первая winXP)

[k0da]

попробуйте переименовать
/etc/sysconfig/network/ifcfg-blah-blah в /etc/sysconfig/network/ifcfg-eth0

[sus1n]

Переименовал, затем стер все записи из /etc/udev/rules.d/30-net_persistent_names.rules
Перезагрузился, затем настроил соединение через eth0, как было описано ранее.
После очередной перезагрузки eth0 снова изменился на eth1.

[fed71]

Возможно глючит НетворкМенеджер. Попробуй в ясте Сетевые устройства-Сетевые платы выбрать Традиционный метод ifup

[RogerZ]

Возможно глючит НетворкМенеджер. Попробуй в ясте Сетевые устройства-Сетевые платы выбрать Традиционный метод ifup

Да, сам намучился с сетевыми интерфейсами, пока не стал пользоваться ifup вместо NetworkManager'a. Недоделанный он какой-то.

[sus1n]

ifup был включен изначально, так что скорее всего не в этом дело

[k0da]

ааа 6100?
Была такая проблема она проявляется при совместном использовании с WinXP Решение (не пользоваться им да и решение я давал гдето здесь на форуме)

[sus1n]

Пока в голову приходит только одно решение- стирать лишнее из /etc/udev/rules.d/30-net_persistent_names.rules перед каждым выходом из системы, но по моему это выглядит как то криво, типа заметаем мусор под стол.
Еще хотел узнать на чем основывается утверждение, что проблема в чипсете... есть статистика или это официальная информация от novell?
Хочу все таки докопаться до истины и постараться решить проблему )

[sash-kan]

sus1n
я так понял, что сетевая карта при каждой загрузке получает новый mac-адрес.
по крайней мере такой вывод можно сделать из приведенного отрывка из /etc/udev/rules.d/30-net_persistent_names.rules
это так и есть?

[sash-kan]

Пока в голову приходит только одно решение- стирать лишнее из /etc/udev/rules.d/30-net_persistent_names.rules перед каждым выходом из системы, но по моему это выглядит как то криво, типа заметаем мусор под стол.

прямее будет подправить скрипт, который формирует содержимое этого файла.
у меня (debian) прямо в файле первой строчкой написано:
# This file was automatically generated by the /lib/udev/write_net_rules
в твоей системе, скорее всего, скрипт будет лежать где-нибудь в другом месте.

а может быть будет достаточно просто заменить сгенерированную строку на
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="mac-адрес сетевой", NAME="eth0"
у меня именно такая строчка генерируется.
если, конечно, mac-адрес не меняется при каждой загрузке.

[sus1n]

Да, mac адрес действительно меняется при перезагрузке.
Вот только не понятно почему.

[sash-kan]

Да, mac адрес действительно меняется при перезагрузке.
Вот только не понятно почему.

вот здесь-то собака и порылась.
раз меняется практически единственное средство для идентификации сетевой карты, никакая привязка имени интерфейса, выполняемая udev-ом, не прокатывает.
возможно, имеет смысл попробовать указывать конкретный mac-адрес при подъеме интерфейса.

[sus1n]

Проблема все таки решена )
Крутились мы где то близко, так что опишу чуть подробней мои действия
после более внимательного просмотра файла /etc/udev/rules.d/30-net_persistent_names.rules обнаружилось:

Код: Выделить всё

# This rules are autogenerated from /lib/udev/rename_netiface.
....
#See also /etc/udev/rules.d/31-net_create_names.rules.
# Read /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names for
# further information.

файл /lib/udev/rename_netiface ничего не прояснил, файл /etc/udev/rules.d/31-net_create_names.rules заинтересовал меня больше, но все равно не то, а вот в файле /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names был описан вариант изменения правил присвоения номера сетевого интерфейса. Впрочем это, то как я это понял с моим плохим английским. Там предлагалось следующее:

If you want to disable this mechanism you may choose FORCE_PERSISTENT_NAMES=no
in /etc/sysconfig/network/config. You may also delete the rules in 3*-net* or
delete the whole files, but then rcnetwork will take some seconds longer. So
better disable it via FORCE_PERSISTENT_NAMES=no or much better use it.

Что я собственно и сделал, (добавил FORCE_PERSISTENT_NAMES=no) после чего eth0 после перезагрузки уже не меняется и сеть работает.
Всем спасибо за помощь.

[NiKoLa_N]

Проблема все таки решена )
Крутились мы где то близко, так что опишу чуть подробней мои действия
после более внимательного просмотра файла /etc/udev/rules.d/30-net_persistent_names.rules обнаружилось:

Код: Выделить всё

# This rules are autogenerated from /lib/udev/rename_netiface.
....
#See also /etc/udev/rules.d/31-net_create_names.rules.
# Read /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names for
# further information.

файл /lib/udev/rename_netiface ничего не прояснил, файл /etc/udev/rules.d/31-net_create_names.rules заинтересовал меня больше, но все равно не то, а вот в файле /usr/share/doc/packages/sysconfig/README.Persistent_Interface_Names был описан вариант изменения правил присвоения номера сетевого интерфейса. Впрочем это, то как я это понял с моим плохим английским. Там предлагалось следующее:

Что я собственно и сделал, (добавил FORCE_PERSISTENT_NAMES=no) после чего eth0 после перезагрузки уже не меняется и сеть работает.
Всем спасибо за помощь.

Спасибо за тему!
Пришлось несколько раз столкнуться с тем же самым.
ИМХО, заслуживает помещения в "простые решения".

[Slimy]

Спасибо за тему!
Пришлось несколько раз столкнуться с тем же самым.
ИМХО, заслуживает помещения в "простые решения".

+1

[gregi]

Подскажите а как это применить в Дебиан 4.03, та же проблема.....

[andro_id]

а если просто в /etc/udev/rules.d/*-net_persistent_names.rules удалить строку(строки) с интерфейсом, который переименовывается и перезагрузиться?

[ZayDen]

Подскажите а как это применить в Дебиан 4.03, та же проблема.....

ага и на CentOS и RHEL тоже, всё обрыл не нашёл