Probleme avec tcp_info

Version imprimable

21/04/2009, 01h24
Martin.D

Probleme avec tcp_info

Bonjour,

je réalise un sniffer avec pcap (tcpdump) sous linux et j'aimerais utiliser la structure tcp_info pour affiner mon filtre (par exemple : si le mss est spécifié).

Le probleme est que je ne comprend rien à cette structure qui n'est ni commentée ni expliquée nulle part (<netinet/tcp.h>). Comment savoir quelles options sont utilisées ?

Merci d'avance :)
21/04/2009, 09h33
nicolas.sitbon

http://linuxgazette.net/136/pfeiffer.html
Cordialement.

J'avais déjà vu cette page mais cela ne m'avais pas aidé.

Je vous explique rapidement plus en détails mon problème.

J'utilise pcap pour récupérer des paquets sur lesquels je veux avoir certaines informations (valeur du MSS lors du handshake en l'occurrence).

Pour cela je fais :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 const struct etherhdr*etherhdr; const struct ip* iphdr; const struct tcphdr* tcphdr; const struct tcp_info* tcpinfo; int etherhdr_size = sizeof(struct etherhdr); int iphdr_size = sizeof(struct ip); int tcphdr_size = sizeof(struct tcphdr); int tcpinfo_size = sizeof(struct tcp_info); etherhdr = (struct etherhdr *) packet; iphdr = (struct ip *) (packet + etherhdr_size); tcphdr = (struct tcphdr *) (packet + etherhdr_size + iphdr_size); tcpinfo = (struct tcp_info *) (packet + etherhdr_size + iphdr_size + tcphdr_size);
Lorsque j'affiche des informations sur le header TCP ou IP j'ai des informations correctes mais lorsque je fais un
Code:

1 2 printf("Send MSS = %u & Receive MSS = %u & Advertised MSS = %u\n", tcpinfo->tcpi_snd_mss, tcpinfo->tcpi_rcv_mss, tcpinfo->tcpi_advmss);
J'ai des valeurs bizzaroides comme 4154236971 pour le MSS send alors que wireshark m'indique des valeurs cohérentes, 1460, 1448, ...

J'ai également fais un ntohs sur ces valeurs mais elles ne semblent pas plus cohérentes (259, 11176, ...).

J'espère que c'est clair :)

Merci

21/04/2009, 14h21
nicolas.sitbon

Qu'est ce qui te fait penser que tu peux faire ça:

Code:

tcpinfo = (struct tcp_info *) (packet + etherhdr_size + iphdr_size + tcphdr_size);

J'ai l'impression que tu n'as pas vraiment lu le lien que j'ai donné.
21/04/2009, 15h22
Martin.D
Re,
Code:

1 2 tcpinfo = (struct tcp_info *) (packet + etherhdr_size + iphdr_size + tcphdr_size);
Semblait couler de source vu que cela vient après le header TCP (qui ne contient pas ces infos).

J'ai lu plus en détails l'article et ca ne m'aide pas vraiment. Il explique une méthode pour récupérer des informations sur une connexion TCP en créant une socket. Mais moi dans mon sniffer je n'ai accès à aucune socket (utilise les fonctionnalités de pcap) et je risque d'avoir plusieurs centaines de connexions TCP simultanées, entrantes ou sortantes ...

Puis il indique un fichier (tcp.c) ou on peut trouver des explications sur comment la structure est remplie mais je n'ai pas ce fichier sur ma distri (Ubuntu 8.04).

Ou alors j'ai raté qqchose dans l'article :)

Donc que ce soit en utilisant cette structure tcp_info ou pas, comment puis avoir accès aux informations contenues dans les options des paquets TCP (à part chercher pendant longtemps pour créer ma propre structure ...) ?

Merci d'avance :)
21/04/2009, 16h53
nicolas.sitbon

Citation:

Envoyé par Martin.D

Semblait couler de source vu que cela vient après le header TCP (qui ne contient pas ces infos).

Ah bon? où as tu été péché cela? après le header TCP, il y a les datas.
21/04/2009, 17h23
Martin.D

Oui, je sais ! Mais comme la structure tcphdr de tcp.h ne comptait que 20 octet pour une taille supérieure du header length (lors du hanshake spécialement), je me suis dis que pour capturer ces informations il suffisait d'utiliser la structure tcp_info juste après.

Car si on met la structure de 20 octet du TCP header, il reste certains bits qui ne doivent pas être des données mais bien partie de l'header TCP ...

As tu une idée pour récupérer ces informations stp ?
21/04/2009, 18h50
nicolas.sitbon

Dans ce cas, le seul moyen que je vois est d'inspecter les segments pendant le three way handshake et notamment durant le SYN et SYN ACK, le MSS est envoyé à ce moment là (mais ça n'est pas obligatoire).
21/04/2009, 19h01
Martin.D

Tout à fait d'accord !

Mais le soucis c'est que je n'arrive pas à accéder à ces informations vu qu'elles se trouvent dans les options de l'header TCP et que ces options ne sont pas prises en comptes par le header TCP de <netinet/tcp.h>.

Dés que le header length est supérieur à 20 c'est qu'il y a des options. Mon expression du filtre est de prendre juste les packets ayant le flag syn ou les flags syn et ack à 1. Tout ca marche très bien, le seul soucis c'est l'accès aux options ...

Donc comment récupérer ces informations ??

(merci pour ces réponses rapides en passant)
21/04/2009, 22h05
nicolas.sitbon

Comment les récupérer? en les analysant!
voici la procédure:
vérifier le champ Data offset, il doit avoir la valeur 5 minimum, s'il vaut plus, c'est qu'il y a des options.
Le format des options est le suivant:
un identifiant sur 1 octet qui vaut:
0 - End of options list
1 - No operation (NOP, Padding)
2 - Maximum segment size (see maximum segment size)
3 - Window scale (see window scaling for details)
4 - Selective Acknowledgement ok (see selective acknowledgments for details)
8 - Timestamp (see TCP Timestamps for details)

Les identifiants 2, 3 et 8 sont suivis d'un octet précisant la longueur de l'option en octet, suivi de l'information elle même.
Exemple en hexa:
020405B4 => 02 nous dit qu'il s'agit du MSS, 04 nous qu'il y a en tout 4 octets pour cette option donc 1 octet pour l'indentifiant, 1 autre pour la longueur et les 2 autres pour le MSS lui même, on a donc déjà lu 2 octets, il nous en reste 2 à lire, 05B4 soit 1460.

J'espère avoir réussi à me faire comprendre car ce n'est pas facile à expliquer.

J'y suis finalement arrivé ! Merci bien nicolas.sitbon

Je vais vous mettre mon code qui n'a rien d'optimiser ni de complet vu que je ne traite pas toute les options, mais c'est une bonne base.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
 
const struct etherhdr* etherhdr;
const struct ip* iphdr;
const struct tcphdr* tcphdr;
 
int etherhdr_size = sizeof(struct etherhdr);
int iphdr_size = sizeof(struct ip);
int tcphdr_size = sizeof(struct tcphdr);
 
etherhdr = (struct etherhdr *) packet;	
iphdr = (struct ip *) (packet + etherhdr_size);
tcphdr = (struct tcphdr *) (packet + etherhdr_size + iphdr_size);
 
if (tcphdr->doff  > 5) {
  const u_char* tcpOptions = packet + etherhdr_size + iphdr_size + 20;
  char kind[4];
  sprintf(kind, "%3d", *tcpOptions);
  int optType = atoi(kind);
 
  while (optType != 0) {
    if (optType != 2) {
      switch (optType) {		
        case 1 : tcpOptions++;	break;
        // Autres options à gérer pour être complet
      }
    }
    else {
      tcpOptions += 2;
      char mss_hexa[5];
      sprintf(mss_hexa, "%2x%2x", *tcpOptions, *(tcpOptions + 1));
      int mss = hex2Dec(mss_hexa);
      break;
    }
    sprintf(kind, "%3d", *tcpOptions);
    optType = atoi(kind);
  }
}

Ce n'est pas commenté mais ca me semble assez explicite. J'ai pas trouvé d'autres moyens pour les conversions u_char, char, hex, dec :s

Résolu :)

22/04/2009, 16h02
nicolas.sitbon

Sans parler des problèmes de sécurité inhérents à ton code, ton algo n'est pas bon, exemple :

Code:

0402020405B400

Ici j'ai mis le SACK en premier et le mss en second et ton va prendre le 02 qui indique la longueur de l'option sack, pour l'identifiant de MSS.
De plus le MSS est uint32_t, donc il peut varier de 1 à 4 octets, d'où l'importance de lire la longueur contrairement à ce que tu fais où tu présumes celle ci à être toujours 2.
23/04/2009, 11h59
Martin.D

Ok, pour la longueur j'avais oublié ce détails.

Pour l'autre point j'en étais bien conscient ! J'ai ici mis un premier jet de code fonctionnel ! Juste pour donner l'idée générale.

Sais tu si toutes les options listées ici sont susceptibles d'apparaitres lors du handshake ?

Merci pour ces conseils :)
23/04/2009, 17h00
Martin.D

Après quelque recherche concernant l'option MSS, la taille de cette option semble fixée à 4 octets et donc 2 pour la valeur du MSS. Je suppose que cette façon de faire permet de supporter l'évolution future des MTU. Mais avec 2 octets on arrive déjà à 65536 octets ...ce qui est suffisant normalement sauf si utilisation de jumbogram.