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
[quote=morfik]A jak dopiszesz sobie:
allow-hotplug eth0
I pokaż log systemowy w chwili gdy restartujesz ten router.[/quote]
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
[quote=morfik]A jak dopiszesz sobie:
allow-hotplug eth0
I pokaż log systemowy w chwili gdy restartujesz ten router.[/quote]
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 :(
[quote=morfik]I pokaż log systemowy w chwili gdy restartujesz ten router.[/quote]
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.
[quote=uzytkownikubunt]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ń:
ip link show ip addr show
[/quote]
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
[quote=morfik]I u mnie działa bez zarzutu, coś macie gdzieś skopane. xD[/quote]
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 [b]auto ethX[/b] coś zmienia w temacie ale jednak nie zmienia.
[quote=pasqdnik]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.[/quote]
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.
[quote=morfik]Co do tego dhcp, zobacz czy nasłuchuje jakiś demon, i spróbuj go zabić.[/quote]
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.
[quote=morfik]Pokaż jak wygląda to poniższe polecenie, w obu przypadkach, tj. gdy net działa i nie działa:
ip route show
[/quote]
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[/quote]auto eth1
allow-hotplug eth1[/quote]
?Offline
Wcześniej maiłem tylko auto i efekt był taki sam.
Offline
[quote=brii]Wcześniej maiłem tylko auto i efekt był taki sam.[/quote]
Przecież od początku mowa o [i]allow-hotplug[/i].
Offline
Wg dokumentacji debianowskiej używa się albo [i]auto[/i] albo [i]allow-hotplug[/i] albo [i]allow-auto[/i] 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 [b]auto ethX[/b] jest tylko [b]allow-hotplug ethX[/b] 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-detailed-explanation-of-etc-network-interfaces-syntax/128662#128662[/quote]
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:Kod:
# networkctl # networkctl status eth0i jeszcze to daj:
Kod:
# systemctl list-unit-files | grep networkdOstatnio 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.
[quote=uzytkownikubunt]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.[/quote]
Sprytne, podziałamy.
Ostatnio edytowany przez brii (2015-11-21 15:16:37)
Offline
Strony: 1
Time (s) | Query |
---|---|
0.00013 | SET CHARSET latin2 |
0.00005 | SET NAMES latin2 |
0.00127 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.137.180.62' WHERE u.id=1 |
0.00211 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.137.180.62', 1732772060) |
0.00098 | SELECT * FROM punbb_online WHERE logged<1732771760 |
0.00053 | SELECT topic_id FROM punbb_posts WHERE id=293321 |
0.00014 | SELECT id FROM punbb_posts WHERE topic_id=27914 ORDER BY posted |
0.00061 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=27914 AND t.moved_to IS NULL |
0.00006 | SELECT search_for, replace_with FROM punbb_censoring |
0.00113 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=27914 ORDER BY p.id LIMIT 0,25 |
0.00092 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=27914 |
Total query time: 0.00793 s |