Misschien he je iets aan deze pagina, en de links die daarbij
staan.
http://nl.wikipedia.org/wiki/Internet_Control_Message_Protocol

Koekie, zelf ga ik in zo'n geval op zoek naar sources en
kijk hoe anderen e.e.a. hebben geimplementeerd.

Misschien heb je hier wat aan. lwIP is een open source
project van een compacte TCP/IP stack vooral bedoeld voor
embedded systemen (met kleine CPU's). De home page is hier:
http://savannah.nongnu.org/projects/lwip/.

Als je lwip-1.1.1.zip ophaalt (slechts 347K :), uitpakt,
naar subdir src/core/ gaat, dan vind je bovenaan de file
"inet.c" een routine die aangekondigd wordt met ongeveer het
volgende commentaar:

/* This is a reference implementation of the checksum
algorithm, with the aim of being simple, correct and fully
portable. Checksumming is the first thing you would want to
optimize for your platform. */

Er volgen enkele routines die op verschillende manieren zijn
geoptimaliseerd (door 'echte' C programmeurs dus helaas
niet op leesbaarheid).

Erik van Straten,
Ik was eigenlijk al bezig de source codes te vergelijken en overeen
komsten te vinden.Het probleem alleen is echter dat iedere keer op een
andere manier word gedeclareerd.Om een voorbeeld te geven op http://www.netfor2.com/tcpsum.htm zie je de source dest protocol en
length ook terug komen in de source code.Maar bv bij http://netweb.usc.edu/csiat/dos/brkill.c is het gewoon een functie en
komen geen enkele pointers van het iphdr packet in voor.

Wat ze alleen alle bij overeen hebben is dat de functie zelf het eerste een
pointer bevat en erna een integer net zoals bij de source in lwip.En de
while en if functie.En verder nog wat losse declaraties.En hier zit juist het
probleem in.Want in de memo van de rfc 1071 staat "An efficient
checksum implementation is critical to good performance.Maar waar
ga je vanuit als de checksum zelf al niet in juiste c syntax geschreven is.

Een snelle blik op die laatste, onderaan functie init_pkt staat:

pkt.tcphead.th_sum =
tcp_cksum ((u_short *) ADRES_VAN pseudo, 32);

(Ik gebruik ADRES_VAN i.p.v. de ampersand omdat die in dit
forum waarschijnlijk wegvalt). Die pseudo is een
struct met de volgende members, en deze wordt net voor
bovenstaande aanroep gevuld met gegevens uit het pakket:

u_long saddr;
u_long daddr;
u_char zero;
u_char proto;
u_short len;
struct tcphdr faketcp;

dus daar zitten dus wel degelijk de relevante gegevens uit
de IP header in. N.B. laat je niet verwarren door de regel
een stukje hoger:

pkt.iphdr.ip_sum =
htons (tcp_cksum ((u_short *) ADRES_VAN pkt.iphdr, 20));

De functienaam tcp_cksum is hier misleidend, want hier wordt
de checksum van de IP -header uitgerekend (zelfde
algoritme).

RFC1071 is uit 1988. Als jij met een moderne Intel/AMD CPU
werkt en geen extreem slechte C-code schrijft zou ik me daar
maar geen zorgen over maken. Wel wordt de boel extreem traag
als je velden weg gaat laten bij de checksum berekening
(alleen pakketten met toevallig een goede checksum komen dan
nog door).

Ten slotte nog een link naar wat oudere pages geschreven
door Vijay Mukhi:
http://www.vijaymukhi.com/vmis/roll.htm; onderaan
http://www.vijaymukhi.com/vmis/ip.htm vind je nog
een checksum routine.

Erik van Straten,
Maar neem nou het geval dat de checksum code wel goed is
geschreven.Zou dan gelijk tcpdump de checksum weer gegeven worden
of mis ik dan nog een stap als het mss gedeelte want het option gedeelte
hoord hier toch ook nog bij met bv inhoud van "SACK PERMITTED NOP
NOP".Of staat het option veld los van het een syn request aan vraag van bv
GET / HTTP/1.1.

Ps. Overigens goeie documentatie van Viay Mukhi.Het enige dat ik niet
begrijp is dat die bij d checksum.c gedeelte onder ip er nog een keer een
extra loop bij hangt bij de meeste source codes wordt direct verwezen naar
chksum = checksum ( a, sizeof( a ) );

Heb je trouwens die u_char zero en struct tcphdr faketcp; nodig om de
checksum te maken want op http://www.netfor2.com/tcpsum.htm
staat je eigenlijk alleen ip source , ip dest , protocol en tcp length nodigh
hebt.

want dan kan het bv toch ook iets zijn als :

Erik van straten,
Het is trouwens gelukt met die checksum was wel wat stoeien met die
variablen en wat structs maar uit eindelijk is dit em geworden:

Status: starting three way handshake
checksum = 0x5af0
Sending SYN packet to [ 127.0.0.2 ]

Die tcp checksum geeft die nu ook in weer in ethereal onder windows en
en linux.Zou alleen nog veel werk zijn denk ik om die tcp options er bij te
krijgen en de "maximum segment size" ftp://ftp.rfc-editor.org/in-notes/rfc2018.txt werkende te krijgen.Maar thx in iedergeval voor de
hulp van de checksum :D

Okay Koekie!

Op je twee posts van vrijdag heb ik trouwens niet gereageerd
omdat (A) het discutabel is of deze discussie wel op dit
forum thuishoort en (B) ik er zelf naar m'n zin teveel tijd
in had moeten stoppen en (C), last but not least, dit zaken
zijn die elke programmeur (zeker met zoveel verschillende
voorbeeldcode op Internet) zelf op moet kunnen lossen. Goed
dat je er zelf uit gekomen bent, daar leer je echt het
meeste van!

Erik van straten,
Het was ook een afweging die ik had gemaakt voor het plaatsen van die
twee topics.Ik weet dat het niet nog al gevoelig ligt op security.nl en zou
probreren in het vervolg niet meer over te gaan op het programeren.Aan de
andere kant dee ik het ook om de reden om een keer andere te laten zien
die zich zich wel zouden willen verder ontwikkelingen maar blijven hangen
in applicaties en manuals waar ze eigenlijk niks aan hebben.En zo
misschien op deze manier een beter beeld krijgen hoe nou security
experts bezig zijn als het gaat om applicaties en beveiliging etc etc.

Persoonlijk voor mij zijn er namelijk maar twee/drie handleidingen rfc's de
c syntax en de assembly syntax en probeer deze kennis steeds verder uit
te brijden.Ik heb nog het geluk dat ik ongeveer weet waar moet zoeken en
het staps gewijs gaat maar langzaam verbetering in komt maar voor veel
die niet weten waar ze moeten beginnen of weten hoe ze zich zelf een
patroon kunnne aanleren waardoor het leren makkelijker gaat is het een
stuk lastiger tot zelfs onmogelijk.

Wat ik jammer vind is op scholen worden rfc's en het programeren van
netwerk applicaties van c op rfc's weinig tot geen aandacht besteed aan
rfc's die juist nou zo belangrijk zijn voor security en het dan ook jammer
vind dat website als security.nl hier zelde tot weinig aandacht aan besteed
wat ook een bron van informatie zou kunnen worden voor
systembeheerders/netwerk beheerders en gewone mensen die eigenlijk
wel meer zouden willen over hoe internet werkt.

koekie