Bonjour, je suis en train de programmer (enfin j'essaie) une petite pile
tcp/ip pour une brouette hors d'âge...
Config
Brouette <- SLIP / RS232 -> Linux (avec slattach et ifconfig)
Lorsque je tente un ping visant la brouette, celle ci reçoit bien les
messages par contre toute réponse de sa part et ignorée par la source (en
clair, 100% de paquets perdus)
Habituellement, quand les informations sont erronées tcpdump le dit. J'en
déduis donc que j'ai réussi à produire un datagramme IP contenant un
message ICMP correct.
Alors, d'où peut bien provenir le problème ?
Je sais que c'est de l'hexa mais bon... J'ai pas mieux !
Je sais que c'est de l'hexa mais bon... J'ai pas mieux !
Un petit coup de tethereal -V ce serait déjà plus clair et moins fatigant :-)
Jacques.
Merci pour le tuyau c'est vrai que c'est mieux que tcpdump... Et le diagnostic est clair : mes checksum IP et ICMP sont pourris
Rhâa j'ai trouvé plusieurs routines qui font ça à droite à gauche mais je ne comprends rien à leur fonctionnement.
Où dégoter une explication de l'algo utilisé ?
Frame 39 (84 bytes on wire, 84 bytes captured) Arrival Time: Oct 15, 2004 18:30:03.017978000 Time delta from previous packet: 0.179954000 seconds Time since reference or first frame: 9.269623000 seconds Frame Number: 39 Packet Length: 84 bytes Capture Length: 84 bytes Raw packet data No link information available Internet Protocol, Src Addr: 192.168.2.1 (192.168.2.1), Dst Addr: 192.168.2.254 (192.168.2.254) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 84 Identification: 0x0012 (18) Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: ICMP (0x01) Header checksum: 0x47f4 (incorrect, should be 0xf447) Source: 192.168.2.1 (192.168.2.1) Destination: 192.168.2.254 (192.168.2.254) Internet Control Message Protocol Type: 0 (Echo (ping) reply) Code: 0 Checksum: 0xe678 (incorrect, should be 0xe878) Identifier: 0x3a20 Sequence number: 0x005e Data (56 bytes)
Jacques Caron
Salut,
On 15 Oct 2004 16:25:51 GMT, Zouplaz wrote:
Rhâa j'ai trouvé plusieurs routines qui font ça à droite à gauche mais je ne comprends rien à leur fonctionnement.
Où dégoter une explication de l'algo utilisé ?
Dans la RFC qui va bien. RFC 791 pour IP:
Header Checksum: 16 bits
A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed.
The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
This is a simple to compute checksum and experimental evidence indicates it is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience.
RFC 792 pour ICMP:
Checksum
The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP Type. For computing the checksum , the checksum field should be zero. If the total length is odd, the received data is padded with one octet of zeros for computing the checksum. This checksum may be replaced in the future.
Tu peux aussi regarder le source de ping:
/* * in_cksum -- * Checksum routine for Internet Protocol family headers (C Version) */ u_short in_cksum(addr, len) u_short *addr; int len; { int nleft, sum; u_short *w; union { u_short us; u_char uc[2]; } last; u_short answer;
nleft = len; sum = 0; w = addr;
/* * Our algorithm is simple, using a 32 bit accumulator (sum), we add * sequential 16 bit words to it, and at the end, fold back all the * carry bits from the top 16 bits into the lower 16 bits. */ while (nleft > 1) { sum += *w++; nleft -= 2; }
/* mop up an odd byte, if necessary */ if (nleft == 1) { last.uc[0] = *(u_char *)w; last.uc[1] = 0; sum += last.us; }
/* add back carry outs from top 16 bits to low 16 bits */ sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */ sum += (sum >> 16); /* add carry */ answer = ~sum; /* truncate to 16 bits */ return(answer); }
Je me souviens que la dernière fois que j'avais regardé il m'avait semblé que leur machin était tout buggé à cause de problèmes d'endianness, mais visiblement ça retombe sur ses pieds quoi qu'il arrive!
Header checksum: 0x47f4 (incorrect, should be 0xf447)
Là tu as a priori juste un problème d'endianness (inversion des deux octets).
Checksum: 0xe678 (incorrect, should be 0xe878)
Là je sais pas trop, sauf peut-être un problème d'endianness en cours de route qui affecte la retenue?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Salut,
On 15 Oct 2004 16:25:51 GMT, Zouplaz <pouet@pouet.com> wrote:
Rhâa j'ai trouvé plusieurs routines qui font ça à droite à gauche mais je
ne comprends rien à leur fonctionnement.
Où dégoter une explication de l'algo utilisé ?
Dans la RFC qui va bien. RFC 791 pour IP:
Header Checksum: 16 bits
A checksum on the header only. Since some header fields change
(e.g., time to live), this is recomputed and verified at each point
that the internet header is processed.
The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header. For purposes of
computing the checksum, the value of the checksum field is zero.
This is a simple to compute checksum and experimental evidence
indicates it is adequate, but it is provisional and may be replaced
by a CRC procedure, depending on further experience.
RFC 792 pour ICMP:
Checksum
The checksum is the 16-bit ones's complement of the one's
complement sum of the ICMP message starting with the ICMP Type.
For computing the checksum , the checksum field should be zero.
If the total length is odd, the received data is padded with one
octet of zeros for computing the checksum. This checksum may be
replaced in the future.
Tu peux aussi regarder le source de ping:
/*
* in_cksum --
* Checksum routine for Internet Protocol family headers (C Version)
*/
u_short
in_cksum(addr, len)
u_short *addr;
int len;
{
int nleft, sum;
u_short *w;
union {
u_short us;
u_char uc[2];
} last;
u_short answer;
nleft = len;
sum = 0;
w = addr;
/*
* Our algorithm is simple, using a 32 bit accumulator (sum), we add
* sequential 16 bit words to it, and at the end, fold back all the
* carry bits from the top 16 bits into the lower 16 bits.
*/
while (nleft > 1) {
sum += *w++;
nleft -= 2;
}
/* mop up an odd byte, if necessary */
if (nleft == 1) {
last.uc[0] = *(u_char *)w;
last.uc[1] = 0;
sum += last.us;
}
/* add back carry outs from top 16 bits to low 16 bits */
sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */
sum += (sum >> 16); /* add carry */
answer = ~sum; /* truncate to 16 bits */
return(answer);
}
Je me souviens que la dernière fois que j'avais regardé il m'avait semblé
que leur machin était tout buggé à cause de problèmes d'endianness, mais
visiblement ça retombe sur ses pieds quoi qu'il arrive!
Header checksum: 0x47f4 (incorrect, should be 0xf447)
Là tu as a priori juste un problème d'endianness (inversion des deux
octets).
Checksum: 0xe678 (incorrect, should be 0xe878)
Là je sais pas trop, sauf peut-être un problème d'endianness en cours de
route qui affecte la retenue?
Jacques.
--
Interactive Media Factory
Création, développement et hébergement
de services interactifs: SMS, SMS+, Audiotel...
http://www.imfeurope.com/
Rhâa j'ai trouvé plusieurs routines qui font ça à droite à gauche mais je ne comprends rien à leur fonctionnement.
Où dégoter une explication de l'algo utilisé ?
Dans la RFC qui va bien. RFC 791 pour IP:
Header Checksum: 16 bits
A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed.
The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero.
This is a simple to compute checksum and experimental evidence indicates it is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience.
RFC 792 pour ICMP:
Checksum
The checksum is the 16-bit ones's complement of the one's complement sum of the ICMP message starting with the ICMP Type. For computing the checksum , the checksum field should be zero. If the total length is odd, the received data is padded with one octet of zeros for computing the checksum. This checksum may be replaced in the future.
Tu peux aussi regarder le source de ping:
/* * in_cksum -- * Checksum routine for Internet Protocol family headers (C Version) */ u_short in_cksum(addr, len) u_short *addr; int len; { int nleft, sum; u_short *w; union { u_short us; u_char uc[2]; } last; u_short answer;
nleft = len; sum = 0; w = addr;
/* * Our algorithm is simple, using a 32 bit accumulator (sum), we add * sequential 16 bit words to it, and at the end, fold back all the * carry bits from the top 16 bits into the lower 16 bits. */ while (nleft > 1) { sum += *w++; nleft -= 2; }
/* mop up an odd byte, if necessary */ if (nleft == 1) { last.uc[0] = *(u_char *)w; last.uc[1] = 0; sum += last.us; }
/* add back carry outs from top 16 bits to low 16 bits */ sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */ sum += (sum >> 16); /* add carry */ answer = ~sum; /* truncate to 16 bits */ return(answer); }
Je me souviens que la dernière fois que j'avais regardé il m'avait semblé que leur machin était tout buggé à cause de problèmes d'endianness, mais visiblement ça retombe sur ses pieds quoi qu'il arrive!
Header checksum: 0x47f4 (incorrect, should be 0xf447)
Là tu as a priori juste un problème d'endianness (inversion des deux octets).
Checksum: 0xe678 (incorrect, should be 0xe878)
Là je sais pas trop, sauf peut-être un problème d'endianness en cours de route qui affecte la retenue?
Jacques. -- Interactive Media Factory Création, développement et hébergement de services interactifs: SMS, SMS+, Audiotel... http://www.imfeurope.com/
Zouplaz
Jacques Caron - :
Tu peux aussi regarder le source de ping:
Merci pour ces infos, dans me petite collection de routines celle là je l'ai pas ;-) Je vais essayer
Je me souviens que la dernière fois que j'avais regardé il m'avait semblé que leur machin était tout buggé à cause de problèmes d'endianness, mais visiblement ça retombe sur ses pieds quoi qu'il arrive!
Header checksum: 0x47f4 (incorrect, should be 0xf447)
J'avais pas vu, quel idiot !
Là tu as a priori juste un problème d'endianness (inversion des deux octets).
Checksum: 0xe678 (incorrect, should be 0xe878)
Là je sais pas trop, sauf peut-être un problème d'endianness en cours de route qui affecte la retenue?
Je vais tout vérifier à nouveau... Je ne sais pas si c'est un indice mais c'est vrai que les deux résultats sont tout de même assez proches (e6 au lieu de e8)
En tout cas merci encore
Jacques Caron - jc@imfeurope.com :
Tu peux aussi regarder le source de ping:
Merci pour ces infos, dans me petite collection de routines celle là je
l'ai pas ;-) Je vais essayer
Je me souviens que la dernière fois que j'avais regardé il m'avait
semblé que leur machin était tout buggé à cause de problèmes
d'endianness, mais visiblement ça retombe sur ses pieds quoi qu'il
arrive!
Header checksum: 0x47f4 (incorrect, should be 0xf447)
J'avais pas vu, quel idiot !
Là tu as a priori juste un problème d'endianness (inversion des deux
octets).
Checksum: 0xe678 (incorrect, should be 0xe878)
Là je sais pas trop, sauf peut-être un problème d'endianness en cours
de route qui affecte la retenue?
Je vais tout vérifier à nouveau... Je ne sais pas si c'est un indice mais
c'est vrai que les deux résultats sont tout de même assez proches (e6 au
lieu de e8)
Merci pour ces infos, dans me petite collection de routines celle là je l'ai pas ;-) Je vais essayer
Je me souviens que la dernière fois que j'avais regardé il m'avait semblé que leur machin était tout buggé à cause de problèmes d'endianness, mais visiblement ça retombe sur ses pieds quoi qu'il arrive!
Header checksum: 0x47f4 (incorrect, should be 0xf447)
J'avais pas vu, quel idiot !
Là tu as a priori juste un problème d'endianness (inversion des deux octets).
Checksum: 0xe678 (incorrect, should be 0xe878)
Là je sais pas trop, sauf peut-être un problème d'endianness en cours de route qui affecte la retenue?
Je vais tout vérifier à nouveau... Je ne sais pas si c'est un indice mais c'est vrai que les deux résultats sont tout de même assez proches (e6 au lieu de e8)
