TH udev i zamiana interface eth0 z eth1

[Bartosz Lis]

On Tuesday 17 of April 2012 09:24:09 Łukasz Maśko wrote:
> Dnia wtorek, 17 kwietnia 2012, Paweł Kośka napisał:
> > 2012/4/16 Paweł Kośka <pawel w viop.pl>:
> > > W dniu 16 kwietnia 2012 16:41 użytkownik Paweł Kośka <pawel w viop.pl>
> > > napisał:
> > > 
> > > 
> > > Interface od vlanów też zmienia nazwę;)
> > > Łukasz obadam też Twoją wersję.
> > 
> > No i ciągle jest źle....
> > Ale już sytuacje naprawiłem, wyciągnąłem drugą sieciówkę i już system
> > nie ma problemu z nazwami ;)
> 
> Cokolwiek dziwne. U mnie działa już wiele miesięcy i nie zdarzyło się, że
> system źle zaskoczył.

Witam,

Opisany problem pojawiaja się na 100%, gdy ma się więcej niż jedną sieciówkę 
kontrolowaną przez ten sam moduł jądra lub sieciówkę wieloportową. Wtedy przy 
ładowaniu modułu na raz pojawia się więcej niż jeden interfejs. Np. na raz 
pojawiają się eth0 i eth1. 

Załóżmy że admin, chciał aby intefejsy sieciowe dostawały kolejne nazwy w/g 
fizycznego położenia na obudowie idąc od lewej do prawej (lub z góry na dół). 
Tymczasem moduł wstępnie nazywa karty eth0 i eth1 nie wiedząc nic o fizycznym 
położeniu interfejsów na obudowie/śledziu. Mamy scenariusz:

krok 1. Moduł jądra wykrywa dwa interfejsy i wstępnie je nazywa. Załóżmy że  
wstępne nazwy zostały przydzielone odwrotnie, niż by chciał admin.
krok 2. Jądro wysyła zdarzenia do UDEVa, że zainicjowało urządzenia sieciowe.
krok 3. Teraz następuje faza modyfikacji nazw przez UDEVa na podstawie MACów. 
Niestety nazwy eth0 nie można zmienić na eth1, bo ta już jest zajęta przez 
interfejs, który dla odmiany powinien nazywać się eth0, ale też nie może być 
przezwany, bo obie nazwy zostały nadane jednocześnie w kroku 1.

W sytuacji, gdy każdy interfejs jest kontrolowany przez osobny moduł jądra 
(jak w pierwszym poście tego wątku) według mnie występuje wyścig (nie badałem 
tego w źródłach jądra, ale z własnych obserwacji tak sądzę). Moduł wstępnie 
nazywa interfejs w trybie kernela i generuje zdarzenie do udeva w userlandzie. 
Może się tak zdarzyć, że przed obsłużeniem tego zdarzenia przez UDEV jądro 
zacznie inicjować następny moduł. Mamy wtedy zasadniczo dwa scenariusze:

A. W jednych skrzynkach pierwszy moduł nadaje wstepną nazwę pierwszemu 
interfejsowi a UDEV ją zmienia ZANIM drugi moduł nada wstępną nazwę drugiemu 
interfejsowi. Wtedy wszystko jest OK.

B. W innych skrzynkach wyścig rozstrzyga się pechowo: transmisja zdarzeń do 
userlandu trwa wolniej i udev przystępuje do zmieny nazw dopiero wtedy, gdy 
oba moduły już wstępnie nazwały swoje interfejsy (odwrotnie niż w ustawieniach 
UDEVa) i nawzajem blokują sobie zmianę nazw. 

Moje wyjście z tego impasu jest takie, że poprzez UDEV zmieniam nazwy kart 
sieciowych na n0, n1, n2, n3 itd. Tak naprawdę może być cokolwiek innego niż 
eth[0-9]+ . W zasadzie można by pójść krok dalej i nazywać interfejsy bardziej 
opisowo: n_lan, n_dmz, n_isp, itp.

Pozdrawiam,

-- 
Bartosz Lis

[pl] Instytut Informatyki Politechniki Łódzkiej
[en] Institute of Information Technology, Technical University of Lodz
Wolczanska 215
90-924 Lodz, Poland

phone:  +48(42)6312796
fax:    +48(42)6303414
email:  bartoszl w ics.p.lodz.pl