ICMP, iedereen heeft er wel eens van gehoord, was het niet onder ICMP, dan was het wel onder de naam ping of onder de naam trace route.
Neen, ICMP= niet ping, ICMP= ook niet trace route maar ping is wel ICMP en trace rute bestaat ook uit ICMP

moeilijk ? nee hoor ...Internet Control Message Protocol (RFC792) een protocol dat instaat voor het medelen of testen van de netwerk-connectiviteit. ping is hier een onderdeel van, net zoals trace route.

leuk ? ja hoor, best wel, lees maar verder ...

Laten we eens een ping bekijken. Als je een ping doet naar je localhost (127.0.0.1 = default loopback adress) krijg je ongeveer zoiets

ping localhost : Reply from 127.0.0.1: bytes=32 time<1ms TTL=128

het eerste deel is duidelijk denk ik, je krijgt een antwoord.
het tweede deel, "bytes=32" defineert de grootte van het verzonden ICMP packet, in dit geval 32 bytes, dit kan je vergroten of verkleinen met de optie -l

ping -l 1024 localhost : Reply from 127.0.0.1: bytes=1024 time<1ms TTL=128 het packet dat je stuurt is in dit geval veel groter, dit kan een verschillend resultaat opgeven in geval van netwerk problemen.

de tijd (time<1ms) is ook vrij duidelijk, dat is de tijd die overgaat vooraleer je een antwoord gekregen hebt. (hieruit wordt de round-trip delay bepaald)

en dan het laatste gedeelte :ooit gehoord van TTL ? TTL staat voor time to live.

Als een packet verzonden wordt op een netwerk, dan krijgt het een TTL waarde mee, dit is een waarde uitgedrukt in hops (een hop is een routeringspunt waar het packet passeert)
Standaard op een windows doos, heeft een packet een TTL van 128. Op een *nix doos of op een router, is de TTL default 64 (maar dit hoeft zo niet te zijn, dit kan perfect aangepast worden, zelfs in een windoos)

wat is nu Time to live ? Letterlijk vertaalt: tijd om te leven. Welnu, elke keer als dit packet een router passeert, krijg je TTL -1, dus als je met je windoos een packet stuurt naar een bestemming die 5 hops verwijderd is van je pc ( een ping naar een dns server van je provider bv) dan komt je icmp packetje daar toe met een TTL van 120 ; geen probleem dus, het packetje valt perfect binnen de grenzen van TTL en wordt op dit vlak dus perfect geaccepteerd.

een netwerk (internet) bestaat uit routes, elke destinatie moet via wegwijzers gedefineerd zijn. Wanneer er zich een fout in deze routering bevindt, wil dit zeggen dat de kans groot is dat er ergens routing-loops ontstaan wat erop neer komt dat bepaalde packetten doelloos op het netwerk blijven ronddolen.

Om dit te voorkomen, is deze TTL in leven geroepen. Eens de TTL bereikt is word het packet onvermijdelijk weggegooid ( discarded) en wordt er een ICMP message terug gestuurd dat de doelhost niet bereikbaar is. (vandaar dat ik een pest heb aan firewalls die icmp blokkeren, dit is meer in uw nadeel dan in uw voordeel ..)

Dit brengt ons dan ook ineens bij de werking van tracert of trace route.

Bij een trace route, worden er opeenvolgend ICMP packetten uitgezonden met een TTL van +1. Eens de eerste hop bereikt, wordt het packet ge-discard en krijgt de vragende machine daar bericht van; op deze manier weet je doos de naam en IP-address van de machine die het packet gedropt heeft. Vervolgens verzend je machine een packet met dezelfde destinatie maar met en TTL van +1. De machine na diegene die zojuist een packet heeft gedropt, zend je een ICMP bericht dat het packet gedropt is wegens een verstreken TTL (TTL expired). Op deze manier heb je dan reeds de naam en ip van de eerste & de tweede hop... dit gaat zo door tot de uiteindelijke bestemming in kaart gebracht is, met als resultaat de bekende trace route....


ICMP doet nog veel meer, als een doelhost bv niet kan volgen in dataflow, word er via ICMP een bericht gestuurd de transmissie te vertragen/stoppen.Vandaar dat U er alle baat bij heeft dit protocol wel toe te laten.

Tot slot kan ik jullie verzekeren dat het blokkeren van ICMP weinig gaat doen aan de veiligheid van je netwerk, tenslotte, tcp bestaat uit een 3-way handshake, dus ook al antwoord een netwerk niet op een ping, dat wi écht niet zeggen dat het niet detecteerbaar is. ( lees de paginas op http://insecure.org/nmap/ (http://http://insecure.org/nmap/) maar eens ;-)

groetjes
L.

Blijkbaar weet je meer van het lagere level achter ethernet, daarom deze vraag waar ik al een tijdje mee zit en niet opgelost krijg;)
Ik heb aan de ene zijde een meetinstrument bestaande uit een risc micro controller met een ethernet aansluiting werkend als client. Aan de andere zijde is een pc met een delphi programma dat data ontvangt van de client over tcp/ip.
De data is eigenlijk een datastream, dus de client opend de connectie, de server established en data wordt verzonden. De data loopt continu over deze verbinding en de connectie wordt dus niet afgesloten.
Wat heb ik nu aan de hand:
Als ik het programma van de pc afsluit wordt de connectie verbroken. Start ik het programma op pc weer op, duurd het exact 2 minuten vooraleer ik weer connectie kan maken met mijn meettoestel. Met een sniffer zie ik dat als het meettoestel een connectie wil openen hij telkens 'RST' terug krijgt ipv 'ACK'. Nu blijkt dat in het TCP/IP protocol ergens een tijd zit gebakken dat als een connectie niet op de juiste manier wordt afgesoten er een time out is van exact 2 minuten. Dit is omdat er nog pakkettjes van een vorige verbinding ergens kunnen rond dolen op het netwerk.
Is er ergens een manier of instelling waar ik die tijd kan veranderen? 2 minuten is wel erg lang als je moet wachten. Nu kan je zeggen: zorg dat je uw verbinding op de juiste manier afsluit, maar zowel de pc als het meetinstrument kan gewoon met een switch worden uitgezet. Resultaat, spanningsloos en dus geen afsluit sequentie.
Tot nu toe heb ik dus geen oplossing gevonden.

Groetjes,

Peter

Peter,

het rst (reset) packet dat je terug krijgt, duid er inderdaad op, dat je risc geen 2de connectie toelaat en weldegelijk wacht op een Fin. als je een fin packet stuurt, zal je daarna terug kunnen connecteren. Dit is eigenlijk het principe waar een dos-attack op berust. ( 3 way handshake --> sync, syn-ack, ack. zolang de remote kant geen ack ontvangt, heb je een half open connectie die openblijft todat de timeout is bereikt, als je dit dusdanig aantal x herhaalt, loopt de tcp-stack buffer vol en accepteert de machine geen tcp sync packetten meer : dan heb je een dos-attack = denial of service.) gezien je box maar 1 tcp half open connect toelaat, heb je bij de 2de connect eigenlijk al het effect dat plaatsvind bij een DOS.

er zijn normaal bij mijn weten 2 mogelijkheden : of je zet de half open connection timeout zeer kort, of je zorgt dat de box meerdere meerdere TCP connects toelaat. ( dit zijn zeker niet de mogelijkheden om een dos tegen tegaan, maar wel om misschien uw probleem te verhelpen)

gezien ik de box niet ken, weet ik ook niet of dit configureerbaar/customisable is. Je zou eens kunnen proberen om die doos af te scannen op tcp-poorten die diezelfde service draaien, of tijdens die 2min timeout, een tcp connect te initiëren vanaf een ander source ip adres. Naar welke poort connecteerd je delphi client ?


groeten
L.

Het is het delphi programma dat op pc draaid dat de server is, de risc computer is de client. Dus wanneer de risc controler terug connectie wil maken met de pc, krijg ik RST terug van de pc;)
De risc controler maakt connectie op poort 8514 van de pc, een vrije poort. Alles gaat prima, enkel als de risc computer aan en uit wordt gezet (waardoor hij dus de connectie die hij open heeft met de pc, niet juist afsluit) moet ik 2 min wachten. Met de sniffer zie ik dus wel dat de risc computer connectie terug wil openen naar de pc op poort 8514, maar hij krijgt een RST pakket terug gedurende 2 min.
In mijn risc computer kan ik wel dit instellen:
IRTR (Initial retry Time register) en RCR(Retry count register) maar dit zijn de timers voor re-transmissie van TCP, dus een error.
Nu de laatste tijd heb ik niet zo veel meer gelet op de fout, maar sinds we .NET2.0 gebruiken voor onze programmatie aan pc zeide lijkt het verholpen of toch allesinds beter...
Op het moment is het weer heel druk hier op het werk, dus als ik weer eens dit probleem zie en tijd heb zal ik eens een juiste sequence en sniffer log posten.

Bedankt Luc@s ;)