Jasne. Widziałeś ten program ??? Jak zobaczysz to się wypowiedz.


Facet, co ma wspolnego komunikat ICMP jakim jest ICMP ECHO REPLY (czyli
odpowiedź na PING), z IGMP (Internet Group Managment Protocol)?
Jak sie douczysz to sie wypowiedz.

Facet, co ma wspolnego komunikat ICMP jakim jest ICMP ECHO REPLY (czyli
odpowiedź na PING), z IGMP (Internet Group Managment Protocol)?


zapytajmy chłopaków z symanteca.

Jak sie douczysz to sie wypowiedz.


a skoro doczytałeś to może by tak odpowiedź na pytanie z topiku ?

Frantz

Na serwerku (Mandrake 9.2) przestały się logować zdarzenia do messages.
Postanowiłem go przeładować, niestety shutdown -r now nie chciało działać
i nacisnąłem na krótko przycisk power na obudowie.
w syslogu ostatni komunikat mówi: apmd: User Suspend
Mam wrażenie że system sie zahibernował i teraz próbuje sie odhibernować,
ale mu nie wychodzi.
Oto co widać na ekranie w momencie gdy sie zatrzymuje:

NET4: Linux TCP/IP 1.0 for NET4.0
IP: Protocols: ICMP, UDP, TCP, IGMP
IP: Routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 65536)
Linux IP multicast router 0.06 plus PIM-SM
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
Resume Machine:   This is normal swap space
RAMDISK: Compressed image found at block 0
Swsusp 1.0.3: kswsuspd starting
Freeing initrd memory: 89k freed
VFS mounted root (ext2 filesystem).
Mounted devfs on /dev
Red Hat nash version 3.4.43-mdk starting
Loading jbd.o module
Journalled Block device driver loaded
Loading ext3.o module
Mounting /proc filesystem
Creating root device
Mounting root filesystem
kjournald starting. Commit interval 5 seconds.
EXT3-fs: mounted filesystem with ordered data mode.
Remounting devfs at correct place is necessary
mounted devfs on /dev
Freeing unused kernel memory: 156k freed

Co z tym fantem zrobić ??
fsck nie pomaga, zastąpienie /etc/ kopią z backupu tez nie :(

ktos ma jakieś pomysły ??

Witam,

        Czesciowo znam odpowiedź: "dobrze działa" :-) Chodzi mi jednak, jak
to jest w praktyce zrealizwoane. W połączeniach TCP wyszystkoe się zgadza:
protkół połączeniowy, czasy retransmisji, itp okreslone, wiadomo kiedy
połączenie się zaczyna i kiedy kończy (a przynajmniej jak długo należy
czekać nim się uzna, że nastąpiło rozłączenie).

        A jak to jest w przypadku UDP? Jesli mój klient wysle do serwwera
zapytanie UDP to skad firewall wie jak dlugo należy pamiętać, że
przybywająca z serwera odpowiedź należy powiązać z tym, a nie innym
klientem?

Poza tym czasami wysyła się infromacje UDP tylko w jednym kierunku (np.
trapy SNMP) i to w dużych ilosciach.  Czy maskarada o kazdym takim pakiecie
pamieta?  Co w przypadku kiedy na komunikat IGMP przychodzi w odpowiedzi
setki pakietow na sekunde pakietów multicast UDP?

Wiem, ze to wszystko dziala, tylko jak? :)

On 13.12.2008, Antoni.Bura@gmail.com <la@127.0.0.1wrote:

   Czesciowo znam odpowiedź: "dobrze działa" :-) Chodzi mi jednak, jak
to jest w praktyce zrealizwoane. W połączeniach TCP wyszystkoe się zgadza:
protkół połączeniowy, czasy retransmisji, itp okreslone, wiadomo kiedy
połączenie się zaczyna i kiedy kończy (a przynajmniej jak długo należy
czekać nim się uzna, że nastąpiło rozłączenie).

   A jak to jest w przypadku UDP? Jesli mój klient wysle do serwwera
zapytanie UDP to skad firewall wie jak dlugo należy pamiętać, że
przybywająca z serwera odpowiedź należy powiązać z tym, a nie innym
klientem?


Dokładnie tak samo jak w przypadku TCP. Skąd wiesz że połączenie TCP nie
zostało zablokowane na przykład na firewallu? Wtedy nie masz ACK+FIN
kończącego połączenia, a natownica musi sobie z tym jakoś poradzić.

Poza tym czasami wysyła się infromacje UDP tylko w jednym kierunku (np.
trapy SNMP) i to w dużych ilosciach.  Czy maskarada o kazdym takim pakiecie
pamieta?


Tak. Możesz sobie to sprawdzić w /procu.

Co w przypadku kiedy na komunikat IGMP przychodzi w odpowiedzi
setki pakietow na sekunde pakietów multicast UDP?

Wiem, ze to wszystko dziala, tylko jak? :)


--
Secunia non olet.
Stanislaw Klekot

Witam!

Dzialal mi Red Hat 7.2 az pewnego dnia naszla mnie ochota na kompilacje
jadra i po jego uruchomieniu dostalem komunikat:

NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
ds: no socket drivers loaded!

I jak mozna sie latwo domyslic siec nie dziala. Sterownik karty
sieciowej jest taki sam jak oryginalny: RTL8139, konfiguracje robilem
przy pomocy xconfig

Czy ktos moze mi dac jakies wskazowki jak sie tego pozbyc?

Pozdrawiam,
Marek

Użytkownik Marek Berkan <M.Ber@mberkan.plw wiadomości do grup
dyskusyjnych napisał:3C1FD836.8040@mberkan.pl...

Witam!

Dzialal mi Red Hat 7.2 az pewnego dnia naszla mnie ochota na kompilacje
jadra i po jego uruchomieniu dostalem komunikat:

NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP: Hash tables configured (established 32768 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
ds: no socket drivers loaded!

I jak mozna sie latwo domyslic siec nie dziala. Sterownik karty
sieciowej jest taki sam jak oryginalny: RTL8139, konfiguracje robilem
przy pomocy xconfig

Czy ktos moze mi dac jakies wskazowki jak sie tego pozbyc?

Pozdrawiam,
Marek


Jaki masz kernel ?
Z ta sieciowka zaraz po zainstalowaniu na 2.4.5 sa problemy (przynajmniej u
mnie). Niby dziala wszystko ok i pingi rowniez, problemy zaczynaja sie jak
zaczynasz sciagac wieksze pliki ( np. z lokalnej) transfer sie zatrzymuje
:(((
Ja skompilowalem jajko 2.4.16 i wreszcie zaczelo dzialac OK.
Nie wiem co bylo przyczyna bo po zainstalowaniu niby szlo rtl8139too ale w
rzeczywistosci dobrze nie dzialalo. Acha co charakterystyczne przy starcie
kompa przy ustawianiu IP mialem linijke ....incompatibile conection
Polecam 2.4.16 dziala bez zarzutow.
Pzdr

On Thu, 22 Dec 2005 14:08:20 +0100, Marko wrote:
Witam ,

czy ktos moze zdiagnozowac taki komunikat ?

Malformed or unhandled IP packet dropped -         192.168.100.90, 0, LAN -
224.0.0.22 -       IP Protocol 2


To pakiet multicast IGMP wysłany z komputera w sieci z adresami z klasy C
RFC 1918.
Napisz coś więcej bo trochę mało informacji podajesz.

Zgodnie z sugestia testera wyciekow poprzez firewalle, zainstalowalem
Winsock2 dla Win95 sciagniety ze stron Malegomiekkiego. Uzywam dialupu.

O ile przedtem bylo spokojnie, to teraz w pakieciarni widze:
1) natychmiast po kazdym polaczeniu sie z siecia jest wyslanych 5 pakietow
pod adres 224.0.0.2 zidentyfikowany przez DNS-a jako ALL-ROUTERS.MCAST.NET
Wlasnie tak, duzymi literami.
Gdy zablokuje dostep do sieci _przed_zalogowaniem_ sie to mam komunikat od
ZoneAlarm:
The firewall has blocked Internet access to the all routers multicast
address (224.0.0.2)(ICMP Router Solicit)...

2) Przy kazdym rozlaczeniu sie z siecia leci ostatni, szosty, pakiet pod
ten adres.
Gdy zablokuje dostep do sieci _przed_rozlaczeniem_ sie to mam komunikat od
ZA:
The firewall has blocked Internet access to the all routers multicast
address (224.0.0.2) (IGMP Leave Group)...

Nigdy mniej, nigdy wiecej pakietow. Otwartym tekstem nic nie jest w nich
napisane. Sa malutkie.
Co ten adres oznacza i po co wysylane sa pakiety? Maja na celu ewidencje
czasu rozpoczecia i zakonczenia bytnosci w sieci?
Wiem, wiem... Oni szpieguja mnie na kazdym kroku;-)
Jakies sugestie? Zmienic system?;-) Zgodnie z trzema antyszpiegami nie mam
zadnych 'niepotrzebnych' plikow Windowsowych.

Nawiązując do postu z Wed, 9 Aug 2000 11:48:18 +0200 autorstwa Michal Zalewski (lcam@dione.ids.pl):
: Hmm... ICMP to jest ta sama warstwa co IP :)
: Nieprawda. ICMP, podobnie jak UDP czy TCP jest protokolem podrzednym
: wzgledem IP.

W modelu OSI/ISO ICMP jest w trzeciej warstwie razem z IP oraz IGMP.
Poza tym ICMP jest rozszerzeniem protokolu IP, a nie osobnym
protokolem enkapsulowanym w IP. I nie sprzeczaj sie, bo tak jest i juz
:)

: Jak najbardziej ma. Zapraszam do RFC. Ten naglowek jest oczywiscie duzo
: bardziej ubogi (opisuje typ i podtyp komunikatu ICMP, zawiera jego wlasna
: sume kontrolna, a w payloadzie posiada poczatek pakietu IP, na ktory
: stanowi odpowiedz).

Eh, zrob raz cos porzadnego zamiast caly czas krytykowac innych.

On Wed, 9 Aug 2000, Grzegorz Janoszka wrote:
:Hmm... ICMP to jest ta sama warstwa co IP :)
: Nieprawda. ICMP, podobnie jak UDP czy TCP jest protokolem podrzednym
: wzgledem IP.

W modelu OSI/ISO ICMP jest w trzeciej warstwie razem z IP oraz IGMP.
Poza tym ICMP jest rozszerzeniem protokolu IP, a nie osobnym
protokolem enkapsulowanym w IP. I nie sprzeczaj sie, bo tak jest i juz
:)


W takim samym stopniu jak TCP nie jest oddzielnym protokolem. Sam pakiet
TCP nie zawiera informacji wystarczajacych do zroutowania go (zreszta
nawet informacje o tym, ze to TCP znajduja sie w naglowku IP). ICMP jest
integralna czescia komunikacji IP, tu nie przecze - choc IMHO mniej wiecej
tak samo integralna, jak np TCP - i pod wzgledem "konstrukcji" jest to
pakiet osadzony w IP. Koniec. Naglowek IP. Naglowek [ICMP|TCP|UDP]. Dane.
Nie polemizuje z ISO, tylko zwracam uwage na pewien detal konstrukcyjny -
ty stwierdziles, ze "ICMP nawet wlasciwie nie ma naglowka" i dales do
zrozumienia, ze odroznia sie od UDP czy TCP. ICMP od UDP rozni sie tylko
zastosowaniem oraz brakiem portow w naglowku - natomiast sumy kontrolne,
typ komunikatu, podtyp etc posiada.

Eh, zrob raz cos porzadnego zamiast caly czas krytykowac innych.


Czasem robie ;

_______________________________________________________
Michal Zalewski [lcam@tpi.pl] [tp.internet/security]
[http://lcamtuf.na.export.pl] <=--=bash$ :(){ :|:&};:
=-----=God is real, unless declared integer. <=-----=

Łukasz Bromirski napisał(a):

icek wrote:
| jakies idee dlaczego tak się dzieje?
| cos dodatkowo opisać?

Jak rozumiem, cały test przeprowadzasz w jednym VLANie jednego
przełącznika?


tak
robiłem tez tak, ze testy robiłem w jednym VLANie ale na dwóch
podłączonych przełącznikach, tzn. do jednego wpinałem vlc nadające, a do
drugiego odbierające
raz, zrobiłem tak:
wpiełem planet WGSD1020 (on ma IGMP querier) do niego vlc transmitter, a
do linksysa wpiełem vlc receiver..
było ok.. ale jak wpiełem 2 vlc receiever do linksysa i dałem stop
(oglądając stumien z 225.0.0.5, to na drugim tez transmisja się
zatrzymywała, ale moze było to dlatego, ze ten planet ma tylko IGMPv1? -
tak strzeliłem..

Jeśli chodzi o Linksysa, przejrzyj dokładnie rozdział w podręczniku
opisujący multicasty (IGMP Snooping) oraz konfigurację ich
bridgingu. Jest tam duża ilość różnego rodzaju timeoutów do ustawienia.


mozesz dać jakąś wskazówkę?
ten manual znam prawie na pamięc :(
męcze te linksysa od kilku tygodni :(
support linksysa jest do bani, ten w EU, teraz pisze do US, może coś mi
pomogą..

najgorsze, ze jak snifuje to nie widze zadnych komunikatów IGMP (a na
innych przełącznikach widze) no i ból, ze tam gdzie liste przy bridge
multicast ustawiam, nie moge dac dynamic :( wygląda jakby opcja była
niedostępna :(

icek wrote:
mozesz dać jakąś wskazówkę?
ten manual znam prawie na pamięc :(
męcze te linksysa od kilku tygodni :(
support linksysa jest do bani, ten w EU, teraz pisze do US, może coś mi
pomogą..

najgorsze, ze jak snifuje to nie widze zadnych komunikatów IGMP (a na
innych przełącznikach widze) no i ból, ze tam gdzie liste przy bridge
multicast ustawiam, nie moge dac dynamic :( wygląda jakby opcja była
niedostępna :(


Skontaktuj się z dystrybutorem, od którego kupiłeś sprzęt i poproś
o pomoc techniczną.

icek napisał(a):

a z tym wysyłaniem IGMP leave.. to sam juz nie wiem..
z jednej strony wydaje mi się ze moze, ale z drugiej strony nie wysyła
nic (snifuje cały czas) więc moze stacja nie moze wysłac takiego
komunikaty? Zakładając ze nie moze to skąd miałby się wziąśc IGMP leave
aby transmisja nie szła do klienta? Z dowodu nie wprost wychodzi mi
jednak ze stacja moze wysłać IGMP leave.. mozesz mi dać "wędke" aby
zaczał szukać co jest nie tak?


w jednym z tych dokumentów co mi podałeś, znalazłem ze host wysyła
IGMP leave
teraz to juz nie wiem gdzie mam jakiś błąd, więc proszę o "wędkę" do
rozwiązania problemu.