Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Mam ustawioną statycznie sieć na komputerze z Debianem, który jest podłączony do routera z Gargoyle. Za każdym razem kiedy restartuję router(ze switchem) stacja z Debianem zachowuje się tak jakby wyciągnięto kabel LAN (oczywiste) i niestety sieć na niej przestaje działać aż do momentu kiedy ręcznie nie podniosę interfejsu. Kojarzycie gdzie jak można zmienić ustawienia Debiana tak by nie reagował na odłączenie kabla sieciowego?
/etc/network/interfaces:
auto eth0
iface eth0 inet static
address 192.168.98.32
netmask 255.255.255.0
gateway 192.168.98.2
Debian o którym mowa to Jessie - system bazowy, brak NetworkManagera.
Najbardziej wkurzające jest to, że po podniesieniu interfejsu muszę ponownie uruchamiać niektóre usługi i to jest największy ból.
Ostatnio edytowany przez brii (2015-11-19 14:14:00)
Offline
morfik napisał(-a):
A jak dopiszesz sobie:
Kod:
allow-hotplug eth0I pokaż log systemowy w chwili gdy restartujesz ten router.
To samo miałem kiedyś i to też miałem dopisane i z automata nie działało. Potem chyba wrzuciłem wicd, albo nm.
Offline
Dodam tą linię w konfiguracji i sprawdzę, instalacji NM chciałbym bardzo uniknąć. Dobrze by było gdyby działało to jak dekadę temu - raz przypisywało się adres do interfejsu (nawet z palca), kabel można było przypinać/odpinać do woli a interfejs cały czas był podniesiony.
Offline
2391
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:27:36)
Offline
morfik napisał(-a):
A jak dopiszesz sobie:
Kod:
allow-hotplug eth0I pokaż log systemowy w chwili gdy restartujesz ten router.
Aż mi głupio, bo nie zauważyłem braku tej linii - wcześniej zawsze ją miałem. Teraz działa jak należy, dzięki :)
Ostatnio edytowany przez brii (2015-11-19 21:35:02)
Offline
Jednak moja radość była przedwczesna :(
morfik napisał(-a):
I pokaż log systemowy w chwili gdy restartujesz ten router.
Nov 21 09:28:38 centrala kernel: [ 338.945944] r8169 0000:05:00.0 eth0: link down Nov 21 09:28:38 centrala kernel: [ 338.946009] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Nov 21 09:28:39 centrala kernel: [ 339.226458] r8169 0000:05:00.0 eth0: link down Nov 21 09:28:39 centrala kernel: [ 339.226522] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready th0: link becomes ready
Po podłączeniu kabla:
Nov 21 09:28:51 centrala kernel: [ 351.850401] r8169 0000:05:00.0 eth0: link up Nov 21 09:28:51 centrala kernel: [ 351.850423] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
i sieć nie wstaje.
uzytkownikubunt napisał(-a):
Zrób tak, żeby było ok, a potem odepnij kabel i podłącz, by nie można było połączyć się z siecią. W tym stanie podaj wyniki poleceń:
Kod:
ip link show ip addr show
ip link show:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether c4:e9:84:04:38:a9 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether d0:50:99:5a:08:da brd ff:ff:ff:ff:ff:ff
ip addr show:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether c4:e9:84:04:38:a9 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether d0:50:99:5a:08:da brd ff:ff:ff:ff:ff:ff inet6 fe80::d250:99ff:fe5a:8da/64 scope link valid_lft forever preferred_lft forever
==================================================
Zauważyłem ciekawą sprawę - mimo tego, że interfejs ustawiony jest statycznie, to po podłączeniu kabla uruchamia się dhclient i próbuje pobrać konfigurację po DHCP. O co może chodzić?
==================================================
Dorzuciłem drugą kartę sieciową do tego komputera i co ciekawe na niej wszystko działa poprawnie. Jak odłączam i dołączam kabel to w logach ta karta generuje tylko:
Nov 21 10:28:45 centrala kernel: [ 650.544836] r8169 0000:01:00.0 eth1: link down Nov 21 10:28:52 centrala kernel: [ 657.216181] r8169 0000:01:00.0 eth1: link up link up
Na feralnym interfejsie jest jeszcze dodatkowo coś o IPv6:
Nov 21 10:25:02 centrala kernel: [ 426.405045] r8169 0000:05:00.0 eth0: link down Nov 21 10:25:02 centrala kernel: [ 426.405117] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Nov 21 10:25:04 centrala kernel: [ 429.054380] r8169 0000:05:00.0 eth0: link up Nov 21 10:25:04 centrala kernel: [ 429.054402] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
mimo, że IPv6 nie konfigurowałem.
Ostatnio edytowany przez brii (2015-11-21 10:34:59)
Offline
Przełączanie stanów działa (ipv6 bez znaczenia). Problem jest raczej w konfiguracji i pewnie dwa narzędzia ci próbują konfigurować to połączenie i pewnie znika brama w wyniku "ip route show". Ustal czemu ci dhcp się odpala.
Ostatnio edytowany przez morfik (2015-11-21 12:35:07)
Offline
Problem w tym, że nie wiem nawet gdzie zacząć szukać. System jest praktycznie bazowy czyli nie ma NetworkManagera czy wcid które mogłyby konfigurować połączenia. Interfejs kładzie się od razu po odpięciu kabla a dhclient ładuje się w jakieś 30 sekund po podłączeniu kabla :(
Offline
U mnie w robocie też mamy (m. in. takie jak Ty) problemy z większością kart działających obecnie z modułem r8169. Dla testów podmień kartę na inną, opartą na innym chipie.
Offline
Ja też mam:
Nov 21 13:05:42 morfikownia kernel: r8169 0000:02:00.0 eth1: link up Nov 21 13:06:14 morfikownia kernel: r8169 0000:02:00.0 eth1: link down
I u mnie działa bez zarzutu, coś macie gdzieś skopane. xD
Co do tego dhcp, zobacz czy nasłuchuje jakiś demon, i spróbuj go zabić. Potem postaraj się ręcznie skonfigurować połączenie (za pomocą ip addr, ip link, i ip route).
Pokaż jak wygląda to poniższe polecenie, w obu przypadkach, tj. gdy net działa i nie działa:
ip route show
Ostatnio edytowany przez morfik (2015-11-21 13:12:54)
Offline
morfik napisał(-a):
I u mnie działa bez zarzutu, coś macie gdzieś skopane. xD
My mamy poważniejsze problemy niż autor wątku i wierz mi, że skopany to jest moduł.
Poza tym do teraz autor nie pochwalił się pełną zawartością pliku interfaces.
Offline
Już się chwalę całym interfaces ;)
W międzyczasie zmieniły się adresy na takie które w mojej "infrastrukturze" ułatwiają mi testowanie.
# This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). source /etc/network/interfaces.d/* # The loopback network interface auto lo iface lo inet loopback auto eth0 allow-hotplug eth0 iface eth0 inet static address 192.168.246.254 netmask 255.255.255.0 gateway 192.168.246.1 dns-nameserver 192.168.246.1 auto eth1 allow-hotplug eth1 iface eth1 inet static address 192.168.209.254 netmask 255.255.255.0
Przez chwilę myślałem, że może jeszcze auto ethX coś zmienia w temacie ale jednak nie zmienia.
pasqdnik napisał(-a):
U mnie w robocie też mamy (m. in. takie jak Ty) problemy z większością kart działających obecnie z modułem r8169. Dla testów podmień kartę na inną, opartą na innym chipie.
Dorzuciłem drugą ale na tym samym module, nie miałem innej niezintegorwanej, na niej wszystko działa OK. Obstawiam, że moduł jednak jest niewinny bo takie same akcje odchodziły na różnych komputera gdzie były karty z e1000e albo jeszcze inne.
W międzyczasie wziąłem inny dysk i odstawiłem lameriadę - zainstalowałem na nowo Jessie ale tym razem wymusiłem podczas instalcji ręczną konfigurację interfejsów. Wpisy wygenerowane w /etc/network/intrafaces są takie same a wszystko działa jak należy.
morfik napisał(-a):
Co do tego dhcp, zobacz czy nasłuchuje jakiś demon, i spróbuj go zabić.
Nope - nie nasłuchuje, uruchamia się automagicznie dopiero po ponownym podłączeniu kabla - czarna magia.
Zbyt głęboko w czeluściach Debiana nie siedzę i nie jestem w stanie sprawdzić co jeszcze się różni w całej konfiguracji wygenerowanej po instalacji kiedy wymusza się ręczne ustawienia sieci, ale chyba w tym jest klucz do problemu.
morfik napisał(-a):
Pokaż jak wygląda to poniższe polecenie, w obu przypadkach, tj. gdy net działa i nie działa:
Kod:
ip route show
Przed odłączeniem kabla:
default via 192.168.246.1 dev eth0 192.168.209.0/24 dev eth1 proto kernel scope link src 192.168.209.254 192.168.246.0/24 dev eth0 proto kernel scope link src 192.168.246.254
Po odłączeniu:
192.168.209.0/24 dev eth1 proto kernel scope link src 192.168.209.254
Zaraz po podłączeniu:
192.168.209.0/24 dev eth1 proto kernel scope link src 192.168.209.254
Minutę później:
default via 192.168.211.1 dev eth0 192.168.209.0/24 dev eth1 proto kernel scope link src 192.168.209.254 192.168.211.0/24 dev eth0 proto kernel scope link src 192.168.211.160
192.168.211.* to IP rozsiewany przez DHCP w tym LANie
Ostatnio edytowany przez brii (2015-11-21 14:06:07)
Offline
Dlaczego masz jednocześnie auto i allow-hotplug:
auto eth0
allow-hotplug eth0
auto eth1
allow-hotplug eth1
?
Offline
Wcześniej maiłem tylko auto i efekt był taki sam.
Offline
brii napisał(-a):
Wcześniej maiłem tylko auto i efekt był taki sam.
Przecież od początku mowa o allow-hotplug.
Offline
Wg dokumentacji debianowskiej używa się albo auto albo allow-hotplug albo allow-auto albo w ogóle się tą linię pomija (w specyficznych konfiguracjach). Chociaż w sieci jest pełno przykładów, gdzie jest to pomieszane...
Ostatnio edytowany przez pasqdnik (2015-11-21 14:33:38)
Offline
Zmieszanie tych dwój wpisów występuje nawet w oficjalnym wiki Debiana, niemniej dzięki za informację - rzeczywiście w automatycznie wygenerowanym pliku nie ma auto ethX jest tylko allow-hotplug ethX jednak wprowadzenie takiej zmiany niczego nie zmienia w kwestii omawianego problemu :(
Offline
Tu jest różnica między tymi parametrami:
auto interface – Start the interface(s) at boot. That’s why the lo interface uses this kind of linking configuration.
allow-auto interface – Same as auto
allow-hotplug interface – Start the interface when a "hotplug" event is detected. In the real world, this is used in the same situations as auto but the difference is that it will wait for an event like "being detected by udev hotplug api" or "cable linked".
http://unix.stackexchange.com/questions/128439/good … 128662#128662
Jeśli chce się mieć interfejs podnoszony i konfigurowany tylko na starcie systemu, to auto. W każdym innym przypadku allow-hotplug, no chyba, że ktoś nie chce by jakiś interfejs był z automatu konfigurowany wtedy żadne z powyższych. Cała filozofia. xD
Co do tej sytuacji, że przy wybraniu dhcp w instalatorze są problemy, a przy manualnej wszytko działa. To być może jest to za sprawą systemd. W efekcie czego ten konfiguruje interfejs po dhcp, a ty dodatkowo w /etc/network/interfaces. Zajrzyj do katalogu /etc/systemd/network i zobacz czy są tam jakieś pliki. Ewentualnie też podaj wynik:
# networkctl # networkctl status eth0
i jeszcze to daj:
# systemctl list-unit-files | grep networkd
Ostatnio edytowany przez morfik (2015-11-21 15:02:43)
Offline
2396
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:27:42)
Offline
Przeorałem już system - instaluję go na nowo bo niebawem komp musi działać. W wolnej chwili odtworzę tą sytuację i zobaczę co do sprawy wnosi systemd.
Dałem jeszcze w /etc/default/networking:
# Set to 'no' to skip interfaces configuration on boot CONFIGURE_INTERFACES=no
by mieć pewność, że jeszcze coś innego nie miesza w ustawieniach sieci przy bootowaniu ale to też nic nie zmieniło.
uzytkownikubunt napisał(-a):
Oprócz tego co morfik napisał jak bym przeniósł plik dhclienta pod inną nazwę, w jego miejsce zrobił skrypt basha, który by używał zmiennej $PPID do znalezienia PIDu procesu rodzica, a potem zapisywał jakie procesy są uruchomione wtedy w systemie np. sprawdzając przez ps axf i zapisując do jakiegoś plik. Na końcu można by wywołać stary dhclient z basha używając $@, by przekazać argumenty.
W ten sposób udałoby się znaleźć, co odpala dhclienta.
Sprytne, podziałamy.
Ostatnio edytowany przez brii (2015-11-21 15:16:37)
Offline
Strony: 1