oooops, chntier repris sous le nom
ArduinoEthernetBridge moins (P2P avbe ouverture de ports)
dessin:
vocabulaire:
- central: réseau local "ordinaire"; lien internet, serveur dhcp
- satellite: machine ou sous réseau distant, ses adresses Ip fournies par le Dhcp du réseau central
QPC: nécessite peut-être de pouvoir mémoriser un paquet entier, donc pas nano! 328!
(sauf si on arive à utiliser les 8 K du
Enc28J60?
QPC: créer un attribut qui dise la nature d'un paquet:
numéroter (modulo 128 le paquet envoye
se dispatch sut data[0]
- 0 : paquet "court" la suite et à injecter tel que
- 1: interdit (serait le long d'un paquet court!)
- pair: en-tête:
- le premier octet (data[1]) est à conserver pour restaurer le paquet origine
- la suite à conserver comme entête
- impair >0: contenu d'un paquet long (sauf le premier octet)
QPC: comment "intercepter" les paquets:
- par la connexion sur un réseau non switché (HubVersusSwitch), voire Wifi WEP!
- mais ça n'arrêterait pas la diffusion au reste du réseau, on aurait par exemple deux réponses dhcp, etc...
- en se présentant comme "passerelle"
- la bête a une IP sur le réseau local
- la cible configurée manuellement avec cet IP comme passerelle
- compatible une seule interface ethernet
-
mais faudrait aussi définir des routes si on veut être compatible avec le trafic local
tout paquet reçu de l'adresse mac de la cible est transmis (en bifide) au central
- les req dhcp
- les paquets Tcp ou Udp
toute paire de paquets reçue du central (sur le port X) est reconstitué et réémis
éventuellement deux pieds dans le même sabot avec deux interfaces sur le réseau local
- passerelle physique: nécessite deux cartes ethernet (4 € de plus! donc devis avec un 2560: environ 20 €, 40 € la paire)
- une connexion vers le sous réseau satellite (une ou plusieurs machines??, aura des IP sur le réseau central)
- plus besoin de définir une passerelle manuellement
- transmettra y compris la requête dhcp initiale (qui sera servie par le "central")
- pas de communication entre la cible et le réseau local
- pas besoin de connaître adresse mac
- une connexion sur le réseau local
- tout ce qui arrive sur la prise "cible" est transmis à l'autre (sous forme de paquet bifide)
- tout ce qui arrive à l'Ip publique (en paquets bifides) est transmis vers la cible (ou le réseau cible)
- GAFFE permet de relier deux ordis symétriques, en ip fixe sans qu'ils aient accès à internet!
- routé
- dans la conf précédente, pas de communication du satellite avec son réseau local ni internet
- pour faire plus:
- cible sur le réseau local
- pobox sur le réseau local avec deux IP dites privée et publique
- règle de routage sur la cible disant que pour telle IP/plage du réseau central, route vers ip privée de la pobox
- les IP définies dans la règle ci dessus échappent au protocole who has IP etc ...
deux gadget appariés, avec comme paramètres:
- adresse mac de la "cible"
- adresse IP de la plateforme d'interconnexion (ou de l'autre boitier)
GAFFE à l'embonpoint, si le paquet est "proche" (à 54 octets) de la taille max Tcp
si le paquet est court:
- le paquet comme données , donc les deux adresses mac à l'offset 0 et 6 sont différentes
paquet "long": il faut envoyer le paquet en deux morceaux (dit bifide),
la seule différence entre central/distant est le fait de capturer selon adresse mac source ou destination!
le boitier "central"
- adresse mac de la "cible"
- éventuellement plusieurs,
- éventuellement auto-apprentissage
- adresse IP de la plateforme d'interconnexion (ou de l'autre boitier)
- capture sur la base de l'adresse mac destination:
- les broadcast
- dest mac de la cible ou des cibles et les emballe pour envoyer au boitier distant
- reçoit les paquets venant du distant, les déballe et poe sur le réseau
le boitier "distant"
- adresse mac de la "cible"
- transmet tous les paquets reçus
- adresse IP de la plateforme d'interconnexion (ou de l'autre boitier)
- capture sur la base de l'adresse mac source : la la cible
prise en charge des paquets sortant du tunnel:
déterminer si c'est :
- une en-tête de paquet long data[0..5] = data[6..11] = mac-address de la cible la mac-address de la cible est à prendre en fin du paquet
se baser sur le premier octet seon la définition en préambule.
dilemme
- en-tête d'abord
- demande de mémoriser les données: trop pour la ram du nano
- un peu plus simple à la réception (juste écraser en-tête)
- données d'abord
- ne demande de mémoriser que 54 caractères à l'émission
- mais à la réception ?????
pour la "capture",pas de souci, le paquet est intégralement disponible dans la "loop"
URGENT: trouver comment émettre un paquet "forgé"
(en fait ça s'apparente à l'envoi d'un paquet udp, pas de dialogue, etc...)
utiliser "packetsend"
s'inspirer de echo icmp
en réception depuis le cloud:
- 1 recevoir entête et mémoriser les 54 ??? caracteres (ou différent selonb protocole)
- 2 recevoir paquet de données et écraser en-tête avec le contenu du paquet mémoris
et ça doit le faire!
variante folle:
- le boitier "central" prend l'adresse mac de la CIBLE distante, donc filtrage automatique des paquets à envoyer