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

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, 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

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?

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.

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?

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.

@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?

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

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

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?

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ć.

Witam, Czy w Moderate Shut Down istnieje możliwość żeby dało się wyjść za pomocą przycisku włącznika na panelu przednim dekodera, bo aktualnie na moim BSKA nie działa, działa tylko z pilota.

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ć.

a sprawdzasz czy te pierwsze dwa zapytania oo DHCP wychodzą wogóle w sieć z tunera? Bo ja to sprawdziłem i nie wychodzą. Umówmy się tak, że jak trafię na taki router który się nie wyrabia, to Ci wyślę żebyś mógł to potwierdzić.

Przepraszam za off-topic, ale jakoś tak ja też nie mogłem się powstrzymać. Pozwolisz, że z jednym punktem się nie zgodzę, z tym dhcp, to problemem jest jednak box, bo wysyła zapytania w powietrze zanim się port podniesie. I to moim zdaniem jest właśnie niezgodność ze standardem. A dobry sprzęt sieciowy w tym wypadku w ostatnich sekundach się wyrabia, a ten z dolnej półki (ale mieszczący się w standardach) nie. Oczywiście lepiej mieć sprzęt sieciowy lepszy niż ten gorszy i tu się z Wami zgadzam w 100%. :-) Taka jest moja opinia poparta obserwacją rzeczywistości i mam nadzieje mi na nią pozwolicie :-)

@tux Ale czy ja się na coś upieram?? Jak najbardziej zrozumiałem i tak jak napisałem wcześniej zmieniam porty i chce wyłączyć logowanie na roota i przesiąść się na su, czy to mało. czy ja się upieram, że chce zmian? NIE, NIE, NIE. Podaję tylko pomysły standardowych rozwiązań stosowanych przez innych. PS. Nie wiem, ale czy to forum zostało stworzone do dyskusji o dystrybucji na nasze tunerki, czy do obrażania mniej zaawansowanych użytkowników, bo się czasem zastanawiam? :-( To przeanalizuj proszę jeszcze raz moje wątki i jest kilka w których się myliłem i się do tego przyznałem oraz bardzo wiele w których miałem rację. A czy Ty się nigdy nie mylisz? Ja z czytania tego forum, nie zauważyłem ani razu żebyś napisał, że się myliłeś, mylę się? To chyba jednak Ty zasługujesz na takie określenie które zastosowałeś wobec mnie. Ja już kończę "prywatne wycieczki" bo one do niczego nie prowadzą. Zastosowałem się do rad i bardzo za nie dziękuję.

j00zek, czy mógłbyś, poproszę bez osobistych wycieczek. Ja się staram nikogo nie obrażać nawet jak się z nim nie zgadzam i wybacz, ale nie wszyscy wszystko wiedzą, nawet Ty.

To ja proponuję zamknąć ten wątek, bo już zostało w nim napisane wszystko co mogło być napisane, a ja, jeśli pozwolicie potestuję stosowanie su i wyłączenie roota i dam znać w nowym wątku o "su" na graterli.

i wyszło: Przepraszam, ale nie mogłem się powstrzymać... :P Nie jednak wyszło inne niż Dupa#123 A powiedz mi skąd pewność, że Twoje "niesłownikowe hasło" nie trafi kiedyś na jakąś listę i ze skomplikowanego ciągu znaków stanie się słownikowym? Przeglądałeś listę tych "słownikowych" zastosowanych w tym ataku? Bo sporo jest takich na słownikowe nie wyglądających.

mi po chown i chmod działa su bez problemu :-) Testowo wyłączę sobie logowanie na roota przez ssh i popracuję kilka dni i dam znać.

Co wy na to, żeby można było odinstalowywać paczkę demona ftp? Od początku nie skorzystałem z ftp wszystko wysyłam i pobieram przez ssh. próbował ktoś odinstalowywać z opcją force, widzicie jakieś przeciwwskazania? GraterliaOS:~# opkg list-installed *ftp* vsftpd - 3.0.2.3 GraterliaOS:~# opkg remove vsftpd No packages removed. Collected errors: * print_dependents_warning: Package vsftpd is depended upon by packages: * print_dependents_warning: system-core * print_dependents_warning: These might cease to work if package vsftpd is removed. * print_dependents_warning: Force removal of this package with --force-depends. * print_dependents_warning: Force removal of this package and its dependents * print_dependents_warning: with --force-removal-of-dependent-packages. GraterliaOS:~#

Ja wymyśliłem dość skomplikowane (cyfry, małe duże litery + znaki specjalne) i okazało się, że było na liście tych słownikowych :-( Więc to nie daje gwarancji. walczę z su i mam coś takiego: $ su root Password: su: can't set groups: Operation not permitted $ jak dam: # chown root:root /bin/su # chmod u+s /bin/su To zaczyna działać, dziwne, bo: ls -l /bin/su ls -l /bin/busibox wygląda tak zamo przed i po chmod. nic z tego nie rozumiem. :-(

Dora, nie upieram się :-) Ale sprawdzę opcję drugiego użytkownika i wyłączenia roota. Jak zadziała dodacie do FAQ?