8-12-99.
Au mois de décembre, dans les froides montagnes grenobloises, les pc freebsd commencent leur lente migration vers la version 3.3. Tandis que le prototype de mobilité hiérarchique a déjà migré en 3.3, les pc continuent leur compilation de la souche IPv6 des heures durant, c'est beau un pc qui compile.
7-12-99.
Quelques petites corrections/ameliorations :
3-12-99.
Une autre avancé importante aujourd'hui : le MA est capable d'apprendre de nouveaux correspondants pour les MH qu'il gère. Chaque nouveau correspondant reçoit des BU selon la politique hiérarchique définie.
Si on regarde la liste des fonctionnalités mobilité hiérarchique à réaliser ____ on s'aperçoit que le prototype est fini.
Donc je suis maintenant en mesure de démarrer un mobile sur son réseau mère en lui demandant de tourner en mode 2, de voyager de site en site tout en étant suivi par une liste de correspondants grandissantes grace au smooth handoff entre MA.
Reste maintenant :
De ces travaux resortira une feuille d'évaluation de la mobilité hiérarchique dans FreeBSD.
2-12-99.
Deux avancées importantes :
Avancement moins important mais intéressant pour les tests, le parametrage de tout un tas de variables par les fichier de conf /etc/mobile6 et /etc/gateway6. J'ai commençais la redaction d'un document sur comment installer/utiliser la mobilité hiérarchique dans FreeBSD. Ce document sera remis au ssprojet 5 pour sa campagne de tests. Il sera en ligne dès que possible.
Pour faire des tests j'utilise maintenant un HA AIX situé dans les locaux de BULL Echirolle. Cependant un phénomène étrange existe entre nos deux sites. On perd un paquet sur deux ! J'ai donc soumis ce problème aux responsables réseau. Néanmoins, ce problème est intéressant car il permet de tester comment se comporte le proto lorsque des paquets se perdent. Cela m'a permis de trouver des bug dans les procédures d'enregistrement des mobiles et dans les smooth handoff.
Il me reste donc sur le gaz du codage de conf, et la détection de nouveaux correspondants par un MA (ouie c'est chaud).
Les spécifications fonctionnelles ont été mises à jour avec une paragraph sur les changements de mode. Il reste donc à coder certains de ces cas qui ne l'étaient pas encore(UHMMA mode 2 vers les autres modes).
La synchronisation des numéros de séquence entre le MH et son MA a été réalisé telle qu'elle est décrite dans les spec fonctionelles. Cela a pour but que le MH sache quel numéro de séquence attendre de son HA, lorsqu'il tourne en mode 2 (pas de liste de CH).
L'horrible oubli qui faisait qu'un mobile en mode 1 envoyait des BU à tous ses CH lorsqu'il se déplae à l'intérieur d'un site, a été comblé. La politique hiérarchique est donc ok.
Une réflexion sur Cellular IPv6 a été ouverte. Il s'agit pour l'instant de comprendre comment fonctionne CIPv4 pour déterminer la meilleur façon de le porter en IPv6 :.
Francis Dupont s'est lancé sur la trace du filtre qui coupe mes BACK contenant des listes de CH, prochainement le smooth handoff sera donc ok, et plus besoin de le passer dans un BREQ.
22-11-99.
Voilà. Les spécifications fonctionnelles et techniques d'implémentation dans FreeBSD sont mises à jour et en ligne. J'attend les commentaires des partenaires pour corrections et additions. Au cours de la mise à jour de ces documents, il m'est apparu que j'avais oublié deux choses absoluments primordiales :
Je m'en vais donc corriger ces deux oublis de ce pas.
èSuite à la très bonne impression de CC lors de son brillant exposé lors de la conférence organisée par les gens de Cellular IP, il devient primordial d'adapter Cellular IP à notre framework, pour prouver que ce framework peut effectivement accepter n'importe quel protocole de gestion de micro mobilité. Je m'en vais donc me devenir un chef en Cellular IP, avant de l'adapter en IPv6 et l'intégrer dans le framwork.
Travaux :
15/11/99.
Depuis un mois où je n'ai pas été très prolixe sur le site, je travaillais dur sur l'implémentation afin de la finir et de pouvoir livrer une distribution exploitable. Le mode 1 est fini, tandis qu'il ne manque que la détection des correspondents par le MA pour le mode2. En fait soyons plus objectif, tous les tests effectués l'ont été en utilisant le mobile ethernet de FD. J'attend avec impatiente mes cartes WLAN pour tester dans un autre environnement. Le passage d'une carte à l'autre me semble aussi très intéressant à explorer. Reste également les différentes swap entre les différents modes, qui pour l'instant ne sont pas jugés prioritaires. Il me reste à éclaircir ce qu'il doit ce passer quand un mobile changer de mode. J'ai déjà les cas simple de UHMMA mode 1 vers MIPv6 et inversement. Il faut ensuite mettre en place des procédures de smooth handoff entre le mobile et son précédent MA pour passer de UHMMA mode 2 a MIPv6 (et inversement).
Au cours de ce mois, en plus de finir le code, j'ai beaucoup retravailler le code existant, pour qu'il soit plus "lisible" et plus indépendant. J'ai suis passer de 6 fichiers a 14, cela signifie que j'ai bien séparé le code, à la manière de FD dans ndpd-mobility. Il me reste encore a retravailler les commentaires qui ne sont pas à jour pour la pluspart, suite au modification citées ci-dessus.
Tableau des types de mouvement.
J'ai inclu le code du BS dans le MA, ce qui permet de limitter le nombre de machines pour mes tests. Un MA communique maintenant son adresse et son mode (UHMMA 1 ou UHMMA2), les BS transmettent ce mode dans les rt adv en plus de l'adresse. J'ai enfin pris le temps de coder une méthode de configuration des machines en utilisant /etc/gateway6.
Lorsque je codais, il m'est venu plusieurs idées que je vais maintenant développer.
Tout d'abord pourquoi avoir un MA qui tourne UHMMA en mode 1 ou en mode 2, et pourquoi pas les deux ? L'idée est bonne et n'est pas compliquée à implémenter. Un MA sera alors capable de gérer des mobiles en mode 1 et d'autres en mode 2. Le mode de fonctionnement du MA sera toujours annoncé dans les rt adv. Un MA annonçant un mode 2, sera capable de faire les deux modes, car le mode 1 est inclu dans le mode 2. Par contre un MA annonçant un mode 1, ne fera que du mode 1. Par contre cela nous créait d'autre cas de changement de mode. Nous avons maintenant 6 cas de swap.
En lisant le nouveau draft MobileIP, je me suis inspiré de la découverte des HA, pour envisager une méthode de partage du travail pour les MA. Nous savons que le travail effectué pour un mobile en mode 2 sera important, il est donc intéressant de prévoir des solutions pour ne pas écrouler le MA. Plusieurs MA sur le virtual network me semble une bonne solution. Tout comme font les HA, le MA peuvent s'échanger leur adresse dans les rt adv (du virtual network) avec un entier symbolisant leur charge. Chaque MA se construit alors une liste de MA, en triant cette liste dans l'ordre du moins chargé au plus chargé. Ce n'est donc plus l'adresse d'un MA qui sera donnée au mobiles arrivant sur le site, masis une adresse anycast ; tous les MA du site. Le mobile va donc faire une demande de liste des MA en utilisant cette adresse. Un MA va lui répondre et lui donnant la liste (ou un bout de la liste). Le mobile n'aura plus qu'à utiliser le premier de la liste (le moins chargé) pour s'enregistrer.
Voilà, pour les travaux à venir, il va falloir :
7/10/99.
Très bien. Cela fait maintenant plus d'une semaine que je n'ai pas mis à jour le site. Ce satané windows a encore crashé, me privant de mon éditeur HTML. Me voilà de retour avec un bon vieux netscape. Résumé de la semaine dernière. J'ai entièrement retravaillé la politique des mouvements dans mon code. Je cherche à rendre UHMMA complétement indépendant de MIP, afin d'éviter les plus possibles les interactions. Je réduis donc l'emploi de hack dans MIPv6 pour produire mes propres fonctions. J'ai ensuite continué à tester debugger mon code. Il m'est également apparu de nouveaux cas de figure auquel je n'avais pas pensé comme le changement de carte réseau, les deux étant connectées sur le même lien, même si physiquement il n'y a pas eu de mouvement, pour MIP il s'agit d'un mouvement puisque changement de coa. Le mouvement ne se gère donc maintenant pls que par les fonctions mobile_move, major_move mais aussi par des fonctions qui gèrent les interfaces, telles mobile_chgif et mobile_chgha. En ce début de semaine j'ai intégré dans le code les fonctions de swap d'un mode à l'autre. Cela m'a parrut important car tous les sites ne seront pas équipés de MA. Pour l'instant je n'ai que les swap de MIP vers UHMMA1 et inversement. J'ai testé, cela fonctionne. J'ai également testé un nouveau cas de mouvement visite - > home. Il est ok également. Mais pour l'instant mes tests ne portent que sur des mouvements avec changement d'interfaces. FD a produit ce qu'il appelle la mobilité ethernet ; on branche et débranche les cables à chaud et ça marche. Pour en être sur j'ai pris du temps pour faire des tests. Les résultats sont en ligne.
Tests MIPv6 6 octobre 99.
Moralité : ça marche bien. Je vais donc intégrer mon code dans cette nouvelle souche (une nouvelle fois ....) et commencer à tester mes cas de mouvement par la "mobilité ethernet", car pour ces mouvement là, le cheminement d'exécution n'est pas le même que pour le changement de cartes. Affaire à suivre. Afin de préparer des cas de mouvement inter et intra site, j'ai remanié la plate-forme pour former deux sites distincts /48. Cela m'a également permis de tester la politique d'envoi de BU aux CN : coa pour le domain local, vcoa pour les autres ; ca marche. Plate-forme. Reste toujours le problème que le mobile envoie des paquets avec sa H@ en source. FD ne m'a toujours pas répondu à ce sujet. Je vais mettre en place sur duvel, un cron qui me mailera quand un fichier source de MIPv6 est modifié.
27/9/99.
Bon cela semble ok pour le mode 1 ; à savoir que le mobile gère lui même les BU, on respecte ainsi le bout en bout. Le MA n'est qu'un proxy. J'avais quelques craintes pour la découverte des correspondants à cause du double proxy (ha/ma) et cela fonctionne, mais qu'en tcp/udp, par icmpv6 cela ne produit pas de découverte. FD est au Japon, je ne sais donc pas, si cela vient de lui (pas fini le pcb) ou de moi (double proxy). Donc je résume mes tests :
Il me reste donc à tester / debugger les autres mouvements : visite -> visite, visite -> home pour le mode 1 et régler un ptit problème de politique de positionnement de l'adresse source en émission de paquet du mobile ; pour l'instant j'utilise la h@ pour les CH et la coa pour le MA et la vcoa pour le HA ; enfin bref c'est un peu le basard de ce coté là ... Pour ce qui est du mode 2 ; le fait de réaliser le mode 1 m'a reglé les gros problèmes que je me trainais depuis juin. C'est pas encore fait, mais 90 pour cent du code est là. J'ai aussi integre MIP, UHMMA mode 1 et 2 dans le code de ndpd-host, on peux ainsi démarrer dans n'importe quel mode avec le même binaire. Quand j'aurais le mode 2 opérationnel, on regardera cellular. Par contre les politiques pour passer d'un mode à un autre sont devenues un peu flou du coup. Passer du mode 2 à MIP et vice versa est simple et peut être fait en utilisant du code déjà existant, par contre le mode 1 faut que j'y réfléchisse à froid, et cellular, pffffuuuuuuu. Maintenant je vais donc finaliser le mode 1 (adresse du mobile en sortie) et tester les autres déplacements. J'en proffiterais alors pour tester le code "moveable" de FD, cela me fera donc trois pierres d'un coup, car je préparerais TEC en même temps. Je me suis fixe vendredi soir pour que le mode 1 fonctionne, c'est bien parti, et je vais peut être même réussir à caser TEC dans la semaine. Il me restera ensuite à aller à BULL pour tester les scenarios TEC avec des AIX (comme le jour du salon). Début de semaine prochaine, le mode 2 sur le grill. Là je pense batailler plus à cause des smooth handoff. Disons que mi-octobre me semble raisonnable. Cela me laissera deux trois semaines pour regarder cellular IP et être prêt pour mi novembre. Après enfin je prend 6 mois de vacance ;-)
23/9/99.
Après être allé au connectathon sur mobile IPv6 et vu les avancements de FD, j'ai eu l'irrestible envie d'upgrader la plate-forme en FreeBSD 32, car la souche est quand même beaucoup mieux.
J'ai donc fait l'upgrad de toutes les machines, ce fut long et douloureux (d'ailleurs il y en a encore une qui compile ...). Maintenant c'est ok, j'ai la nouvelle souche de FD et je me suis empressé de faire quelques tests pour vérifier ses nouvelles fonctionnalités. Evidement elles ne fonctionnent pas toutes. La découverte des correspondants est ok, et c'est une bonne nouvelle pour moi. La détection de mouvement fonctionne aussi, pour peu que l'on augmente la fréquence des rt adv. Par contre le traitement résultant d'un mouvement n'est pas au point ! Mais bon j'ai porté le code de UHMMA direct dans cette souche. Il me faudrait pondre un outil qui patch automatiquement (ou aide) car c'est la troisième fois que je le fais. J'ai compilé c'est ok.
Dans la foulée j'ai trouvé pourquoi le paquet contenant l'adresse du MA n'arrive pas a destination. Il est correctement construit par le MA et envoyé sur le réseau. C'est le kernel de la BS qui le filtre car il s'agit là d'une option non reconnue. J'ai regardé dans le noyau ; il existe une fonction pour traiter chaque type de destination option. Il faudra donc écrire une nouvelle fonction pour ma nouvelle option. Pour l'instant, je vais me servir d'une option existante et y ajouter une sub-option. Cela permet de passer le kernel. Je vais utiliser un BReq, qui est l'option la plus simple.
Je vais aussi réflechir à ce que CC a appelé la solution 1 ; le MA n'est qu'un proxy et le MH s'enregistre auprès de lui. Cette solution semble beaucoup plus simple, et évitera les divers problèmes de smooth handoff. Cela va donc créer un nouveau mode de fonctionnement, nous aurons donc MIP, UHMMA1 (pas de prise en charge par le MA) et UHMMA2 (prise en charge par le MA). A première vue, UHMMA1 est déjà écrit, il s'agit uniquement de rajouter des tests aux bons endroits pour obtenir l'effet voulu. Cela semble facile, je vais rédiger un petit papier organique sur cette solution et patcher le code, je me donne 10 jours pour faire marcher cette solution. Après quoi je continuerais sur UHMMA2 et les divers problèmes de smoth handoff.
13/9/99.
Bon ok le proxy du MA fonctionne.
En fait il y avait trois problèmes :
if (! gateway_enabled == "YES") alors packet droppedDonc il faut que le HA (MA) soit un routeur !!! Même s'il n'a qu'une seule interface.
Conclusion : on peut donc dire que l'on a un processus d'enregistrement du mobile qui fonctionne correctement sans intervention humaine (pour ajouter une route par exemple). Prochaine étape : déplacement inter site.
6/9/99.
FreeBSD 3.2 :
Bon finalement, le HA de la 32 ne marche pas non plus !!! Je dois oublier qq chose. Je vais faire un appel au secour sur la mailing list.
Je profite d'avoir un 32 pour commencer le portage de la partie MA. Ainsi, lorsque mon pb de HA sera régler j'aurais déjà une partie de HMIP sous 32, car je pense qu'un portage massif n'est pas une bonne solution. Il vaut mieux procéder machine par machine.
Pour ce portage, je vais revoir ma politique d'ajout de code. Jusqu'à présent j'ajoutais mon code dans celui de MIP à grands coups de ifdef/endif. Je réutilisais alors beaucoup de code de FD, mais certaines fonctions possèdent plus de ifdef que de code. Pour ce portage je vais donc créer de nouvelle fonction pour HMIP et limitter ainsi les ifdef. J'aurais donc plus de fonctions, mais elles seront plus lisibles.
Le portage a été effectué en une après midi. Les quelques changements apportés par FD et Richier ont posé qq pb de compilation, mais maintenant c'est ok.
27/8/99.
Le mobility agent :
Le processus d'enregistrement d'un mobile fonctionne correctement. J'ai rajouté en hard un CH pour le mobile qui s'enregistre. Pour l'instant j'ai pris ce CH sur le même brin que le MA, ce qui n'est pas une bonne chose (conclusion du jour). Je vais donc le prendre sur le réseau entre grue et ibis, là où il n'y a aucune autre machine.
Au moment des tests il existait plusieurs tug actif. La raison est que j'utilise GDB et que donc je ne sors pas proprement du programme. Le nettoyage n'est donc pas fait. Il faut que je refasse un test avec une machine clear, et je serais si le problème venait des tugs ou de ci dessus.
A bien y réflechir cela peut également provenir du fait que la machine cherchant à joindre le mobile par son VCOA se trouve sur le même lien que le MA, sur le MN donc. Il s'échange alors une quantité de nd soll nd ann impressionnante, mais le MA ne redirige toujours pas. Je vais donc déplacer ma machine vers un autre réseau.
La version de FD sur la quelle je travaille possède encore des pb. Un mobile est incapable de joindre son home network lorsqu'il s'est enregistré (envoi des BU), et ce à cause d'une home route mal positionnée.
J'ai regardé comment se visualise un tug sur le HA : il est RUNNING (flag 8050) et possède la conf : inet6 HA address/128 -> H@
Mon tug sur le MA est RUNNING et possède la conf : inet6 MA address/128 -> VCOA
Le MA est maintenant capable d'envoyer des HR vers le HA et des BU vers des CH (il restait un bug de taille de paquet pour les BU, maintenant corrigé).
29/8/99.
Problème de tug/anycast suite :
Le problème persiste... Cad que le MA ne fait pas suivre les paquets destinés à la VCOA. Le routeur envoie une nd sollicitation pour demander qui a la VCOA, mais le MA ne répond pas.
J'ai pourtant revu en détail le fonctionnement du proxy du HA de FD pour le reproduire, mais sans résultat. J'ai d'abord pensé que l'erreur venait de la fonction del_troute ; fonction qui utilise la H@ pour travailler. Dans mon cas, il ne faut pas utiliser la H@ mais la VCOA. J'ai donc pensé faire un swap en cet endroit. En analysant où se faisait l'appel à cette fonction j'ai constaté que le swap je l'avais déjà fait, puisque l'appel a del_troute se fait dans add_tunnel, l'endroit où je swap H@ et VCOA pour créer un tunnel/proxy vers le mobile. L'erreur est donc ailleurs. Je pense que mon tug est correctement configuré.
J'ai noté au passage que le MA envoie bien un grat. radv comme le fait le HA sur le home network ; ce rtadv grat est correct d'après les traces, une analyse du paquet serait cependant souhaitable.
Après tous ces essais, j'ai regardé en détail le fonctionnement du proxy de FD sur un HA tout simple. J'ai regardé les paquets qui passe au moment de l'établissement, puis au moment où une machine s'adresse à la H@ ; et j'ai constaté que cela ne machait pas non plus ! Etrange car il s'agit de la distrib de juin, celle que j'ai moi même fait marcher plusieurs fois (et qui a maché pour la démo). Je vais donc reprendre un test, avec un mobile de FD et un HA de FD avec un CH tout con qui fait un telnet sur la H@ en ayant pris soins de rebooter toutes ces machines (pour virer toute entrée dans un cache du kernel). Si cela ne fonctionne toujours pas, j'installerais la version 3.2 de FreeBSD et la dernière souche en date de FD sur le HA. Cela devrait marchait ; je commencerais alors à porter mon code sur cette nouvelle souche, en commençant par le MA, en concervant le MH pour l'instant, car celui-ci produit ce que j'escompte pour l'instant.
28/8/99.
Le mobile :
Le mobile se lance et utilise la détection de mouvement de FD. Il envoie un paquet de registration au cours du processus de boot. Ce paquet est correct d'après les traces de tcpdump.
Le mobile s'ouvre un tunnel vers le MA, ce tunnel possede les flags 8050 (RUNNING), par contre il ne possede pas de conf. => vérifier avec MIP de FD le comportement est le même.
Le mobile stocke le paquet de reg. en mémoire et lance un timer pour la réémission s'il ne reçoit pas les BACK escomptés. J'ai coupé la route vers le MA, le paquet n'est donc jamais arrivé. La réémission a eu lieu, c'est donc ok pour cela. J'ai changé de politique quant à la gestion des timers dans ndpd-host. Je ne reserve plus en début de programme de la mémoire une bonne fois pour toute pour les timers afin de les réutiliser. Je déclare en début les pointeurs sur timer, et je creais des nouveaux timers à chaque fois que nécessaire. Je fais cela car la gestion des timers est étrange.
run_timeout retire un timer qui expire de la liste des timers. Ensuite il lance le traitant associé. Enfin si le status du timer n'a pas changé dans le traitant, la mémoire du timer est libérée. Je prend soins lorsque je lance un timer de prévoir qu'il soit détruit lorsqu'il expire, ainsi je peux en lancer un autre au lieu de réutiliser la même structure, ce qui me causait des problèmes de blocages.
Le mobile s'ajoute bien les adresses temp et home sur son interface. Il utilise sa COA pour acceder au réseau visité mais sa home pour les autres adresses, ce qui n'est pas terrible du tout. Ce problème n'existait pas avant cet instant. Après avoir recommencer l'expérience plusieurs fois, le problème ne se pose plus que pour adresser le home network. Il n'y a pas de H@ option dans les paquets sortant car je travaille encore sur une version qui ne fait pas de reconnaissance de nouveaux CH. Il faut les déclarer dans /etc/mobile6, et alors les H@ sont ok. ICMPv6 ne marche pas non plus avec cette version, les tests de connexion sont donc fait exclusivement avec telnet.
Le mobile continue ensuite son exécution et relance le paquet d'enregistrement si le MA ne répond pas. J'ai du tracer le processus de boot d'un mobile utilisant la souche de FD, et ce affin de trouver une petite erreur. Cette erreur provoquait l'envoi de 2 paquets d'enregistrement et plantait finalement à cause de l'insertion du même timer deux fois.
Trace du boot.
Le mobile fonctionne donc jusque là, je poursuis maintenant le trace d'un enregistrement dans le MA, pour que le MH reçoive ses BACK.
27/8/99. L'ajout de la VCOA sortie du BACK fonctionne sans soucis, c'est comme une H@, je l'ai mise en place avec un préfix de 128. Le mobile ne peut cependant pas continuer (commencer) à fonctionner car le proxy du MA n'est pas op pour l'instant. On peut cependant gruger en changeant la politique d'attente de BACK, et ainsi vérifier que le mobile peut recevoir des paquets addressés à la VCOA. Avec un petit bout de code simple, j'ouvre un tug tout bête vers le mobile est je construis un paquet destiné à la VCOA. Le paquet passe sur le brin (les deux machines sont sur le lien) et se fait décapsuler et est traité. Pour être sur qu'il est traité, j'ai mis une destination option dedans (un BU) et comme ça le paquet a été remonté à ndpd-host pour traitement. Un point d'arrêt sur recv_destop dans gdb et voilà le test vérifié.