Version imprimable
Bonsoir,
Ca fait quelques temps que je m'essaye au socket sous linux mais sans grand sucées ; j'aimerai tout simplement envoyer via socket RAW des requêtes arp .
Je me suis documenté sur le contenu du trame ARP/Ethernet et je pense avoir correctement assimilé la chose.
Le problème se situe dans la rédaction du code, j'aimerai savoir si vous connaissez un site ( en francais si possible ) qui explique comment réaliser un socket RAW de façon détaillé et commenté ?
Merci d'avance et bonne soirée
A ta place, et pour éviter un sacré paquet d'emm...., je passerais par libpcap pour émettre (et recevoir ! ;)) mes trames en raw.
Tu pourras émettre des trames raw en utilisant la fonction pcap_inject (sous Linux) et pcap_sendpacket (sous Windows). Ne me demande pas pourquoi les fonctions sont différentes sur les deux OS, je n'en sais rien, mais un coup de compilation conditionnelle règle très vite le souci.
Au pire, tu cherches un wrapper C++ vers cette librairie, par exemple libpcap++ (je ne l'ai pas testée par contre).
Si tu tiens absolument à passer par une programmation manuelle des raw sockets, alors direction le mode promiscuous et l'ouverture avec socket(AF_RAWETH,SOCK_RAWETH,0)... J'ai déjà testé, c'est loin d'être trivial à mettre en place et, en plus, tu as pas mal de soucis de compatibilité / portabilité avec ce genre de code. Or, c'est justement ce que va t'éviter l'utilisation de libpcap.
Merci bien, disons qu'avant d'utiliser libpcap j'aimerai comprendre les sockets fait "à la main" ;)
Je vais creuser ta piste, merci :)
Je dirais plutôt le contraire exactement, pour ma part, et j'ai pourtant "bouffé" pas mal de raw sockets... Utilises-les déjà au niveau applicatif (décodage des différents layers) avant de te mêler de la tripaille interne de l'OS pour les faire fonctionner ! :mouarf:Citation:
Envoyé par geek-59600
Aurais tu des lien à me conseiiler pour les sockets selon la méthode que tu m'a décrite ( AF_RAWETH) car j'en ai jamais entendu parler .
man socket... C'est pour ça que je te conseille de passer par libpcap.
Crois-moi sur parole : j'ai bouffé des raw sockets sur trois OS différents (dont Linux, Windows et un unix-like), et en mode bourrin. Ben au final, je ne suis pas prêt de retenter l'expérience en tapant directement dans les sockets BSD : c'est inutile, pas portable et les perfs sont moins bonnes qu'avec la libpcap.
Bon si tu le dis j'vais regarder de ce coté la y'a moyen de mettre la "dll" dans l'exe ou faut installer libcap a coté ?
Arf j'aurais préféré une solution qui m'es possible d'inclure au binaire :)
Je vais aller voir du coté des sock_raweth j'aime bien comprendre comment ca marche quitte à me prendre la tête :)
Question il y a t il moyen d'utiliser des sockets encore en plus bas niveau ? genre directement avec le driver du chip réseau ? ( curiosité quand tu nous tiens )
Heu... Les raw socket sous Windows, c'est encore pire que sous Linux, tu sais ? :mouarf: Plus sérieusement, WinPCAP (ou libPCAP sous Linux) s'installe très facilement, cf. Wireshark par exemple. Aucun problème avec ça, sans compter que ceux que ça intéresserait ont déjà les librairies en question installées, en général.
A titre personnel et en remarque : faudrait un peu arrêter (et tu n'es pas spécifiquement visé) avec les binaires monolithiques construits à grand coup de link statique... Ras-le-bol d'avoir des applications bouffeuses de RAM pour qu'un lambda s'évite 10 minutes de boulot sur un setup. Pour ma part, ce genre d'appli, c'est poubelle direct désormais.
Quant à taper dans le contrôleur Ethernet... D'une part, ce n'est possible qu'avec un driver (quel que soit l'OS), et d'autre part, il te faudrait alors la datasheet du contrôleur. Si tu ne sais pas ce qu'est une datasheet, c'est un excellent indicateur pour dire "pas touche"... ;) Déjà, parce que la notion même de socket n'existe plus à ce niveau, et que l'on raisonne exclusivement au niveau du protocole Ethernet lui-même. Les contraintes de temps de réponse et de traitement ne sont en plus pas du tout ce à quoi tu es habitué, c'est un monde de driver et non pas d'application utilisateur.
Après, tu peux bien sûr étudier ce que tu veux, mais si tu n'as pas une excellente connaissance des réseaux et des différentes couches du modèle OSI, tu t'exposes à un sacré paquet de nœuds à la tête... Être curieux, c'est très bien, mais il faut aussi prendre les choses dans le bon sens et le bon ordre.
Je suis sous linux, si j'ai dis dll tout à l'heure c'était que je ne retrouvais plus le terme bibliothèque pour le linkage static, je test mes soft en les envoyant à des connaissance via msn ou autre cependant je préfère leur éviter 36000 manœuvre car il ne sont pas forcément caler en informatique pour la plus part l'ordinateur = MSN .
Pour la question de l'accès a encore plus bas niveau, je sais ce qu'est qu'un datasheet et je n'ai aucune envie de descendre plus bas ( en niveau ) que je ne le suis déja c'était simplement pour savoir si cela était possible je me doute bien qu'à un tel niveau la notion de socket est révolue .
Ce qui me motive à chercher au niveau de socket RAW ; c'est simplement que j'ai déja coder une appli client/serveur sous Qt sans dire que c'était facile il faut reconnaitre que Qt nous mache beaucoup le travail ... et ca j'aime pas, tout du moins tant que j'ai pas compris ce qui se passe plus bas et comment tout cela fonctionne .
Pourquoi les sockets RAW ? Tout simplement parce que Qt ne les gère pas donc je pars de 0 et que j'aimerai essayer d'envoyer une trame Arp qui est relativement "simple" au niveau du contenu.
Donc voila c'est un peu mon défi du moment : réussir à balancer une foutu trame ARP à ma livebox :D.
Sur ce je vous souhaite une bonne soirée et merci encore.
SO (Shared Object) pour l'équivalent DLL, ou "libXXX.a" pour les librairies statiques ".lib".Citation:
Envoyé par geek-59600
C'est possible, en effet. Mais honnêtement, à part si tu dois supporter une carte réseau inconnue sur ton OS, il y a peu d'intérêt à l'opération : les drivers existants sont en général déjà très optimisés, et faire "mieux" sera extrêmement difficile.Citation:
Envoyé par geek-59600
Je te le redis : utiliser les raw sockets, c'est en fait deux problèmes conjoints.Citation:
Envoyé par geek-59600
Le premier, c'est de gérer les layers OSI manuellement, avec toutes leurs variantes et cas spéciaux. Si tu veux un bon exercice, vraiment complet à ce niveau, tu n'as qu'à réimplémenter le protocole UDP (+ IPv4 ou v6, + ARP, +BootP/DHCP, + ICMP, + LLC éventuellement, + Ethernet). Tu verras que c'est déjà loin d'être trivial. Ce problème-là est totalement impossible à shunter, tu DOIS te le taper de A à Z.
Si tu veux un bon "énoncé", essaie de créer une pile UDP capable de simuler un nombre quelconque d'équipements Ethernet (adresses MAC simulées + récupération dynamique d'adresses IP via DHCP, avec notamment gestion complète ICMP / ARP). Tu as déjà quelques semaines de boulot devant toi avec ça, voire quelques mois... ;) Bien sûr, le "secret" réside dans l'épluchage des diverses RFC de chaque protocole, et dans une excellente conception de ta pile.
Le deuxième, c'est la gestion de ces sockets au niveau de l'OS lui-même, et l'activation du mode promiscuous. Des éléments comme le PF_RING seront nécessaires pour avoir un taux de transfert décent, et il faudra te battre avec les BPF (Berkeley Packet Filter) pour améliorer les perfs si jamais tu n'as pas les buffers PF_RING. De plus, cette partie n'est pas vraiment portable, et tu vas trouver des soucis de portabilité d'une machine à l'autre, même avec un OS identique. De plus, là, pas le choix : l'application devra tourner en root/Administrateur, donc pas top côté sécurité.
C'est à ce niveau-là que je te conseille d'utiliser PCAP, qui te permettra de t'affranchir de cette partie et de te concentrer sur la partie intéressante (la première, donc)... Quitte à revenir dessus plus tard, une fois les protocoles OSI maîtrisés !!
Mais dis-toi bien que si des logiciels comme tcpdump ou Wireshark sont basés exclusivement sur PCAP, il y a une bonne raison...
Bon courage !
Bon je vais suivre ton conseil et je vais voir du coté de libcap :)