Misschien wordt je wat wijzer met Digital Home NetAnalyzer DL

http://www.qualitylogic.com/genoa_test_tools/digital_home/dh_netanalyzer_dl.html

Jah daar lijkt het op "Save the analysis outputs in a unique compressed
file that can be loaded at a later time" zou wel data zijn waar ik na zoek.Thx!

Een ACK packet bevat geen data. Het is een ACKnowledge dat het packetje (waar wel data in zat) met sequence nummer 285 is aangekomen.

Wil je echt alles weten over TCP/IP investeer dan in het boek "TCP/IP Illustrated Volume 1" van Stevens. Misschien niet het beste boek om het uit te leren maar van onschatbare waarde als naslagwerk.

Dat ben ik dus nu aan het uitzoeken ben wel zo ver dat waneer je bv
google.nl intyped die eerst een syn stuurd google een syn+ack terug
stuurd en dan die dan weer een ack terug stuurd waarna get http / 1.1
wordt aangevraagd.Maar kan niet de info vinden of nou alleen TCP paket
word verstuurd met het sequence nummer 285 of dat er nog meer
informatie in het paket zit.Zoals bijvoorbeeld bij syn het geval is die de
aanvraag voor ack doet.

Maar denk wel dat ik het boek ga bestellen van TCP/IP illustrated volume 1
van stevens als daar de informatie in staat die precies weer geeft wat er
gebeurd als een three way handshake plaats is het wel de moeite waard
om het boek te kopen.Ik heb al het boek TCP/IP illustrated volume 2 maar
dat is gericht op netwerk applicaties met c wat overigens enorm leerzaam
is.

Volume 3 gaat overigens over zaken als TLS en wat losse protocollen.. Ze staan alledrie gebroederlijk naast elkaar in m'n, inmiddels uitpuilende, boekenkast ;)

Volume 1 is een absolute aanrader. Zeer gedetailleerd.

Een SYN bevat ook geen informatie, geen data althans (len=0).

Voorbeeld?
Opzetten connectie van client naar server:
C --- SYN (seq=0)(len=0)-------------------+ S
C +-- SYN (seq=0)/ACK (ack=1)(len=0) --- S
C -----ACK (seq=1)(len=0)--------------------+ S
Nu is er een echte TCP connectie en kan er data verstuurd worden...

Client stuurt een opdracht naar de server:
C --DATA(6 bytes)(seq=1)(len=6)------+S
C +-------------------ACK(ack=7)(len=0)---S

Server stuurt een antwoord terug:
C +--DATA(10 bytes)(seq=1)(len=10)---S
C -----------------ACK(seq=11)(len=0)---+S

Je kunt aan de len= zien hoeveel "data" een pakketje bevat. Het sequence nummer van de ACK (ack=) is het sequencenummer (seq=) + de lengte (len=). Hierdoor ziet de verzendende partij dat het pakketje is aangekomen (de ACK) en hoeveel bytes (sequencenummer + length) er ontvangen zijn.

Wat je echter in de praktijk zult zien is dat er en data verstuurd word en tegelijk het vorige ontvangen pakket ge'ACK'ed wordt. Dat is wat efficienter. Wat ook nog mogelijk is is een zogenaamde delayed ACK. Er wordt dan pas een ACK verstuurd nadat er meerdere pakketten zijn ontvangen. Die ene ACK bevestigd dan het ontvangen van meerdere pakketjes. Ook dat wordt gedaan om de efficiëntie te verhogen.

Dus als ik het goed begrijp dat bij de three way handshake er geen data in
het paket zit vanwege de len steeds 0 aan geeft? Want wat die weer geeft
met ethreal is als je na google surfed is:

127.0.0.1 66.149.85.99 TCP 1374 HTTP [SYN] seq=0 len=0
66.149.85.99 127.0.0.1 TCP HTTP 1374 [SYN,ACK] seq=0 ack=1 len=0
120.0.0.1 66.149.85.99 TCP 1374 HTTP [ACK] seq=1 ack=1

Op vallend is dat de window met [syn,ack] bv win=8290 weer geeft en verdubbeld is bij [ACK] win=64240.Klopt het dan dat win(window) aangeeft hoevel data in len kan ?

wireshark is het tegenwoordig.

Tijdens de handshake wordt er nooit data verzonden. De connectie is er immers nog niet.. De "connectie" is er pas na de three-way handshake (SYN-SYN/ACK-ACK).

TCP window size
The TCP receive window size is the amount of received data (in bytes) that can be buffered during a connection. The sending host can send only that amount of data before it must wait for an acknowledgment and window update from the receiving host.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

De maximale hoeveelheid data in een pakketje is afhankelijk van de [url=http://en.wikipedia.org/wiki/MTU_%28networking%29]MTU[/url].

De RFC's van IP, TCP en HTTP zijn naar mijn mening ook best
goed leesbare documenten over hoe het zou moeten werken. Ze
zijn het makkeijkst te vinden door te googlen op
bijvoorbeeld: rfc tcp

Als je de RFC nummers weet kan je ze ook makkeijk bij het
ietf vinden op http://www.ietf.org/rfc.html

SirDice,
Thx! goeie ilustratie trouwens van het TCP model maar wat ik me nou
eignelijk afvraag is als ik nou een SYN zou sturen na een server en de
server replyed met SYN-ACK deze verwacht dus een ACK van mij maar als
ik nou een SYN terug zou sturen zou die dan weer een SYN-ACK terug sturen of gaat die server dan trippen omdat die wacht op een ACK.

Nee, die server gaat niet trippen, althans een goede server niet, bedenk wat er gebeurd als meerdere clients een connectie maken naar de server. Overigens is iemand anders ook al op dat idee gekomen. Kijk eens naar NMap en dan met name de SYN half open scan, beter bekent als de stealth scan.

Waarom doe je dat? Na een three-way handshake wordt er een connectie gelogd. Door de handshake niet helemaal af te ronden wordt de connectie niet gelogd. Nmap doet dat door:

N ----SYN--------+ S
N +--SYN/ACK--- S
N ----RST--------+ S

Er is nu geen connectie die gelogd wordt! Als er een volledige three-way handshake geweest zou zijn wel. Waarom is dat interessant? Een open poort stuurt een SYN/ACK terug, een gesloten poort een RST, komt er helemaal niets terug dan zit er waarschijnlijk een firewall tusen. Hey, zo kun je een
poortscan uitvoeren :))

De RST, is niet noodzakelijk, maar wordt gestuurd om te voorkomen dat de server uit z'n resources zou lopen. Voor elke SYN die ontvangen wordt word er wat geheugen gereserveerd. Omdat er nooit een ACK op de SYN/ACK komt
treed er na een tijdje een time-out op. Dan wordt dat geheugen ook weer vrijgegeven. Door heel veel SYN's te sturen zou je een (slechte) server onderuit kunnen halen omdat'ie op een gegeven moment geen geheugen meer vrij heeft (een DoS dus!).

Maar dan kan je eigenlijk toch ook een anti scan programma er voor
geschrijven want neem nou het geval als iemand 65535 services
scant.Dan wordt dus voor 65535 services iedere keer een stukje een
geheugen vrijgemaakt waardoor je een patroon krijgt en ervan uit kan gaan
dat iemand een syn scan aan het uitvoeren is.Of je kan het detecteren
door dat die 65535 keer een time-out weer geeft of zie ik dat nou verkeerd.

Het is makkelijker om dat met een IDS te doen ;)

Met snort bijvoorbeeld:
http://www.snort.org/docs/snort_htmanuals/htmanual_260/node11.html#SECTION00317000000000000000

Thx voor de site trouwens is leuk om verder in te verdiepen en dingen te
testen.Ben nu bezig een syn aanvraag te programeren en kom steeds een
stukje verder.Maar blijft lastig want loop steeds tegen nieuwe problemen
op/aan.Zo geeft die met:

struct tcphdr hdr;
hdr.source=htons(sport);
hdr.source=htons(dport);
hdr.seq=0
hdr.ack_syn=0;
hdr.syn=1;

Een malformed packet weer onder ethereal.in de header van de andere
computer gaf die aan:

127.0.0.1 127.0.0.2 TCP 5959 > HTTP [Malformed packet]

Nu ben ik er nog niet echt achter waar nu het probleem zit omdat de
hdr.syn=1; wel is gedeclareerd.Maar nergens kan terug vinden in het
packet.Zo geeft bij een gewone syn aanvraag (Flags:0x0002 (syn) .... ..1.
syn:set) weer.Waneer ik nou de hdr.syn=1; verrander na hdr.syn=0x02; blijft
die in het packet weer geven bij flags: 0x04(don't fragment) terwijl de syn
wel is gedeclareerd.

Let wel.. Het sequence nummer in wireshark (ethereal) wordt standaard relatief weergegeven.. Dat is dus niet het echte sequence nummer.

Vergeet ook de checksum niet, wellicht geeft wireshark daarom aan dat het malformed is?

En in (raw) socket programmeren ben ik niet zo'n ster, je zou de source van bijv. NMap eens kunnen bekijken.. Die bevat vast een hoop interessante code. Of Volume 2 ;)

SirDice,
Heb het trouwens voor elkaar gekregen dat die alleen een syn
verstuurd.Alleen blijft die nog een malformed packet vermelden bij het
packetje.Een groot deel komt al overeen als ik http://www.google.nl in type.Zo
geeft ethereal weer:

127.0.0.1 127.0.0.2 TCP 5959 > http [syn] seq=0[malformed packet]

Transmission Control protocol
Source port : 5959(5959)
Destination port: http(80)
short segment.Segment/framgent does not contain a full tcp header might
be nmap or someone else deliberately sending unusual packets)
sequence number = 0 (relative sequence number)
header length = 28 bytes;
flags:0x0002(syn)
0 = COngestion window reduced (cwr): Not set
0 =ECN-EChO: Not set
0 = Urgent : Not set
0 = Acknowledgement: Not set
0 = push: Not set
0 = Reset: Not set
1 = syn: set
0 = fin: Not set

window size:320
checksum:0x80f3 [validation disabled]
[Malformed Packet: TCP]

Nou vraag ik me af of dit komt door de options die er niet bij staat waneer
ik nou bij de syn kijk van google nl staat er bij options.
options: 8(bytes)
maximum segment size:1460 bytes
nop
nop
SACK permitted

opvallend is namelijk dat bij de header van tcp.h in /usr/include/netinet/tcp.h nergens iets over options staat dan alleen check en urg_ptr.

SirDice,
Weet jij misschien hoe je de source van nmap kan bekijken? Want ben zo
ver gekomen nou dat de geen malformed packet meer weergeeft maar:

127.0.0.1 127.0.0.2 TCP 5959 --+ http [syn] seq=0 len=0

Het enige probleem is nu nog de options en de maximum segment size
en de checksum waar je overigens gelijk in had want deze staat nu nog op
checksum:0x000 wat een hele kluif zou worden denk ik dit werkende te krijgen.Weet jij trouwens of onder linux ook de options worden gebruikt als nop nop SACK permitted ? Dit geeft die namelijk onder windows met ethereal weer.

ps. Wat trouwens grappig is dat die nu geen melding meer weer geeft als
bij die vorige van:

short segment.Segment/framgent does not contain a full tcp header might
be nmap or someone else deliberately sending unusual packets

Downloaden http://insecure.org/nmap/download.html kopje
Source distribution.

Thx ! SirDice,
Die source codes zijn wel handig om te kijken of de code overeen komt en
alles goed is ingesteld.