Journal Port sous powerpc de NuFW

Posté par  (site web personnel) .
Étiquettes : aucune
0
26
juil.
2005
NuFW, le parefeu authentifiant, voir http://www.nufw.org,(...) a été portée sous powerpc et le résultat des travaux ont abouti à la version 1.0.11. Testé sur un mac G3 (merci au liveCD ubuntu) et validé par ailleurs sur les architectures 64 bits, NuFW devrait donc fonctionner sur la plupart des architectures Big Endian.

À signaler également, de nouvelles fonctionnalités comme une option de nufw permettant d’améliorer la vérification du certificat de nuauth et quelques corrections de bogues.

Cette version devrait clore les évolutions fonctionnelles de la branche 1.0. Le travail sur la branche de développement 1.1.x devrait donc bientôt commencer.

Le programme des évolutions n'est pas encore complètement défini et toutes les suggestions sont donc les bienvenues. N'hésitez pas à faire des commentaires !

  • # ...

    Posté par  . Évalué à 2.

    Au passage il se situait ou les pb d'endianess ?
    J'ai du mal a voir ou ca peut intervenir dans un parefeu.

    • [^] # Re: ...

      Posté par  (site web personnel) . Évalué à 2.

      L'architecture de NuFW est en mode client/serveur :
      http://www.nufw.org/article.php3?id_article=3(...)

      Les problèmes étaient au niveau des échanges entre les différents composants car toutes les données de type adresse IP, ports, longueur de paquets sont envoyées de manière binaire.

      Conçu et testé sur machines little endian, le protocole ne se comporte pas de manière idéale lors d'un changement d'endianness. Il a donc été nécessaire de faire les conversions nécessaires au niveau du parsage des informations reçues et au niveau des envoi de données.

      • [^] # Re: ...

        Posté par  . Évalué à 3.

        ou m'enfin y a les fonctions htons et equivalent qui permet de gerer les infos binnaires sur un réseau....
        Et si l'appli avait bien ete concu elle aurait du les utiliser.

        • [^] # Re: ...

          Posté par  (site web personnel) . Évalué à 1.

          Mea culpa, oui c'est ce qui est utilisé maintenant.

          > Et si l'appli avait bien ete concu elle aurait du les utiliser.

          On n'a pas tous fait l'ENSIMAG option système et réseau ;-) certains sont autodidactes d'où certaines approximations lors de la conception du protocole d'échange ...

          • [^] # Re: ...

            Posté par  (site web personnel) . Évalué à 2.

            Juste une petite curiosité (je n'ai pas fait ENSIMAG option système et réseau ;-)) : comment faisiez-vous les échanges alors? Dans tous les exemples que je trouve couramment sur le net concernant la conception d'applications réseau en UDP & TCP/IP, c'est htons qui est conseillé....
            Je ne savais même pas qu'on pouvait utiliser aut' chose.... C'est dire!

            • [^] # Re: ...

              Posté par  (site web personnel) . Évalué à 1.

              En fait c'est plus subtil que ça. Lors de la définition des échanges bianires du protocole il est nécessaire de définir une endianess des envois de données binaires. C'est à tort, que l'encodage little endian a été choisi lors des développements initiaux (effectué sur plateforme x86, donc choix implicite). Hors les fonctions de la famille htons sont égales à l'identité sur architecture big endian. On ne peut donc pas effectuer de conversion par leur aide.

              Morale de l'histoire : mettre les champs en big endian avant d'envoyer sur le réseau pour ne pas avoir de problèmes avec les architectures big endian lorsque l'on définit un protocole.

              Je regrette rarement d'être autodidacte en informatique, là c'est le cas ;-)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.