Sieć DHCP: TAK

[robert_cz]

Taki mi się zdarza problem z DHCP na BSxA. Radzę sobie z nim, ale postanowiłem się jednak podzielić.

 

Podejrzewam, że chodzi o "wolniejsze" serwery DHCP na starszych routerach. Nie pobierają adresu IP z routera, pewnie jakiś timeout i wystarczy restart sieci i natychmiast pojawia się połączenie.

Przy stałym IP tego nie mam. Jak mówicie, jak podłączę soie kabel konsolowy, to coś ciekawego zobaczę?

 

PS. Tux, istniałaby opcja dla fanatyków przewijających się komunikatów z konsoli włączyć zamiast tapety uruchamiania klasyczne wyjście komunikatów z konsoli, a dopiero jak się enigma włączy żeby przejmowała kontrolę?

Fajna opcja by był dla grzebaczy wszelakich :-)

[robert_cz]

Liczę na wybaczenie moderatorów. Wpis pod wpisem, żeby było widać, że uzupełniłem coś:

 

Więc tak, podłączyłem kabel konsolowy i wynik taki:

1) start na zimno, hard reset:

Start network
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces... showSinglePic /boot/logo_.mvi
VIDEO_SELECT_SOURCE MEMORY (Success)
VIDEO_PLAY (Success)
VIDEO_CONTINUE: (Success)
VIDEO_CLEAR_BUFFER: (Invalid argument)
udhcpc (v1.22.1) started
Sending discover...
Sending discover...
Sending select for 192.168.1.12...
Lease of 192.168.1.12 obtained, lease time 259200
route: SIOCDELRT: No such process
adding dns 192.168.1.1
done.

 

 

2) soft reset:

Start network
Setting up IP spoofing protection: rp_filter.
Configuring network interfaces... showSinglePic /boot/logo_.mvi
VIDEO_SELECT_SOURCE MEMORY (Success)
VIDEO_PLAY (Success)
VIDEO_CONTINUE: (Success)
VIDEO_CLEAR_BUFFER: (Invalid argument)
udhcpc (v1.22.1) started
Sending discover...
Sending discover...
Sending discover...
failed...
No lease, failing
done.

 

Teraz pytanie, wie ktoś jak zwiększyć czas przed timeout? Bo wygląda, że to timeout jest problemem.

[Gość smarkusg]

Zerknij help do klienta dhcp , chyba "-t"- ale gdzie to zmienić w sktyptach GOS.... Obstawiam ,że wystarczy dodać parametr tutaj /etc/init.d/udhcpc .

 

GraterliaOS:/# udhcpc --help

BusyBox v1.22.1 (2014-09-11 11:19:38 CEST) multi-call binary.

 

Usage: udhcpc [-fbqaRB] [-t N] [-T SEC] [-A SEC/-n]

  [-i IFACE] [-P PORT] [-s PROG] [-p PIDFILE]

  [-oC] [-r IP] [-V VENDOR] [-F NAME] [-x OPT:VAL]... [-O OPT]...

 

  -i,--interface IFACE  Interface to use (default eth0)

  -P,--client-port PORT  Use PORT (default 68)

  -s,--script PROG  Run PROG at DHCP events (default /usr/share/udhcpc/default.script)

  -p,--pidfile FILE  Create pidfile

  -B,--broadcast      Request broadcast replies

  -t,--retries N      Send up to N discover packets (default 3)

  -T,--timeout SEC  Pause between packets (default 3)

  -A,--tryagain SEC  Wait if lease is not obtained (default 20)

 

 

 

[robert_cz]

Zerknij help do klienta dhcp , chyba "-t"- ale gdzie to zmienić w sktyptach GOS.... Obstawiam ,że wystarczy dodać parametr tutaj /etc/init.d/udhcpc .

 

GraterliaOS:/# udhcpc --help

BusyBox v1.22.1 (2014-09-11 11:19:38 CEST) multi-call binary.

 

Usage: udhcpc [-fbqaRB] [-t N] [-T SEC] [-A SEC/-n]

  [-i IFACE] [-P PORT] [-s PROG] [-p PIDFILE]

  [-oC] [-r IP] [-V VENDOR] [-F NAME] [-x OPT:VAL]... [-O OPT]...

 

  -i,--interface IFACE  Interface to use (default eth0)

  -P,--client-port PORT  Use PORT (default 68)

  -s,--script PROG  Run PROG at DHCP events (default /usr/share/udhcpc/default.script)

  -p,--pidfile FILE  Create pidfile

  -B,--broadcast      Request broadcast replies

  -t,--retries N      Send up to N discover packets (default 3)

  -T,--timeout SEC  Pause between packets (default 3)

  -A,--tryagain SEC  Wait if lease is not obtained (default 20)

 

Nie wiem, cokolwiek zmienię w tym pliku, to system podczas startu i tak to ignoruje, nawet popsułem tą linijkę i nic, dalej się odpala. To musi być gdzieś indziej wywoływane przy starcie i tam muszą być opcje.

[Gość smarkusg]

Do diagnozy komunikacji z dhcpd możesz jeszcze sprawdzić dhcping i do poglądu tcpdump (jako opcja której nie trzeba) . U siebie mam na  ip wpisane ręcznie, z zakresu poza pulą dhcpd i nie mnie router "nie lubi" ;). U Ciebie powinno działać. Program dhcping pod sh4 wygoglujesz.

 

GraterliaOS:~# ./dhcping -s 255.255.255.255 -r -v

no answer

 

 

[robert_cz]

Ponownie proszę o darowanie mi postu pod postem, ale mam rozwiązanie.

Po dodaniu do pliku "interfaces ostatniej linii dla eth0:

 

udhcpc_opts -t 5 -T 5

 

# automatically generated by enigma 2
# do NOT change manually!

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
udhcpc_opts -t 5 -T 5

 

domyślnie jest tak:

 

 -t,--retries N      Send up to N discover packets (default 3)

 

 -T,--timeout SEC   Pause between packets (default 3)

 

Można  by nawet pomyśleć o:

-b,--background         Background if lease is not obtained

jeszcze to posprawdzam, ale powinno wtedy działać w tle i pobrać IP jak się podłączy kabel już po uruchomieniu boxa.

 

---

---

 

Mam inny pomysł, pytanie co na to tux.

Po kilku testach z wiresharkiem zobaczyłem, że problemem nie są opóźnienia, tylko, że zapytania o dhcp zaczynają wychodzić przed fizycznym podniesieniem interface eth0 i dlatego serwer DHCP nie ma szansy odpowiedzieć przed timeout.

Mój pomysł, to zmiana kosmetyczna w skrypcie network, przed

ifup -a

dać podniesienie if:

 iplink set eth0 up

i pause 3s

 

---

---

 

Można prosić o aktualizację w wersji base?

 

Proszę nie pisać posta pod własnym postem!

[mickey]

Co do ostatniego: Podłącz się do routera tak, że po drodze będzie miał jakiegoś switcha i sprawdź wtedy. Linka może nie być, bo nie ma go z drugiej strony kabla, czyli na routerze...

 

A co do "udhcpc_opts"... : Taki wpis powinien być robiony przez skrypty pythona, bo na początku pliku jest "# automatically generated by enigma 2". Jak dla mnie to oznacza, że po zmianach z pilota w pliku się zmieni. Czyli gdzieś tam by musiały być pola do ustawienia "-t", "-T" i ewentualnie "-b", które domyślnie są takie jak obecnie. Który skrypt pythona ... nie szukałem.

[robert_cz]

Co do ostatniego: Podłącz się do routera tak, że po drodze będzie miał jakiegoś switcha i sprawdź wtedy. Linka może nie być, bo nie ma go z drugiej strony kabla, czyli na routerze...

 

A co do "udhcpc_opts"... : Taki wpis powinien być robiony przez skrypty pythona, bo na początku pliku jest "# automatically generated by enigma 2". Jak dla mnie to oznacza, że po zmianach z pilota w pliku się zmieni. Czyli gdzieś tam by musiały być pola do ustawienia "-t", "-T" i ewentualnie "-b", które domyślnie są takie jak obecnie. Który skrypt pythona ... nie szukałem.

Z udhcpc_opts wycofuję się, bo jak sam zauważyłeś:

"# automatically generated by enigma 2"

 

Co do mojego drugiego pomysłu, to na 100% potwierdzony za pomocą huba i Wresharka, żebym miał dump całej transmisji po ethernet i jak się da samo ifup-a, to zanim "zapali się światełko", to już idą zapytania o dhcp. Idą 3, a z racji opóźnienia w podnoszeniu interface wireshark (czyli faktycznie wychodzi przez interface sieciowy tunera) widzi tylko jedno, lub wcale, zapytanie, na które jeśli wyjdzie router odpowiada.

 

Spotkało mnie to już na 4 różnych routerach, więc problem wygląda na powtarzający się.

[tux]

Dodatkowo ciekawostka jest taka, że link karta powinna osiągnąć już na poziomie u-boota. Pytanie czy osiąga?

[robert_cz]

Dodatkowo ciekawostka jest taka, że link karta powinna osiągnąć już na poziomie u-boota. Pytanie czy osiąga?

Sprawdziłem i lampka, czyli "link" nie pojawia się na etapie u-boota, a powinien? Macie jakieś uboty do BSxA na których tak jest?

[Gość j00zek]

link się pojawi jedynie przy boocie systemu przez sieć

[robert_cz]

link się pojawi jedynie przy boocie z nfs-a.

To ja proponuje dodanie link gdzieś we wcześniejszych skryptach, albo w skrypcie uruchamiania sieci i pause 2s.

[tux]

No OK. Ale to nie tłumaczy "źle działających" routerów.

Ja mam zdanie niezmienne. Jeżeli coś działa zgodnie z normą i trzyma się określonych parametrów problemów nie ma.

Zakładając, iż mamy taki "źle działający" sprzęt to zamiast konfigurować połączenie przy pomocy GUI należy użyć "wersji ręcznej" i po sprawie. Podałeś wyżej co dopisać.

[robert_cz]

Ale Tux, okazało się, że moja hipoteza z tym, że to wina routera  po sprawdzeniu za pomocą snifera pakietów, jest nierawdziwa.

Winny jest box, który jeszcze przed fizycznym podniesieniem portu wysyła w poowietrze zapytania DHCP.

stąd problem z timeout,  bo czasem przez interfacee nie zdąży wyjść ani jedno zapytanie.

 

Nie wiem gdzie leży przyczyna, czy ifup powinno poczeekać przed wysyłaniem zapytań o DHCP na podniesinie interface, ale wim, jak to załatać.

Co Wy na to?

[Gość fold]

miałem dwa boxy które robiły mi taki problem.

od czasu do czasu wysypywało im sie połaczenie, tak po prostu.

Czasem po włączeniu do prądu nie było połaczenia. Pomagał restart sieci z pilota.

Rozwiązałem to prymitywnym skryptem , który pinguje router i jak jest coś nie tak to restartuje eth0.

 

Wiem że nie jest to najlepsze rozwiązanie, ale dla mnie wystarczy że od tego momentu działa poprawnie.

[robert_cz]

tux, wygląda, że ten problem istnieje nie tylko u mnie i może zniechęcać mniej zaawansowanych.

 

Moim zdaniem dodanie

iplink set eth0 up

 

gdzieś przed skryptem network rozwiązuje problem.

[Gość j00zek]

może najpierw sprawdź co robi skrypt network.

[robert_cz]

może najpierw sprawdź co robi skrypt network.

sprawdziłem, network uogólniając robi ifup  -a jeśl dobrze pamiętam + wyświetlanie o tym fakcie na wyświtlaczu.

A co konkretnie masz na myśli żebym sprawdził?

[Gość j00zek]

no właśnie ifup -a....

[tux]

To ja napiszę raz jeszcze.

Miałem do czynienia z dwoma dekoderami co miały taki efekt. Osoby specjalnie przyjechały z nimi.

Niestety - wpięcie ich do mojej sieci spowodowało, że działały jak powinny.

Dla mnie wniosek jest jednoznaczny - nie działa Ci jak u innych? Masz dwa wyjścia:

• dostosować swoją sieć tak aby działała jak u innych;
  
• poprawić pod swoją sieć skrypty w boxie.
  

Jestem bardzo sceptycznie nastawiony na aplikowanie jakichkolwiek zmian, które mają dostosować GOS to dziwnie działających sieci.

Wszystko wskazuje na to, że problemem jest ustanowienie linku. Prawdopodobnie po włączeniu kabla (odpaleniu portu LAN) switch w routerze (czy też sam switch) długo negocjuje połączenie.

Jest kilka spraw, które mogą na to wpływać:

• urządzenia LAN nie są do końca kompatybilne ze sobą;
  
• połączenie (wtyczki) coś szwankuje;
  
• okablowanie jest niewłaściwe:
  * złej jakości kabel (np. aluminium miedziowane zamiast miedzi - kabel był tani ale...);
  * złej jakości wtyczki?
  * okablowanie gotowe - większość kabli marki "hipermarket" należy omijać wielkim łukiem - dotyczy to nawet patchcord;
  * okablowanie ma załamania (miejscami) większe niż 45 stopni;
  * okablowanie nie jest długości 1,5m lub jego długość nie jest krotnością 1,5m (wynika ze wzoru na długość fali).
  

Sieci to bardzo skomplikowane zagadnienie.

W tym tygodniu stanąłem przed koniecznością modernizacji swojej sieci domowej (po latach część sprzętu powiedziała, że ma dość :)). Do testów (bo coś musiałem wybrać) stanęli:

• ASUS RT-AC56U (finalnie stanęło na nim + Entware + masa dokompilowanego softu bo potrzeba zaszła);
  
• NETGEAR WNDR4300 (OpenWRT + paczki dodatkowe);
  
• ASUS RT-N53U (Oprogramowanie oficjalne - chodziło tylko o AP -- bridge LAN <--> WLAN;
  
• TL-WR841ND (tak samo jak RT-N56U);
  
• Dodatkowo (bo jeszcze nikt nie kupił) Switch 10/100/1000 Netgear + switch 10/100 Pentagram (chipset Atheros);
  

Na powyższym sprzęcie + okablowanie zgodnie z normą == ZERO PROBLEMU. Cokolwiek bym nie wyczyniał nBox wstaje i zawsze ma sieć!

 

[robert_cz]

Panowie, ja wiem, że jesteście perfekcjonistami i korzystacie ze sprzętu z górnych parametrów standardów ethernet, ale nie zapominajcie, proszę, że z 70% sieci domowych zbudowana jest za sprzętów z parametrami z środka standardów ethernet.

 

Nie wydaje się Wam, że fakt "wysyłania w powietrze", przed podniesieniem interface, zapytań DHCP, raczej nie jest standardowym zachowaniem

 

Nie odbierzcie tego źle, ale u konkurencji działa dhcp w 100%. Może błąd jest w nowej wersji busybox, że ifup -a przed uruchomieniem udhcp nie sprawdza, czy interface już jest up. (wykreślam, jednak busybox to nie ten trop)

 

Popatrzę jak to było w starszych wersjach graterli, bo coś mi się wydaje, że w którejś z poprzednich było OK.

 

[Aktualizacja]

na poniższej wersji DHCP działa w 100%:

Graterlia OS 2.1.0
*** 03.03.2014... ***
BusyBox v1.21.1

Start network

Reconfiguring network interfaces... ifdown: interface lo not configured
ifdown: interface eth0 not configured
udhcpc (v1.21.1) started
Sending discover...
Sending select for 192.168.1.108...
Lease of 192.168.1.108 obtained, lease time 259200
route: SIOCDELRT: No such process
adding dns 192.168.1.1

 

 

I w tej wersji w rcS było:

 

	echo "Start network"
	if [ $vfd == on ]; then # Ustawinienie i aładowanie obsługi sieci
		echo "Network init" > /dev/vfd
	else
		echo "nEt" > /dev/vfd
	fi
	sleep 1
if [ -e /etc/network/interfaces ]; then
	ifconfig eth0 up
	sleep 3
	if [ -e /lib/modules/rt3070sta.ko ]; then
		insmod /lib/modules/rt3070sta.ko
		ifconfig ra0 up
		echo "rt3070 driver loaded"
	fi
	if [ -e /lib/modules/rt5370sta.ko ]; then
		insmod /lib/modules/rt5370sta.ko
		ifconfig ra0 up
		echo "rt5370 driver loaded"
	fi
	/etc/init.d/networking restart

 

Wydaje mi się, że kluczowe było:

		ifconfig eth0 up
	sleep 3

 

[Aktualizacja2]

Jeszcze w wersji Graterlia OS 2.1.1 było OK

 

z graterlia-scripts - 0.1.24

[tux]

Zauwaz ze zrezygnowałem z restartu sieci. Jest to niezgodne z zasadami działania OS.

Napisze raz jeszcze - przyczyna to brak linku a nie oczekiwanie aż łaskawie on się pojawi.

[Gość smarkusg]

Jeżeli można się wtrącić..  Tux ma rację. Pracuję w sieciach parę lat i cyrki różnego rodzaju z działaniem sieci ethernetowej nie śniły się chyba ich pomysłodawcom. Pomijam teoretyczne zasady działania bo i tak się nie sprawdzają. Praktycznie mogę powiedzieć tylko tyle abyś zerknął na krótko jak sprawuje się ( sprawują się) twoje routery, sprawdź wtyki czy nie masz coś ze stykami, kablami itp . Do dokładnych pomiarów potrzebujesz profesjonalnych narzędzi np. fluke itp. ale przy sieci domowej taniej i prościej zarobić kabel lub kupić nowy, pożyczyć sprzęt od sąsiada i sprawdzić. To jest tylko rada, nie ma sensu grzebać w skryptach aby coś zlinkowało się za drugim  razem jak za pierwszym nie może - to czarowanie rzeczywistości ( tak się robi jak się kabli nie chce wymieniać a na której żyle dzieją się cuda). Jak jesteś wpięty w zarządzałkę to ewentualnie zostają opcje limitów odwołań dhcp ale z tego co pisałeś wnioskuję, że coś jest z kablem.

 

[robert_cz]

Zauwaz ze zrezygnowałem z restartu sieci. Jest to niezgodne z zasadami działania OS.

Napisze raz jeszcze - przyczyna to brak linku a nie oczekiwanie aż łaskawie on się pojawi.

 

No to bez restart przywróćmy:

		ifconfig eth0 up
	sleep 3

 

tux, ja Cie rozumiem, ale zrozum też pozostałe 70-80% posiadających sieć ze średniej półki, a nie z najwyższej jak u Was.

A zapytam z ciekawości, na które zapytanie odpowiada Wasz sprzęt i po jakim czasie podnosi się interface?

[tux]

TL-WR842ND

Jak to jest górna polka to nie chce wiedzieć co jest na średniej i dolnej.

 

 

Poza tym nie demonizowalbym. Jakby to było tyle % to raczej juz by huczalo.

[Gość j00zek]

Nie obraz się, ale co chwile udowadniasz l ze cos działa źle. A to siec, a to dvb a to gstm i tak dalej. A później sam przyznajesz, ze jednak jest inaczej.

Wpisz sobie co chcesz w rd.local i rozwiaz sobie problem . Bo niestety nie jesteś siedemdziesiecioma procentami Użytkowników.

[robert_cz]

Nie obraz się, ale co chwile udowadniasz l ze cos działa źle. A to siec, a to dvb a to gstm i tak dalej. A później sam przyznajesz, ze jednak jest inaczej.

Wpisz sobie co chcesz w rd.local i rozwiaz sobie problem . Bo niestety nie jesteś siedemdziesiecioma procentami Użytkowników.

 

Ja się szybko nie obrażam. :-) Przyznaję, że z poprzednią sprawą gst nie miałem racji i się do tego przyznałem, ale za to z np. skryptem uruchamiającym inadyn miałem rację i jeszcze w kilku przypadkach. Czasami po prostu łatwiej się uczyć na błędach, a najłatwiej na własnych. :-)

A jak odpowiedzi szukam, a jej nie dostaję, to szukam dalej, czasem okazuje się, że rozwiązanie jest w innym miejscu niż podejrzewałem na początku, tak było np. z gst.

 

A proszę sprawdźcie jak to jest u Was, po którym zapytaniu o DHCP dostajecie odpowiedź?

Bo ja właśnie zmieniłem na model TD-W8951ND i rzeczywiście działa i wyrabia się w ostatnich sekundach po trzecim zapytaniu, chwilkę przed timeout Czy tak powinno być?

 

Raczej nie bez powodu było to sleep 3, widocznie innym też tak robiło i ktoś wyliczył, że średnio to będą 3 s na uzyskanie linka.

 

Mam nadzieje, że Wy też się nie obrazicie, ale nie huczy, bo istnieją alternatywy do Graterli i jak komuś nie zadziała dhcp, to wrzuca inną dystrybucję i z głowy.

 

[Aktualizacja]

okazuje się, po kilku testach, że sleep 3 jest jednak konieczne, bo tyle trwa link po stronie boxa, a nie routera.

 

Bardzo bym prosił o tą drobną poprawkę w skrypcie /etc/init.d/network

przed

ifup -a

 

		ifconfig eth0 up
	sleep 3

 

z nią po prostu w 100% działa, było tak w Graterli do wersji skryptów co najmniej graterlia-scripts - 0.1.24, a nie było tego już na pewno od wersji graterlia-scripts - 0.1.41, a może wcześniej. Nie mam pośrednich wersji.

 

[Aktualizacja2]

A może żeby nie trzeba było czekać te 3 sekundy dać by "ifconfig eth0 up" gdzieś we wcześniejszym skrypcie przed network.

 

Widziałem, że przy Arivie jest podobny problem z DHCP y zgłaszał go już ktoś.

[Gość antraks]

Mam ten sam problem na nowszych grateliach po restarcie tunera bądź zaniku napięcia muszę robić restart sieci z pilota.Ostatnia działająca to Graterlia OS 2.1.1.Edytowałem skrypt coś poknociłem i straciłem łączność z boxem,muszę od nowa flashować :( .Mam prośbę może ktoś by mi poprawił ten skrypt.Nie mam zamiaru zmieniać routera z Fritzboxa 7270 :) .Dzięki!

ethernet.txt

[robert_cz]

Ten kawałek:

case "$1" in
    start)
start_info
[ -f /var/run/ifstate ] && rm -f /var/run/ifstate
doopt spoofprotect yes
        doopt syncookies no
        doopt ip_forward no

        echo -n "Configuring network interfaces... "
			wpa_supplicantcheck
        ifup -a
echo "done."
;;

 

popraw na:

 

case "$1" in
    start)
start_info
[ -f /var/run/ifstate ] && rm -f /var/run/ifstate
doopt spoofprotect yes
        doopt syncookies no
        doopt ip_forward no

        echo -n "Configuring network interfaces... "
			wpa_supplicantcheck
ifconfig eth0 up
sleep 3
        ifup -a
echo "done."
;;

[sunfizz]

Jadę po DHCP od wieków pod GOS na swoim bsla ( router netgear ) i śmiga jak tra lala. Sieć wstaje aż miło.

[Gość fold]

Akurat wczoraj nie miałem prądu, dawno się to nie zdarzało i zapomniałem jak wtedy zachowują się dekodery  >:(

 

Po braku prądu ADB5800 nie ma połączenia z siecią, trzeba zrestartować sieć z pilota (sprawdzone na 2 sztukach). ADB2450 nie ma sieci, restart sieci z pilota wykonuje sie bardzo szybko i dalej nie ma sieci, dopiero wyciągnięcie wtyczki z prądu pomaga.

Router TP-Link WR1043ND OpenWRT.. Zdaje sobie sprawę że ten router płata figle, ale inne sprzęty podłączone do niego jakoś sobie z tym radzą  :(

[tux]

Oczywiście z posta powyżej dowiemy się:

• TEST czy release?
  
• aktualizacje z kiedy?
  
• gdzie był wykonany restart sieci - wiemy tylko, że z pilota.
  

[Gość tito]

Akurat wczoraj nie miałem prądu, dawno się to nie zdarzało i zapomniałem jak wtedy zachowują się dekodery  >:(

 

Po braku prądu ADB5800 nie ma połączenia z siecią, trzeba zrestartować sieć z pilota (sprawdzone na 2 sztukach). ADB2450 nie ma sieci, restart sieci z pilota wykonuje sie bardzo szybko i dalej nie ma sieci, dopiero wyciągnięcie wtyczki z prądu pomaga.

Router TP-Link WR1043ND OpenWRT.. Zdaje sobie sprawę że ten router płata figle, ale inne sprzęty podłączone do niego jakoś sobie z tym radzą  :(

 

Kolego mam proste pytanie: używasz systemu UPS przy routerze TP-LINK? Pytam dlatego ponieważ podejrzewam że tunery GOS szybciej się bootują niż system na openwrt i dlatego nie dostają odpowiedzi na zapytania DHCP. A to oznacza że tunery działają poprawnie.

[Gość j00zek]

Gwoli wyjaśnienia. GOS czeka teraz w sumie 30 sekund na adres z DHCP. (Prosi o niego 10 razy w odstępach 3 sekundowych). To chyba naprawę dużo czasu dla rutera. ;)

No i zawsze, żeby się upewnić, z czym jest problem, można wpisać adres na stałe. Wtedy wiadomo, czy to dhcp czy jeszcze coś innego.

[tux]

Czas startu na szybszym odbiorniku z GOS (np. ESI czy SPAKR) do czasu zapytania DHCP to około 40sec (pomijam sprawdzanie błędów dysku, zakładam, że ich nie ma).

Dodając do tego powiedzmy 20 sec zapytań DHCP (celowo piszę 20 a nie 30) to mamy MINUTĘ. Nie znam Routera, który by wstawał MINUTĘ, nawet na alternatywnym sofcie. Oczywiście pomijam przypadki, gdy router robi za całą choinkę od routera, przez torrenty, NAS po serwer dźwięku. W takich przypadkach może wstawać dłużej. Jednak wtedy trzeba o tym wiedzieć.

 

U mnie np. wstanie serwerowni to około 6minut. Jedak wiem dlaczego tak jest i nie narzekam jak po DHCP tuner nie dostanie adresu.

Poskładanie macierzy HDD + test spójności (standardowy) musi potrwać i nic z tym nie zrobię. Jednak wiem, że wszystko mam na zasilaczu buforowym (UPS byłby za drogi) i cała serwerownia domowa może pracować bez prądu ponad 6h.

 

Reasumując - przy choince to ja nie zaryzykuje braku UPSa/zasilacza buforowego. Przy zwykłych konfiguracjach jak tuner nie dostaje IP na czas to radzę jak najszybciej doprowadzić sieć do standardów. Im nowszy sprzęt tym większe ma wymagania.

[Gość tito]

Poczekajmy na kolege "fold" - niech ustawi stałe ip dla jednego tunera (BSLA). Sam widzialem juz konfiguracje openwrt plus ext root (pendrive) do tego zewnętrzny dysk twardy, oczywiscie oscam z pcscd i problem gotowy - no ale wtedy, tak jak pisze tux odrazu znaleźliśmy winowajce.

[robert_cz]

Gwoli wyjaśnienia. GOS czeka teraz w sumie 30 sekund na adres z DHCP. (Prosi o niego 10 razy w odstępach 3 sekundowych). To chyba naprawę dużo czasu dla rutera. ;)

No i zawsze, żeby się upewnić, z czym jest problem, można wpisać adres na stałe. Wtedy wiadomo, czy to dhcp czy jeszcze coś innego.

Hej, j00zek, te zmiany, to w release, czy test?

Jedno bardzo teoretyczne pytanie, czy nasze boxy mają możliwość sprawdzania czy sprzętowo został podłączony kabel z urządzeniem po drugiej stronie?

[tux]

Meldują to, ale soft potrzebny do analizy tego (jako daemon) jest za duży na boxa. Dlatego jak nie złapie to musi ponownie zainicjować sieć. Nie jest to kwestia klienta DHCP a całej obsługi sieci - ta jest z busybox.

[Gość antraks]

Ten kawałek:

case "$1" in
    start)
   start_info
   [ -f /var/run/ifstate ] && rm -f /var/run/ifstate
   doopt spoofprotect yes
        doopt syncookies no
        doopt ip_forward no

        echo -n "Configuring network interfaces... "
            wpa_supplicantcheck
        ifup -a
   echo "done."
   ;;

 

popraw na:

 

case "$1" in
    start)
   start_info
   [ -f /var/run/ifstate ] && rm -f /var/run/ifstate
   doopt spoofprotect yes
        doopt syncookies no
        doopt ip_forward no

        echo -n "Configuring network interfaces... "
            wpa_supplicantcheck
   ifconfig eth0 up
   sleep 3
        ifup -a
   echo "done."
   ;;

 

 

Po edycji skryptu problem dalej występuję,po restarcie lub zaniku prądu całkiem się sypie konfiguracja sieci adapter jest wyłączony i dopiero kilkukrotne włączenie go włącza :( .Tuner ADB2850 release.przed edycją wystarcza tylko restart sieci.

 

 

 

[robert_cz]

Mam nadziej, że nikt mnie za to nie zlinczuje :-) Ale napisze to co sprawdziłem:

 

Poprawka z:

<< 22 Marzec 2015 >>

 

...

    [test] aktualizacja pakietu SysVinit (poprawka dla klienta DHCP);

...

 

jeśli tak jak napisał j00zek miała zwiększyć ilość zapytań udhcp z trzech do chyba ośmiu, jak pisał, to nie zwiększyła.

Żeby nikt mi nie napisał, że jestem jakimś oszołomem, czy kimś tam, to napiszę jak sprawdzałem.

 

kabel konsolowy do tunera i odłączony kabel sieciowy, teoretycznie, tuner powinien wysyłać zapytania więcej niż 3 razy. Otóż wysyła tylko trzy:

 

udhcpc (v1.23.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
done.

 

PS. osobiście na temacie już mi przestało zależeć, zostałem skutecznie zniechęcony. Napisałem tylko informacyjnie.

Jak się mylę w którymś punkcie, to proszę o sprostowanie.

 

Co do urządzeń na których mnie to spotkało to:

- Router ZTE ADSL2+ - był on wydawany w Orange z neostradą i w T-Mobile na łączu Orange,

- TD-W8901G - TP-link który był modny klika lat temu,

- Fritzboxa 7270 - o tym pisał kolega @antraks

etc. których nie jestem sobie w stanie teraz przypomnieć.

 

[Gość smarkusg]

Odpowiedz miałeś już na forum.. możesz się bawić skryptami systemu tylko użytkownika lub dopisz sobie startowy jaki chcesz - to tylko linux . Możesz nawet przekompilować "core"  z większą liczbą odpytań dhcp (w wątkach forum widać, że powinieneś dać radę ) . Szczerze życzę Ci powodzenia  bez ironii.

 

"Jak się nie wywrócisz to się nie nauczysz" - i może nawet coś wykombinujesz :)

[314TeR]

Taka refleksja mnie naszła po przeczytaniu tego wątku... czy w GOS jest jakakolwiek kontrola nad tym kiedy zostaną wysłane zapytania DHCP? Zapytania dhcp powinny wyjść dopiero jak zostanie zestawiony link w warstwie sprzętowej, inaczej faktycznie tak jak sugerują niektórzy zapytania mogą pójść w próżnię jeśli system nie czeka. Jeśli w GOS nie ma takiej kontroli bo np. driver od ethernetu nie ma takiej funkcjonalności, skrypty, itp itd... to niestety obie strony mogą mieć rację. Zaklinanie rzeczywistości na zasadzie "w dobrej instalacji nie widzę problemu" faktycznie nie załatwia sprawy. Ja u siebie też nie spotkałem się z podobnym problemem, nie mniej z ciekawości usłyszał bym jak to jest realizowane w GOS.

[mickey]

Po dodaniu do pliku "interfaces ostatniej linii dla eth0:

 

udhcpc_opts -t 5 -T 5

 

(...)

 

Sprawdź załącznik. Trochę inne opcje, ale coś tam dodaje. Trzeba wejść w ustawienia sieci, zmienić na ręczna, zapisać, zmienić na dhcp, zapisać ... i sprawdzić, czy działa.

network.zip

[robert_cz]

Po dodaniu do pliku "interfaces ostatniej linii dla eth0:

 

udhcpc_opts -t 5 -T 5

 

(...)

 

Sprawdź załącznik. Trochę inne opcje, ale coś tam dodaje. Trzeba wejść w ustawienia sieci, zmienić na ręczna, zapisać, zmienić na dhcp, zapisać ... i sprawdzić, czy działa.

 

A jakie zmaiany wprowadza, czego szukać? Bo nie wiem co potrwierdzać.

[mickey]

Zrób jak pisałem. Sprawdź plik interfaces. I zobacz ile discoverów jest na konsoli po zmianie.

[robert_cz]

Zrób jak pisałem. Sprawdź plik interfaces. I zobacz ile discoverów jest na konsoli po zmianie.

 

Działa moim zdaniem ładnie, dodaje linijkę:

udhcpc_opts -t 10

 

do etc/network/interfaces

 

i pyta 10 razy, może o kilka na wyrost, ale nie zrzędzę już :-)

Da się tą modyfikację zastosować w release?

[Gość smarkusg]

Można jeszcze zmienić zawartość plików źródłowych w busyboxa odnośnie network aby nie zmienić skryptów startowych. Chyba opcja najbardziej prosta … jak się nie mylę plik ifupdown.c. Wystarczy zmodyfikować i przekomilować "core". Jak się mylę można mnie zlinczować :)

 

 

[robert_cz]

Można jeszcze zmienić zawartość plików źródłowych w busyboxa odnośnie network aby nie zmienić skryptów startowych. Chyba opcja najbardziej prosta … jak się nie mylę plik ifupdown.c. Wystarczy zmodyfikować i przekomilować "core". Jak się mylę można mnie zlinczować :)

 

A gdzie znaleźć źródła, bo kiedyś szukałem i nie mogłem trafić?

[Gość smarkusg]

Z treści forum kompilowales co potrzeba, nawet sam wykorzystywalem tą wiedzę..

[robert_cz]

Znalazłem coś ciekawego w /usr/sbin:

 

GraterliaOS:/usr/sbin# ifplugd -i eth0 -n
ifplugd(eth0): started: BusyBox v1.23.1 (2015-02-06 15:51:43 CET)
ifplugd(eth0): using SIOCETHTOOL detection mode
ifplugd(eth0): link is up
ifplugd(eth0): executing '/etc/ifplugd/ifplugd.action eth0 up'
ifplugd(eth0): exit code: 255
ifplugd(eth0): exiting
GraterliaOS:/usr/sbin#

 

Więc chyba jest detekcja tego czy jest link czy go nie ma.

 

Musze się w wolnej chwili pobawić tym demonem.

 

 

[Aktualizacja 1]

 

Słuchajcie, moim zdaniem jest świetnie :-)

 

Ddpalam demona z przełącznikiem i żeby było widać na konsoli co się dzieje:

GraterliaOS:~# ifplugd -i eth0 -n
ifplugd(eth0): started: BusyBox v1.23.2 (2015-04-13 22:42:43 CEST)
ifplugd(eth0): using SIOCETHTOOL detection mode
ifplugd(eth0): link is down

i tak cobie demon czeka aż wepnie się kabel. Po wpięciu kabla demon idzie dalej:

ifplugd(eth0): link is up
ifplugd(eth0): executing '/etc/ifplugd/ifplugd.action eth0 up'
ifplugd(eth0): exit code: 255
ifplugd(eth0): exiting

 

ten błąd pomijam, bo nie ma jeszcze w etc tego pliku.

 

Co powiecie na to żeby zamiast podnosić wszystkie interface przy starcie podnosić tylko wifi, a eth0 odpalać demonem?

Przyśpieszy to uruchamianie systemu moim zdaniem, bo sieć będzie podnoszona w tle, oraz dodatkowo rozwiązuje problem wysyłania zapytań DHCP przed podniesieniem interface. sorki @mickey, ale jeśli przeszłoby się na ifplugd, to modyfikacja w Network.pyo nie będzie potrzebna.

 

Brakujące pliki z folderu etc podebrałem sobie z załączonego archiwum.

ifplugd_0.28-19_sh4.deb.zip