Je suis en train de programmer un module pour le noyau qui interfère sur la stack IPv6.
Pour ça, j'ai placé un hook dans la fonction "ip6_output2" du fichier ip6_output.c et je ne m'intéresse qu'à certain paquets multicast.
Je veux rajouter une extension dans l'entête IPv6 en utilisant l'option "hop-by-hop".
J'ai réussit à le faire mais je ne suis capable de rajouter que 8 octets.
Pour faire ça, je fais un "skb_push" de 8 octets sur le "sk_buff" pour décaler l'entête IPv6 (copie dans un tmp et recopie au nouvel emplacement). Puis je place la structure "ipv6_hopopt_hdr" juste après cette l'entête IPv6 en recopiant "nexthdr" d'origine dans son champs "nexthdr" et en mettant ce champs "nexthdr" de l'entête IPv6 à "NEXTHDR_HOP".
En suite, je créer une structure au format TLV :
struct ipv6_TLV_struct {
__u8 type;
__u8 length;
__u16 x1;
__u16 y1;
} __attribute__ ((packed));
J'ai mis le champs "hdrlen" de la structure "ipv6_hopopt_hdr" à 0 et le champs "length" de la structure "ipv6_TLV_struct " à 4.
Dans ce cas, ça fonctionne.
Mais j'aimerai ajouter plus de données dans mon extension :
struct ipv6_TLV_struct {
__u8 type;
__u8 length;
__u16 x1;
__u16 y1;
__u16 x2;
__u16 y2;
__u32 reserved;
} __attribute__ ((packed));
Je rajoute du padding à la fin, pour avoir une taille totale ("ipv6_hopopt_hdr" + "ipv6_TLV_struct") multiple de 64 bits, soit ici 2.
J'ai cru comprendre que le champs "hdrlen" de la structure "ipv6_hopopt_hdr" est égale à la taille de l'extension / 64bit - 1, soit ici 1.
Quand je fais ça, je me retrouve avec un "skb_under_panic" qui intervient dans la stack IPv6, dans mon code tout c'est bien passé.
Je ne parle pas ici de tout les tests nécessaires et la gestion des erreurs (vérifier qu'il y a suffisamment de place dans le sk_buff pour rajouter l'extension, ...).
Pouvez vous m'aidez ? (Je peux fournir le code)
Merci.
# EH
Posté par peck (site web personnel) . Évalué à 3.
Ce qui voudrait dire qu'il faut que tu spécifie 2 headers plutot qu'un plus gros.
Mais je suis loin d'etre un spécialiste, et si ca se trouve le problème vient seulement de ton code :)
[^] # Re: EH
Posté par Doude . Évalué à 1.
Par contre, je suis d'accord avec toi, je pense que le problème viens de mon code mais là je ne sais plus où chercher.
En fait, j'arrive à étendre mon extension à 10 octets mais après ça, c'est le gros plantage.
J'ai l'impression que mon problème viens du "skb_push", dès que veux agrandir le buffer de plus de 10 octets, c'est mort. Pourtant, le kernel panic ne survient pas à mon appel de la fonction "skb_push" mais plus loin dans la stack IPv6.
Je vérifie bien que la place est suffisante en entête du buffer, et pour l'instant je me retrouve toujours dans le cas où c'est suffisant :
if (skb_headroom(skb) < max_headroom || skb_shared(skb) || (skb_cloned(skb) && !skb_clone_writable(skb, 0)))
{
DEBUG(DEBUG_LEVEL0, "not enougth space(%d) or shared or not writable clone sk_buff\n", max_headroom);
struct sk_buff *new_skb = skb_realloc_headroom(skb, max_headroom);
if (!new_skb)
{
kfree_skb(skb);
return -ENOBUFS;
}
if (skb->sk)
skb_set_owner_w(new_skb, skb->sk);
kfree_skb(skb);
skb = new_skb;
}
# Transport header pointer
Posté par Doude . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.