La Fibre
Satellite et faisceau hertzien => Satellite et faisceau hertzien => 
Satellite / radioamateur => Discussion démarrée par: Leon le 03 juin 2012 à 19:30:07
-
Bonjour à tous,
J'ai un projet perso de modem radioamateur qui nécessiterai de faire un driver réseau spécifique.
Je n'ai jamais fait ça, est-ce que quelqu'un d'entre vous a déjà touché à ce genre de choses? Vu le nombre d'experts en réseau sur le forum, je me dis que j'ai un espoir!
Je compte faire un truc compatible windows XP et ultérieur (vista, 7).
Le protocole dans le modem serait un truc fait maison, il n'échange pas que des données IP avec le PC, donc je dois mettre un soft entre l'interface modem, et le driver.
Le soft principal èmet et reçoit des infos au modem via une puce "FT2232", qui est une puce d'interface USB2. Le plus simple pour dialoguer avec, c'est d'émuler un port série. Ca, je sais faire, j'ai commencé à bidouiller avec.
A la sortie du programme associé au modem, on aura des trames IP brutes (pas Ethernet).
Bien évidemment, il faut qu'un bout de mon programme soit appelé à chaque fois qu'il voit une trame IP à envoyer.
Pour le paramétrage (adresse IP, passerelle, DNS, etc), même si ça n'est que manuel dans un premier temps, ça me va très bien, chaque chose en son temps! Bien évidemment, je me contente d'IPV4.
J'ai un peu feuilleté les pages "driver" et "driver réseau" de windows, mais ça ressemble beaucoup à du charabia pour moi. J'ai un peu peur que ce soit inaccessible pour mes connaissance basiques. Mais je me dis aussi que je n'aurais pas besoin d'utiliser toutes les fonctions optionnelles. Je souhaite faire quelque chose de simple, le plus simple possible avant tout.
Je peux programmer en C, C++, ou C#, peu importe.
Bref, c'est faisable, à votre avis? Ou alors je suis en plein délire? Vous avez des cours ou des tutoriels sur le sujet? Des exemples?
Bien évidemment, si vous voyez une autre solution plus simple que l'écriture d'un nouveau driver, je suis également preneur! Du moment que c'est simple et accessible.
Merci d'avance pour votre aide à tous.
Leon.
-
Tu souhaites faire passer des paquets IPv4 sur la radio et les récupérer à l'autre bout (donc un pont) ?
Peu de personnes savent programmer des drivers, la probabilité d'en avoir un ici est faible.
J'ai par contre vu des revues (dispo en kiosque) qui abordent le sujet régulièrement. Tu pourrais peut être trouver une aide dans les anciens numéros.
-
Regarde du côté de SLIP (http://www.sics.se/~bg/telos/slipintro.pdf) pour la partie réseau et d'un driver série virtuel comme com0com (http://com0com.sourceforge.net/).
Cela donnerait un assemblage dans le style stack IPv4 Windows => SLIP => com0com => ton_deamon_gerant_le_modem => RS232 => ton_modem
-
Tu souhaites faire passer des paquets IPv4 sur la radio et les récupérer à l'autre bout (donc un pont) ?
Oui, c'est exactement ça.
Peu de personnes savent programmer des drivers, la probabilité d'en avoir un ici est faible.
Je me disais qu'il y avait peut-être des étudiants, ou anciens étudiants qui auraient vu ça dans leurs cours.
J'ai par contre vu des revues (dispo en kiosque) qui abordent le sujet régulièrement. Tu pourrais peut être trouver une aide dans les anciens numéros.
Quelle genre de revue, stp? Ca m'intéresse.
Cela donnerait un assemblage dans le style stack IPv4 Windows => SLIP => com0com => ton_deamon_gerant_le_modem => RS232 => ton_modem
Oui, j'y ai pensé. C'est un peu lourd à mettre en oeuvre, mais ça serait effectivement beaucoup plus simple à programmer!
J'ai aussi une autre alternative, qui est de créer une 2ieme connexion série depuis le modem, qui transporte du SLIP. Mais je ne sais pas si le microcontrôleur du modem pourrait suivre la cadence (ARM Cortex M3).
Merci en tout cas pour vos réponses. Je vais continuer à chercher.
Leon.
-
Salut à tous. Je déterre mon sujet, car je vais probablement ressortir mes bidouilles dans un futur proche.
SLIP était une très bonne piste. J'avais déjà testé, pour faire communiquer 2 PC sous Win XP, et ça fonctionnait plutot bien.
MAIS (oui, il y a un mais) SLIP n'est plus supporté sur Windows 7 et 8!
Donc je fais de nouveau appel à vos idées. D'après-vous, est-ce qu'il existe d'autres solutions alternatives pas trop complexes à mettre en oeuvre, pour répondre à mon besoin? Et qui soit compatible Win7 et 8?
Merci d'avance pour votre aide!
Leon.
-
J'entends d'ici totonrobert :
Bawé, c'est pas simple de payer les conneries du passé, hein ?
La procrastination n'aide en rien le problème
Ça ressemble fort à une bouse fait à la rache ton truc;
-
C'est typiquement un sujet pour lequel tu trouveras de l'aide dans la communauté DYI (Raspberry PI et surtout Arduino) mais plus coté Linux que Windows donc.
C'est impératif Windows?
Le souci avec Windows c'est la complexité des drivers.
Il faut déjà passer des heures a comprendre comment ca marche, le kernel-mode, le user-mode et les 'classes' de drivers.
Ce dernier point est très important car suivant la classe du driver il existe ou pas des choses facilitant la création d'un driver.
En classe 'réseau' il y a modèle NDIS et ses variations entre XP, 7 et 8. Enfin ca c'est tu veux faire un truc 'qui est vu' dans le systeme comme une carte réseau.
Les points de départ:
comprendre les concepts (http://msdn.microsoft.com/en-us/library/windows/hardware/ff554731(v=vs.85).aspx), le WDM et sa suite le WDF (http://msdn.microsoft.com/en-us/library/windows/hardware/ff557565(v=vs.85).aspx), le WDK (http://msdn.microsoft.com/library/windows/hardware/ff557573).
comprendre les différentes classes: http://msdn.microsoft.com/en-us/library/windows/hardware/ff557557(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/hardware/ff557557(v=vs.85).aspx)
voir si un des exemples peut te servir de base: http://msdn.microsoft.com/en-us/library/windows/hardware/ff554118(v=vs.85).aspx (http://msdn.microsoft.com/en-us/library/windows/hardware/ff554118(v=vs.85).aspx)
choisir l'étendu : XP, 7, 8 les 3 ou que 7,8 ou que 8 ou que XP, etc
J’avoue c'est très complexe. :P j'ai fait du dev de drivers a l'époque de 2000/XP pour des drivers d'imprimante et j'en n'ai pas un bon souvenir..du tout.
Souvent on peut partir du driver fourni par un constructeur ou faire au dessus du driver USB générique. Regardes si la puce au bout du câble USB a des API ou un driver pour Windows par exemple.
Mais la 1ere étape c'est de bien conceptualiser ton projet et faire un design haut niveau plus précis :en gros, comment ça doit marcher . La ca n'est pas assez clair, du moins pour moi, pour t'aider ou t'orienter dans telle ou telle direction.
-
Donc je fais de nouveau appel à vos idées. D'après-vous, est-ce qu'il existe d'autres solutions alternatives pas trop complexes à mettre en oeuvre, pour répondre à mon besoin? Et qui soit compatible Win7 et 8?
Qemu + un linux pour la partie intelligence?
Windows 7/8 =ETHERNET=> TAP/Qemu =ETHERNET=> Stack IP Linux =SLIP=> Accès direct COM/Qemu =serial=> HW
:)
-
LE BOULET ;D
tu veux quoi exactement ( ? ) car j'ai des liens sur des radioamateurs ( et leurs bidouilles de ouf ) qui devrait permettre de trouver ton bonheur ( je l'espère ) :)
je suis dans la grisaille :(
-
J'entends d'ici totonrobert :Ça ressemble fort à une bouse fait à la rache ton truc;
Ah ça, oui, et je le revendique, même ! :P
C'est ça qui m'amuse : bidouiller, découvrir des choses, avancer dans la résolution de problèmes, en amateur, sans se prendre la tête.
J'ai déjà une petite expérience en bidouille électronique/robotique avec les 3 réalisations suivantes. J'ai réalisé ces 3 projets intégralement tout seul, j'ai tout programmé tout seul, sa reprendre la moindre ligne de code de projets pré-existants.
* BOB4, (http://heli.bot.free.fr/)un drone autonome volant en intérieur
* BOB3, (http://ze.bot.free.fr/)un robot roulant d'intérieur autonome, avec des capacités de planification de trajectoire
C'est typiquement un sujet pour lequel tu trouveras de l'aide dans la communauté DYI (Raspberry PI et surtout Arduino) mais plus coté Linux que Windows donc.
C'est impératif Windows?
Windows est impératif? Oui et non. J'aimerai bien que ma solution soit à la fois compatible Linux et Windows. Je sais, je suis en train de vouloir le beurre et l'argent du beurre.
souvent on peut partir du driver fourni par un constructeur ou faire au dessus du driver USB générique. Regardes si la puce au bout du câble USB a des API ou un driver pour Windows par exemple.
Oui, la puce FTDI2232 (interface USB) a déjà des drivers et/ou API pour l'utiliser sous Windows ou Linux. Pas de problème, cette partie là fonctionne déjà. Je sais dialoguer à plusieurs Mb/s (je sais, ça ne vous impressionne pas, mais moi si!) entre un programme fait maison sur mon PC et la carte que je développe. Il "suffit" d'utiliser des drivers simulant une connexion série, c'est à priori le plus simple. Par contre, ça ne me donne aucune piste pour l'interfaçage de mon programme sur PC avec la couche réseau (OSI L3) du PC. C'est bien ça mon plus gros problème.
J’avoue c'est très complexe. :P j'ai fait du dev de drivers a l'époque de 2000/XP pour des drivers d'imprimante et j'en n'ai pas un bon souvenir..du tout
C'est vrai qu'avec ça, tu ne me fais pas vraiment envie. Et vu mon faible niveau en programmation sur PC, je crois bien que je vais abandonner l'idée de faire des drivers, et me tourner vers une autre solution.
Qemu + un linux pour la partie intelligence?
Windows 7/8 =ETHERNET=> TAP/Qemu =ETHERNET=> Stack IP Linux =SLIP=> Accès direct COM/Qemu =serial=> HW
Euh, j'avais dit "simple". Ca ressemble un peu à une usine à gaz, ton idée! Mais je note.
En fait, mon idée du moment est de rajouter une interface Ethernet au modem, et d'embarquer toute l'intelligence nécessaire à la transformation IP-protocole radio directement dans la carte à microcontrôleur du modem. Le problème à résoudre, c'est de trouver une pile IP qui soit assez stable, et de faire fonctionner tout ça avec le peu de ressources de la carte (j'ai 256kO de RAM).
tu veux quoi exactement ( ? ) car j'ai des liens sur des radioamateurs ( et leurs bidouilles de ouf ) qui devrait permettre de trouver ton bonheur ( je l'espère ) :)
En fait, j'ai dans la tête une idée assez folle : inventer un nouveau protocole de transport de l'IP, mais aussi de voix numérique, sur radio. Donc clairement, mon objectif est de ré-inventer la roue, et de ne pas utiliser les solutions qui existent déjà (AX.25 ou HSMM à base d'équipements WiFi ou DSTAR...). Ca peut paraitre idiot dit comme ça, mais mon objectif premier est d'apprendre par la pratique, d'explorer des solutions peu exploitées actuellement, de m'amuser. Sur ce genre de projet, je sais bien que les probabilités de réussite sont faibles, mais qui ne tente rien... ;)
Le plus important pour moi n'est pas forcèment l'objectif final, mais plutôt la démarche qui y conduit.
Et puis d'autres (avec beaucoup plus d'expérience que moi) se sont déjà lancés dans cette avanture, voir exemple ici:
http://lea.hamradio.si/~s53mv/nbp/nbp.html (http://lea.hamradio.si/~s53mv/nbp/nbp.html)
http://lea.hamradio.si/~s53mv/nbp/atnc.html (http://lea.hamradio.si/~s53mv/nbp/atnc.html)
Leon.
-
j'ai vu j'ai lut je suis sur le C.l c'est pas des plus simple a comprendre pour le voyageur ;D en faite tu destine ton quotidien à mettre sur pied un modèle de transmission qui serait commun & modifier par tes soins :P
j'ai trouver
http://www.networksorcery.com/enp/protocol/ip.htm (http://www.networksorcery.com/enp/protocol/ip.htm)
http://support.microsoft.com/kb/289892/fr (http://support.microsoft.com/kb/289892/fr)
http://www.frameip.com/ (http://www.frameip.com/)
je m'excuse :-[ si je me suis planter et pour les liens
c'est ma contribution du BOULET
Bonne journée avec un p't peu de soleil ;D
-
Ah ça, oui, et je le revendique, même ! :P
C'est ça qui m'amuse : bidouiller, découvrir des choses, avancer dans la résolution de problèmes, en amateur, sans se prendre la tête.
J'ai déjà une petite expérience en bidouille électronique/robotique avec les 3 réalisations suivantes.
Pour encourager les bonnes volontés :
http://code.msdn.microsoft.com/windowshardware/Windows-8-Driver-Samples-5e1aa62e/view/SamplePack#content (http://code.msdn.microsoft.com/windowshardware/Windows-8-Driver-Samples-5e1aa62e/view/SamplePack#content)
Je regarderais les exemples USBSamp et NDIS Virtual Driver.
Toaster est le tutorial qu'ils font grandir au fur et à mesure des exemples
Je viserais Windows 7 et supérieur (le modèle de drivers a évolué au moment de Vista, en particulier la couche réseau, mais devient stable à partir de 7/2008R2)
Sinon "LA" ressorce non MSFT pour les drivers c'est http://www.osronline.com/ (http://www.osronline.com/)
-
Oui, la puce FTDI2232 (interface USB) a déjà des drivers et/ou API pour l'utiliser sous Windows ou Linux. Pas de problème, cette partie là fonctionne déjà. Je sais dialoguer à plusieurs Mb/s (je sais, ça ne vous impressionne pas, mais moi si!) entre un programme fait maison sur mon PC et la carte que je développe. Il "suffit" d'utiliser des drivers simulant une connexion série, c'est à priori le plus simple. Par contre, ça ne me donne aucune piste pour l'interfaçage de mon programme sur PC avec la couche réseau (OSI L3) du PC. C'est bien ça mon plus gros problème. C'est vrai qu'avec ça, tu ne me fais pas vraiment envie. Et vu mon faible niveau en programmation sur PC, je crois bien que je vais abandonner l'idée de faire des drivers, et me tourner vers une autre solution.
Donc t'as un existant qui marche, tu veux ajouter du 'réseau' :
Un truc simple à faire : ajoute lui un socket réseau pour échanger des données via IP.
Tu peux partir sur un protocole simple pour voir comment ca marche: un simple 'echo'/chat par exemple.
Puis ensuite tu peux faire évoluer ca en un serveur GRE par exemple (ou autre serveur point a point sur IP style PPTP, SSH, L2TP, SSL).
A l'arrivé tu auras un truc ou il suffit d'ouvrir une session avec pour avoir un lien réseau (couche 3) via ton équipement.
-
Salut,
Perso je regarderais du coté de TUN/TAP:
* Le driver windows existe déjà, et sous linux aussi.
* Ya des tas d'exemple de code, à commencer par les VPN & wireshark.
Du coup , ça se décomposerais simplement en un démon qui écouterais les trames venant du FT2232 , et les réinjecter (en utilisant l'API TUN/TAP) dans la couche réseau Windows, qui les gérera ensuite "normalement".
A la vitesse d'un port série, ça ne risque pas de causer de problèmes.
A voir aussi si le FTDI sur port série est obligatoire: Si tu connais les teensy (notamment les derniers , version 3 ou 3.1) , ils sont plus puissants et permettent plus de chose en USB. J'dis ça car je suis en train de bosser sur un firmware pour ces machins qui , quand tu les branche en Ethernet, serait reconnu sous windows (et linux) comme une carte ethernet USB (peut-être par RNDIS, je sais pas encore - là je suis sur le CDC-Ethernet). Après, niveau firmware rien de plus simple d'utiliser le port série hardware du teensy pour faire une sorte de convertisseur série <> IP (enfin si , faut gérer la couche TCP/IP, mais heureusement ça existe déjà)
Perso mon projet est pour de la domotique, mais le concept de IP over HAM me plait bien aussi... :-)
-
Merci à Obinou et Kgersen!
Je vois que je ne suis pas le seul à bidouiller, ça me rassure! :)
Merci pour ces idées. Ca me mets sur d'autres pistes que je ne connaissais pas du tout, et c'est exactement ça que je recherchais! :)
Un truc simple à faire : ajoute lui un socket réseau pour échanger des données via IP.
Tu peux partir sur un protocole simple pour voir comment ca marche: un simple 'echo'/chat par exemple.
Puis ensuite tu peux faire évoluer ca en un serveur GRE par exemple (ou autre serveur point a point sur IP style PPTP, SSH, L2TP, SSL).
A l'arrivé tu auras un truc ou il suffit d'ouvrir une session avec pour avoir un lien réseau (couche 3) via ton équipement.
Pour les tunnels GRE ou autre, c'est une bonne idée à la base. Mais malheureusement, GRE n'est pas supporté sur Windows, les implèmentations de GRE étant visiblement rares et non maintenues; et les autres types de tunnels semblent complexes à gérer (il faudrait que je simule l'autre bout du tunnel).
Perso je regarderais du coté de TUN/TAP:
* Le driver windows existe déjà, et sous linux aussi.
* Ya des tas d'exemple de code, à commencer par les VPN & wireshark.
Du coup , ça se décomposerais simplement en un démon qui écouterais les trames venant du FT2232 , et les réinjecter (en utilisant l'API TUN/TAP) dans la couche réseau Windows, qui les gérera ensuite "normalement".
Pour TUN/TAP, ça ressemble à une bonne solution pour ce que je veux faire : interfacer une application avec une carte réseau virtuelle. Je vais regarder ça de plus près, en espérant que ça soit accessible pour moi.
A voir aussi si le FTDI sur port série est obligatoire: Si tu connais les teensy (notamment les derniers , version 3 ou 3.1) , ils sont plus puissants et permettent plus de chose en USB.
J'utilise les FTDI2232 qui émulent (côté PC) des ports séries, mais côté matériel, c'est interfacé comme des FIFO 8 bits, donc ça permet des transferts à haut débits (plus de 100Mb/s), même avec le driver qui émule un port série. Je ne suis donc pas limité par la vitesse/puissance des vrais ports série. C'est juste qu'il est plus facile pour moi d'écrire un programme qui dialogue avec un port série (virtuel ou réel), plutôt qu'un programme qui s'interface avec un driver que je maitrise moins.
Je vous tiendrais au courant de mes bidouilles, mais ça n'est pas pour tout de suite.
Leon.
-
Si SLIP n'est plus supporté, PPP l'est certainement encore. C'est son successeur. Après en protocole L2 pour faire du point a point, il y aussi HDLC.
-
Si SLIP n'est plus supporté, PPP l'est certainement encore. C'est son successeur. Après en protocole L2 pour faire du point a point, il y aussi HDLC.
Oui, PPP est supporté par les windows récents. Mais si je choisis PPP, il faudra que je simule un serveur PPP, ce qui est complexe. Autant pour du SLIP, ça se fait en quelques lignes de code, mais pour du PPP, c'est autre chose.
HDLC n'est plus supporté non plus par les windows récents, comme SLIP. Il existe des programmes"tiers" pour faire du HDLC ou du SLIP.
Je note toutes ces idées, et je creuse avant de me faire une opinion et de me lancer. J'aurais plein de tests à faire pour vérifier si certaines solutions sont faisables.
Leon.