Sieć DHCP: TAK

[tux]

[*]zużywasz zasoby tunera do obchodzenia problemu jakości sieci;

[*]nie przyśpieszysz, chyba że wyłączysz NTP; inaczej ładowanie NTP na starcie straci sens;

[*]i wybacz, ale dla mnie WIFI może nie istnieć, także może nie faworyzować danego połączenia

[*]nie wiem czy wiesz, ale soft może startować z NTP - tu też będzie problem.

Można by zastosować daemona, jednak tylko wtedy gdy jest DHCP, i tylko wtedy gdy ktoś ma problemy z siecią.

Swoją drogą niedługo postaram się więcej wyjaśnić na temat sieci podczas opisywania domowego serwera.

 

[robert_cz]

[*]zużywasz zasoby tunera do obchodzenia problemu jakości sieci;

[*]nie przyśpieszysz, chyba że wyłączysz NTP; inaczej ładowanie NTP na starcie straci sens;

[*]i wybacz, ale dla mnie WIFI może nie istnieć, także może nie faworyzować danego połączenia

[*]nie wiem czy wiesz, ale soft może startować z NTP - tu też będzie problem.

Można by zastosować daemona, jednak tylko wtedy gdy jest DHCP, i tylko wtedy gdy ktoś ma problemy z siecią.

Swoją drogą niedługo postaram się więcej wyjaśnić na temat sieci podczas opisywania domowego serwera.

 

@tux, pozwól, że się z Tobą nie zgodzę:

[*]zużywam zasoby tunera po to aby uniknąć wysyłania w powietrze zapytań DHCP przed podniesieniem interface, co czasami skutkuje brakiem pobrania adresu IP przy wolniejszych routerach, dodatkowo tych zasobów zajmuje niewiele bo 0,6% pamięci, tyle co np. autofs, albo vsftpd, z których ja osobiście nie korzystam, a zyskuje się sporo, bo wykrywania podłączenia kabla.

[*]Przyśpieszy się o chwilkę, bo kolejne jest odpalanie serwera ftp a potem ssh, a dopiero crona i NTP, więc nawet najwolniejsze routery dadzą radę do tego czasu odpowiedzieć adresem IP

[*]to nie jest faworyzowanie jakiegoś typu połączenia, tylko pomysł na zwiększenie funkcjonalności boxa, to taki mój pomysł, oczywiście mój pomysł z którym można oczywiście się nie zgadzać

[*]wiem, że może startować z NTP, ale osobiście nie widzę problemu, bo jak ktoś startuje z NTP, to kabel raczej ma podłączony i wtedy ten demon zadziała identycznie jak ifup -a

 

 

[tux]

Pozwolę się też nie zgodzić i będę trwał w tym stanowisku.

System Operacyjny dla Tunera SAT (o tym tu piszemy) to w zasadzie System Embedded. Ten system z założenia nie posiada 100% funkcjonalności pełnego OS. Założenie jest takie, że to, co może obciążać urządzenie, na którym działa taki OS, należy wyłączyć. Liczy się każdy wolny promil zasobów. Tutaj w przypadku sieci panuje zasada taka, że tuner dostaje IP i tyle. Nie zakłada się, że ktoś ma kiepską/złą/niezgodną ze standardem sieć i trzeba będzie kombinować jak koń pod górę, by to działało. Między innymi dlatego można wyłączyć DHCP i ustalić parametry na sztywno.

 

[*]Zużywasz zasoby, gdyż masz kiepską/złą/niezgodną ze standardem sieć na dodatkowy daemon w RAM i "cykający" w odstępach czasu, bo może wreszcie ta kiepska/zła/niezgodna ze standardem sieć odpowie (albo i nie) oraz może przypadkiem zmieniły się parametry sieci. W GOS od samego początku nie popieramy obchodzenia problemów i nie ma takiej siły, żeby to zostało zmienione. Co innego, gdyby to miało coś istotnego naprawić. Rozwiązanie to jednak nie naprawia problemu , za to utwierdza osoby z kiepską/złą/niezgodną ze standardem siecią, że tak ma być, że to oni mają rację i reszta się myli. Jak ktoś ma kiepską/złą/niezgodną ze standardem sieć, niech sam sobie poprawia GOS pod swoją sieć i nie zawraca nam głowy. To nie my mamy coś źle, a ta osoba (na własną odpowiedzialność); Nie do pominięcia jest też fakt, że niewielka grupa osób chce zmusić wszystkich do zużywania zasobów, bo tak i już, bo im nie działa i błędnie zakładają, iż jest ich cała masa.

[*]Przyśpieszy się, ale wyjdą dodatkowe problemy. Tobie i pewnie podobnym Tobie osobom będzie to wisieć, aczkolwiek:

* NTP nie będzie działać poprawnie podczas startu. Nie będzie, bo jak sieć nie wstanie (a może wstać np. po 25 sekundach), to nie przejdzie sprawdzenie czy jest PING i NFP po prostu nie zsynchronizuje czasu, mimo iż sieć później wstała. Ma to jeszcze jeden pejoratywny skutek - brak synchronizacji czasu z netu == automatem włączony czas z TP, a to z kolei odbije się bardzo negatywnie na pracy OSCAM - to już było omawiane!

* AutoFS i zasoby sieciowe - daemon wstanie, ale sieć później - zapomnij o działających udziałach;

* CIFS i inne - podobna sytuacja co wyżej;

Ogólnie dla garstki osób należy przeprojektować pół systemu, bo ich kiepską/złą/niezgodną ze standardem sieć niedomaga? Przypominam, że nadal mamy do czynienia z systemem typu Embedded!

[*]Zakładanie odgórne, że WiFi - którego może nie być w ogóle, jak i sterownika - jest bezsensem samym w sobie. Dyskusja z mojej strony zakończona. GOS ma tę zaletę, że masz w miarę proste i porządnie napisane skrypty startowe - modyfikuj pod siebie, wolno Ci;

[*]Zerknij jak działa NFS i zerknij do skryptów, a potem się wypowiadaj.

Wybaczcie użytkownicy kiepskiej/źłej/niezgodnej ze standardem sieci, ale nikt w GOS dla Was nie będzie dostosowywał systemu. To Wy, moi mili, macie obowiązek, jeśli chcecie mieć coś poprawnie funkcjonującego, mieć tak wykonaną sieć, aby nie sprawiała problemów. Nie po to w GOS prostujemy każdy kawałek systemu, by potem cofać się i nagle wprowadzać "system obchodzenia problemów użytkowników", którzy nie potrafią zrozumieć, że problemem nie jest GOS, a coś u nich, w tym wypadku ich sieć.

 

[robert_cz]

@tux, mam nadzieje, że się nie obrazisz, ale wziąłem sobie do serca to co powiedziałeś i sprawdziłem "wszystko" co zasugerowałeś:

- przyniosłem z pracy kable wyciągnięte z kartoników z telefonami VoIP Cisco - czy możemy uznać, że są zgodne ze standardem?

- odpaliłem "goły" router, ten z listy "wolniejszych" które wymieniłem w wyższych postach, z samym tylko dhcp i podłączyłem kablkem z punktu wyżej - czy tu jest coś poza standardem?

Efekt przy standardowych ustawieniach tuner IP nie dostał.

 

Dalej wziąłem switch Cisco, po to żeby nie zaburzać standardu sieci i odpaliłem na nim, na porcie do którego podłączyłem komputer, kopiowanie całej transmisji z portu do którego mam tuner podłączony, na komputerze Wireshark zarejestrował tylko jedno zapytanie o DHCP.

 

Czy poprawną metodologię zastosowałem?

Czy potwierdzisz, że problem jest w podnoszeniu warstwy Layer2 przed ukończeniem podnoszenia warstwy Layer1 TCP/IP?

Czy to jest zgodne ze standardem?

 

PS. Bardzo szanuje Wasz wkład i Waszą pracę w projekcie, za którą  bardzo dziękuję.

 

Podaj mi proszę adres, a chętnie wyślę Ci taki wolniejszy router, mam nawet jeden router Cisco, który też nie wyrabia się z odpowiedzią dla naszego boxa, czy router Cisco już Cię przekona?

[tux]

Jeżeli jest to "konsumencke" Cisco to mnie nie przekona!

Jest to temat na osobny wątek. W skrócie - Cisco chciało dać tanie COŚ dla domowego użytku. Wyszło koszmarnie a jeszcze zepsuli to co robił Linksys po tym jak go kupili.

W wyższych modelach (ale to już dziesiątki tysięcy złotych) tego problemu mieć nie będziesz.

 

Wracając do zapytań DHCP.

Obecnie w GOS jest ich chyba 10. Nie pamiętam teraz, wybacz....

Działa to tak:

• tuner śle 3x zapytanie do DHCP;
  
• po otrzymaniu pierwszego serwer robi analizę i pcha odpowiedź i tutaj
  - tuner dostanie odpowiedź pomiędzy 1-2 → nie da już zapytania 3;
  - tuner dostanie odpowiedź pomiędzy 2-3 → dostanie adres za trzecią odpowiedzią itd.
  

Na przestrzeni lat używałem dwóch daemonów jako DHCP Server.

• na PLD - DHCP - daemon można by napisać oryginalny;
  
• na PLD - DNS Masq - lekki daemon cacheujący DNS i przy okazji posiadający funkcję DHCP;
  

Za każdym razem konfiguracja była taka sama:

• każde urządzenie w sieci dostaje IP na podstawie MAC;
  
• jest pula pięciu IP przyznawanych MAC spoza listy.
  

W każdym przypadku DZIAŁA.

Jako, że jestem w trakcie modernizacji sieci w domu (będzie osobny post z info co zrobiłem i dlaczego bo może się komuś przydać) przetestowałem też kilka innych rozwiązań szukając urządzeń do konkretnych zadań. I tak szukając AP (bo potrzebowałem czegoś z 5GHz bo na 2,4GHz u mnie nie da się już pracować) przetestowałem je również jako routery. Do zawodów stanęły:

• Netgear WNDR4300;
  
• Asus RT-N53;
  
• Asus RT-AC56U (został jak AP, ale o tym w innym poście);
  

Dodatkowo bo miałem pod ręką to w celach naukowych (ten wątek) sprawdziłem:

• TP-Link TL-WR842ND;
  
• TP-Link TL-WR702N;
  

Więcej nie miałem pod ręką. Sprawdziłem zarówno soft oficjalny jak i DD-WRT/OpenWrt tam gdzie się dało. Co bym nie wyczyniał i tak zawsze tuner za 2 lub 3 zapytaniem dostawał dane. Tyczy się to zarówno LAN jak i WiFi. Z kart WiFi testowałem na karcie Ferguson 03 i Tl-WN727N.

Gdzie leży problem u Ciebie? Nie mam zielonego pojęcia, ale za diabła jasnego nie potrafię tego zreprodukować efektów, o których piszesz na pięciu urządzeniach, trzech wersjach softu na każdym z nich, dwóch sieciówkach WiFi i stosie kabli.

 

[robert_cz]

router Cisco w 100% profesjonalny, tylko wolny/stary, robił kiedyś za router do MPLS-a po E1.

 

@tux, a odpowiedz mi na jedno pytanie: Czy robiłeś kiedyś analizę ile tak naprawdę zapytań DHCP "wychodzi" po kablu w Twojej instalacji?

 

Ja też się upieram, że przy ifup -a box uruchamia warstwę Layer2 nie sprawdzając czy Layer1 się podniosło (co nie jest zgodne z żadnym standardem sieci, nie wiem czy to błąd tego programiku, czy założenie projektowe aby był lżejszy) w przeciwieństwie do ifplugd, które to jako bazę do uruchomienia Layer2 sprawdza czy Layer1 się podniosło, kosztem 0,6% pamięci naszych boxów i nie chodzi mi w ogóle o to, żeby chodził jako demon, tylko po to, żeby zadziałał ten raz kiedy jest podnoszona sieć.

 

Jednym słowem, jestem wstanie na 100% spełniającym standardy sprzęcie, który już nie jest na topie ale ciągle w obiegu i na 100% zgodnej ze standardem instalacji powtórzyć ten przypadek nieotrzymania adresu IP.

[Gość j00zek]

@tux: Przestań kombinować i szybko rób co kolega sobie życzy. Ma być jak użytkownik chce. Szybciutko....

 

 

[robert_cz]

@tux: Przestań kombinować i szybko rób co kolega sobie życzy. Ma być jak użytkownik chce. Szybciutko....

 

j00zek, a umiesz merytorycznie?

powiedz mi gdzie robię błąd skoro twierdzisz, że wymyślam.

A ja wcale nie nalegam na zmiany, już z naleganiem dałem sobie spokój, teraz dyskutuję o pewnym problemie i wymieniam pewne poglądy.

Nie można, zakazane jest to na tym forum?

[Gość smarkusg]

Ja mam bardzo ważną informację, przenieście proszę temat do "piszcie co chcecie".

@robert_cz będzie sobie testował co chce - wilk będzie syty i owca cala.

 

ps

Kurde.. znowu "wojna", wiosna jest jak by ktoś nie zauważył.Proponuję spacer :)

[sunfizz]

do @robert_cz

 

Zastanawiam się dlaczego nie dopiszesz co tam chcesz w skryptach startowych i po problemie, tylko upierasz się - na siłę przypisując błąd systemowi GOS ? Racja, może i jest słuszna, tylko że problem ten nie występuje u 99% użytkowników systemu GOS, korzystających z dhcp. Nie ma sensu zmieniać czegoś, co tak naprawdę jest bezproblemowe i działa tak jak przewiduje jego założenie.

[robert_cz]

do @robert_cz

 

Zastanawiam się dlaczego nie dopiszesz co tam chcesz w skryptach startowych i po problemie, tylko upierasz się - na siłę przypisując błąd systemowi GOS ? Racja, może i jest słuszna, tylko że problem ten nie występuje u 99% użytkowników systemu GOS, korzystających z dhcp. Nie ma sensu zmieniać czegoś, co tak naprawdę jest bezproblemowe i działa tak jak przewiduje jego założenie.

 

Ja nawet sam nie korzystam z DHCP, mnie po prostu intrygują takie tematy gdzie coś działa inaczej niż można się było spodziewać tak jak np. to, że warstwa 2 się odzywa zanim warstwa 1 skończy i intryguje mnie dlaczego ktoś to tak zaplanował, albo dlaczego tak wyszło.

 

PS. Trochę smutne, że nie umiemy rozmawiać merytorycznie.

[tux]

PS. Trochę smutne, że nie umiemy rozmawiać merytorycznie.

Jeżeli rozmowa merytoryczna to jedynie przyznanie Ci racji i dostosowanie się do Ciebie i tej małej grupy, którą reprezentujesz to tej rozmowy nie będzie. Nie jest to możliwe.

 

Podałem Ci konkrety. Jeżeli coś działa nie tak u Ciebie i tej małej grupy osób - sami szukajcie co. Ja nie mam czasu na zawracanie mi głowy czymś takim.

Jeżeli znajdziesz konkretny błąd, naprawisz to i podeślesz rozwiązanie - możemy pomyśleć nad wdrożeniem. Póki co wszystkim poza maleńką ilością osób działa.

 

Dla mnie koniec tematu i nie zamierzam dalej go kontynuować. W sumie nie tylko ja mam już dość.

 

[robert_cz]

PS. Trochę smutne, że nie umiemy rozmawiać merytorycznie.

Jeżeli rozmowa merytoryczna to jedynie przyznanie Ci racji i dostosowanie się do Ciebie i tej małej grupy, którą reprezentujesz to tej rozmowy nie będzie. Nie jest to możliwe.

 

Podałem Ci konkrety. Jeżeli coś działa nie tak u Ciebie i tej małej grupy osób - sami szukajcie co. Ja nie mam czasu na zawracanie mi głowy czymś takim.

Jeżeli znajdziesz konkretny błąd, naprawisz to i podeślesz rozwiązanie - możemy pomyśleć nad wdrożeniem. Póki co wszystkim poza maleńką ilością osób działa.

 

Dla mnie koniec tematu i nie zamierzam dalej go kontynuować. W sumie nie tylko ja mam już dość.

 

Ja tylko powtórzę moje pytanie zadane we wcześniejszych postach:

@tux, a odpowiedz mi na jedno pytanie: Czy robiłeś kiedyś analizę ile tak naprawdę zapytań DHCP "wychodzi" po kablu w Twojej instalacji i czy jakieś wychodzą w powietrze?

[tux]

Robiłem analizę. Od 1 do 3. Zależy od tunera i szybkości jego startu.

Jednak nie ma to absolutnie żadnego znaczenia ponieważ 99% ludzi nie widzi problemu. Nie ma wylewu setek czy tysięcy postów po forach.

Czasem coś komuś nie działa, ale to już normalne. Zawsze się znajdzie jakiś wyjątek.

 

A jako ciekawostkę do Twojej analizy (ja już daję sobie spokój z odpisaniem) napiszę:

• weź stoper do ręki;
  
• podepnij się do debug;
  
• i teraz:
  - sprawdź czas odpowiedzi PING na IP tunera przy DHCP ON;
  - sprawdź czas odpowiedzi PING na IP tunera przy stałym IP.
  

Zdziwisz się jak tuner ze stałym IP odpowie wcześniej niż z DHCP. Wniosek jest jeden - to nie tuner wysyła zapytanie w powietrze, to serwer DHCP odpowiada dłużej niż 3 sec i kończy się to jak się kończy. Może wystarczy zmienić na serwerze DHCP czasy oczekiwania?

Ale jak pisałem wyżej - to już nie mój problem. U mnie link każdy dekoder uzyskuje w czasie poniże 0,5 sekundy od czasu wpięcia kabla pod warunkiem, że karta sieciowa wstała (u-boot się uruchomił lub załadował się sterownik podczas startu). Biorąc pod uwagę, iż sterownik karty załadowany jest kilka sekund przed odpaleniem skryptu sieci to do jasnej XXXXX co rogi reszta sieci żeby się dogadać skoro u mnie jest to 0,5sec. Wtykam kable i zaraz świeci.

 

[robert_cz]

@tux, a Twoim zdaniem takie zachowanie ifup że wysyła zapytania o DHCP zanim potwierdzi, że podniosła się warstwa pierwsza jest zgodne ze standardem?

 

A może ifup powinien mieć dodane sprawdzanie czy jest już link zanim zacznie wysyłać zapytania DHCP tak jak to ma ifplugd?

 

Takie coś ma np. tu:

http://git.busybox.net/busybox/tree/networking/ifplugd.c#n215

http://git.busybox.net/busybox/tree/networking/ifplugd.c#n285

http://git.busybox.net/busybox/tree/networking/ifplugd.c#n375

 

[tux]

@tux, a Twoim zdaniem takie zachowanie ifup że wysyła zapytania o DHCP zanim potwierdzi, że podniosła się warstwa pierwsza jest zgodne ze standardem?

Dla systemu Embedded TAK.

 

Zauważ, że masz do dyspozycji aż 60MB w NAND. Spróbuj tam wepchnąć pełnego klienta DHCP wraz ze wszystkimi jego zależnościami.

Systemy Embedded rządzą się innymi prawami.

Na tym z mojej strony KONIEC. KOMPLETNY KONIEC. Dyskusja jest bez sensu póki nie zrozumiesz, że nie masz do czynienia z pełnym systemem Linux a wersją, która ma wykonać konkretne zadania i implementacja każdej funkcjonalności nie jest możliwa.

 

A tak poza tym. Skoro u mnie nie wysyła w kosmos to znaczy, że mój serwer DHCP odpowiada. Skoro u Ciebie jest inaczej to może zacznij od doprowadzenia serwera DHCP do stanu, w którym zacznie odpowiadać na zapytania.

Jeżeli link masz spóźniony to doprowadź u siebie do tego, żeby był ustanawiany w odpowiednim czasie.

Może problemem są niektóre boxy? Może rodzaj przeróbki, może inny czynnik?

 

Zawsze najłatwiej szukać wszędzie byle nie tam gdzie trzeba.

[robert_cz]

@tux, a Twoim zdaniem takie zachowanie ifup że wysyła zapytania o DHCP zanim potwierdzi, że podniosła się warstwa pierwsza jest zgodne ze standardem?

Dla systemu Embedded TAK.

 

Zauważ, że masz do dyspozycji aż 60MB w NAND. Spróbuj tam wepchnąć pełnego klienta DHCP wraz ze wszystkimi jego zależnościami.

Systemy Embedded rządzą się innymi prawami.

Na tym z mojej strony KONIEC. KOMPLETNY KONIEC. Dyskusja jest bez sensu póki nie zrozumiesz, że nie masz do czynienia z pełnym systemem Linux a wersją, która ma wykonać konkretne zadania i implementacja każdej funkcjonalności nie jest możliwa.

 

A tak poza tym. Skoro u mnie nie wysyła w kosmos to znaczy, że mój serwer DHCP odpowiada. Skoro u Ciebie jest inaczej to może zacznij od doprowadzenia serwera DHCP do stanu, w którym zacznie odpowiadać na zapytania.

Jeżeli link masz spóźniony to doprowadź u siebie do tego, żeby był ustanawiany w odpowiednim czasie.

Może problemem są niektóre boxy? Może rodzaj przeróbki, może inny czynnik?

 

Zawsze najłatwiej szukać wszędzie byle nie tam gdzie trzeba.

 

Skoro twierdzisz, że w przypadku systemów embeded można przymknąć oko, na niezgodność ze standardem, to OK, tej części nie będę poruszał.

Naprawdę sądzisz, że dopisanie do kodu ifup jednej linijki sprawdzania czy jest już link przed wysyłaniem zapytań DHCP spowoduje, że braknie 60MB?

 

Ja szukam wszędzie, nawet w boxach.

[tux]

Tak, będzie to problem. Dlaczego? Dlatego, że nie każdy używa sieci. Zakładając, że sieci może nie być to już nie jedna czy dwie linie a cały system kontroli czy sieciówka jest w ogóle skonfigurowana, następnie czy jest włączona w konfiguracji i jeszcze na koniec kawałek inteligencji omijającej konfigurację sieci jak nie dostanie IP po kilku razach.

 

Jeżeli masz pomysł i chcesz coś włożyć w GOS - napisz coś takiego. Dodamy :) (po testach w gałęzi TEST).

 

Systemy wbudowane mają to do siebie, że działają tak jakie są założenia. W tym wypadku cały system obsługi sieci jest minimalny bo zasoby (każde) boxa nie pozwalają na implementację pełnej obsługi. Przy tym założeniu sieć na boxie działa całkowicie prawidłowo. Jednym z założeń jest to, że druga strona (serwer) odpowiada na zapytania jak powinien a sam link jest ustanawiany od razu a nie po bliżej nieokreślonym czasie zastanawiania się co by tu zrobić.

Przy czym w przypadku nBoxa stawiam na to, że są różne wersje HARDWARE i po różnych przejściach bo kupuje się nie fabrycznie nowe tunery a odnowione. Wystarczy, że nasz nBox przeżył kilka "ataków" wyższego napięcia i ma transformatory na wejściu LAN nadwyrężone. Wtedy nie trudno o długi proces negocjacji.

[robert_cz]

Tu można znaleźć maksymalne czasy ustanowienia linku na poziomie ethernet:

http://www.ieee802.org/3/af/public/jan02/brown_1_0102.pdf

[tux]

Dla BCM :)

Teraz rozumiem dlaczego tak mocno wielu trzyma się z daleka od tej firmy.

[robert_cz]

Dla BCM :)

Teraz rozumiem dlaczego tak mocno wielu trzyma się z daleka od tej firmy.

Dobra poszukam dokładniej w dokumentacji standardu Ethernet zamiast w prezentacji jednego z producentów który dane z tego standardu prezentuje.

[tux]

Akurat BCM faktycznie tak działa i sam widziałem to na oczy w kilku rozwiązaniach. Wtykam kabel i NIC. Po 1,5 sekundy zazwyczaj zastanawiam się czy nie mam walniętego kabla. A tu niespodzianka, jeszcze z sekundę i mam LINKA :)

 

W załączniku masz busybox z -t 10 wkompilowanym (prawdopodobnie bo nie mam jak teraz sprawdzić). Podmień (pamiętaj o wypakowaniu i 755). Napisz czy masz 10 zapytań.

busybox.gz

[robert_cz]

Akurat BCM faktycznie tak działa i sam widziałem to na oczy w kilku rozwiązaniach. Wtykam kabel i NIC. Po 1,5 sekundy zazwyczaj zastanawiam się czy nie mam walniętego kabla. A tu niespodzianka, jeszcze z sekundę i mam LINKA :)

 

W załączniku masz busybox z -t 10 wkompilowanym (prawdopodobnie bo nie mam jak teraz sprawdzić). Podmień (pamiętaj o wypakowaniu i 755). Napisz czy masz 10 zapytań.

 

Jeszcze nie mogłem sprawdzić, nie ma mnie w domu. Dzięki za modyfikację, na 100% sprawdzę, ale wydaje mi się, że 10 to trochę dużo, są takie nboxy które nie mają karty sieciowej i tam o te 10 prób po 3 sekundy się przedłuży.

 

[mickey]

To nie za dużo bo w sumie to niewiele robi.

 

Polecenie ifup -a odpala klienta DHCP i oddaje kontrolę systemowi. Nie czeka na IP, po prostu leci dalej. A po 30 sekundach się wyłączy jak IP nie dostanie. Jak dostanie w 3-iej próbie to się wyłączy po trzech.

 

Natomiast wpisane sleep X powoduje właśnie, że przez X sekund system stoi.

[robert_cz]

@tux, wiem, że nie przepadasz za tematem, ale jest ciągle jedna rzecz której nie rozumiem.

przy starcie udhcpc odpala się z parametrami -R -n (tak przynajmniej pokazuje htop).

 

-n,--now                Exit if lease is not obtained

-R,--release            Release IP on exit

 

to -R powoduje, że po pobraniu IP proces udhcpc ciągle pozostaje w pamięci tunera. Czy to jest konieczne?

A znów -n powoduje, że jak nie dostanie IP to proces udhcpc się zamyka.

 

Nie powinno być odwrotnie?

 

zamiast -n nie lepsze by było:

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

a z -R w ogóle bym zrezygnował.

 

Spowodowałoby to, że jeśli tuner dostanie IP, to udhcpc zwalnia cenną pamięć tunera, a jeśli nie dostanie IP, no to wtedy jego praca w tle miałaby sens.

 

Co Ty na to?

 

[areq]

Server DHCP daje lease na określony czas, rożny w zależności od konfiguracji, dlatego demon musi pozostać aktywny by odnowić dzierżawę w stosownym czasie. -R jest potrzebne, gasisz tuner to wysyłane jest info do servera DHCP ze IP już niepotrzebny.

[robert_cz]

no dobra, zgdozę się z tym, że -R można uznać za potrzebne, ale -n ja bym zmienił na -b.