Journal Hébergement dynamique et modem ADSL Comtrend

Posté par  .
Étiquettes : aucune
0
1
juin
2006
En France, les fournisseurs d'accès ADSLfournissent beaucoup les modems routeurs ADSL de marque Comtrend pour faire les fameux Box avec la téléphonie par IP.

Malheureusement ces modems ne possèdent pas de fonctions intégrée pour gérer des services comme dyndns.

Un petit script est disponible pour récupérer sur le modem directement l'adresse IP publique.

en associant ce script à un client standard comme ddupdate ou ddclient, vous pouvez désormais faire les vérifications de changement d'ip toute les minutes grâce à ce petit script.

Beaucoup de client pour les noms de domaines tentent d'intégrer directement cela, alors pourquoi ce script ?

Parce que les clients ne sont pas forcément disponible sur toutes les distributions ou systèmes, en utilisant ce script, si votre modem est peu connu, ce script assure son support pour tout les clients de nom de domaine dynamique. Enfin cela permet de mieux respecter le principe de "faire une seule chose mais bien". Il est écris en shell, donc portable sur tout les systèmes libres, et ne demandent que très peu de dépendance par conséquent (wget uniquement).

il est disponible dans sa version 0.1 sur https://gna.org/projects/comtrend-ip/

Dans sa futur version, ce script va s'étendre à un maximum de modem tout en assurant une taille du script exécutable minimale, donc si vous pensez que ce script peut vous servir, ou bien vous souhaitez que votre modem soit géré sur la prochaine version n'hésitez pas à l'indiquer sur le suivie de bug ou sur la liste de diffusion.

  • # Quelques remarques sur le script

    Posté par  . Évalué à 4.

    Voici quelques remarques:

    Tu fais des tests avec -s pour savoir si le fichier existe. En général on utilise plutot le -r.

    -s FILE True if file exists and is not empty.
    -r FILE True if file is readable by you.

    Si le fichier est vide, on s'en fiche un peu, ça n'empèche pas de le sourcer; par contre, s'il n'est pas lisible, ça va provoquer une erreur. Il est aussi possible de remonter une erreur si le fichier n'est pas lisible.

    Tu retournes l'aide en exécutant pratiquement vingt fois la commande echo. Dans bash, c'est une commande interne qui ne fait peut-être pas un fork, mais avec d'autres shell, cela peut faire appel à une commande externe. Pour cela, on préfère généralement faire un seul echo, ou un cat

    echo -e "Première ligne\\nSeconde ligne"

    echo "Première ligne
    Seconde ligne"

    ou encore

    cat << _VERSION_
    Première ligne
    Seconde ligne
    _VERSION_


    Si le wget retourne une erreur, tu ne testes rien, tu te contentes de regarder si quelque chose sort au bout de la chaine.
    L'adresse IP du routeur est codée en dur à 192.168.1.1
    wget utilise la version courte des paramêtres, rendant la relecture du script plus compliquée.
    Il y a aussi une dépendance sur logger, je ne sais pas s'il est présent sur toutes les distribs, sous les BSD...

    Voila, sinon c'est encourageant de voir qu'il y a encore des choses écrites proprement. Quand je vois ce pourquoi on paye au boulot...

  • # Pourquoi ?

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

    Salut

    Je ne comprend pas pourquoi tu t'embette a faire un script qui communique avec le modem.

    Pourquoi ne pas se connecter vers un serveur distant qui irait lui dire:
    ton ip c'est xxx.xx.x.xx

    Un peut comme le champ remote_addr d'un script env.cgi

    • [^] # Re: Pourquoi ?

      Posté par  . Évalué à 1.

      Parce que sur un service externe tu ne peux pas te permettre de faire une vérification toutes les minutes ou 30 secondes, ce n'est pas raisonnable en terme de charge réseau. La plupart des services externes si tu ne dispose pas de ton propre serveur à l'extérieur, te demande de ne pas faire un check moins de toutes les 10 minutes.

      • [^] # Re: Pourquoi ?

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

        Toutes les minutes on regarde si on change d'IP. Je pense a un bidouillage avec traceroute

        Voila ce qui ce passe sur ca propre IP
        $ traceroute 172.207.14.36
        traceroute to 172.207.14.36 (172.207.14.36), 30 hops max, 38 byte packets
        1 172.207.14.36 (172.207.14.36) 0.803 ms 0.835 ms 0.767 ms


        Sur une autre IP
        $ traceroute 172.207.14.33
        traceroute to 172.207.14.33 (172.207.14.33), 30 hops max, 38 byte packets
        1 192.168.1.1 (192.168.1.1) 33.461 ms 0.699 ms 0.616 ms
        2 rt-prstc01.dial.aol.com (195.93.106.65) 38.283 ms 37.989 ms 38.414 ms


        On cherche la nouvelle IP et apelle dyndns si on vois que l'IP enregistrée a changé

        • [^] # Re: Pourquoi ?

          Posté par  . Évalué à 0.

          il te faut utiliser un serveur extérieur, en partant du principe qu'il te laisse l'ICMP, et en plus quand tu regardes la cible, ceux qui hébergent derrière une ADSL, il te faut minimiser au maximum le traffic extérieur pour le dédier aux personnes venant de dehors.

          Le script te fait çà en une requête unique, qui ne fait intervenir personne de l'extérieur, pas de charge réseau, ni en local quand tu vois la tête du script dedans.

  • # Note pour ceux qui sont belges et abonnés à Scarlet

    Posté par  . Évalué à 2.

    Le modem/routeur de Scarlet, la Scarlet Box, qui n'est en fait qu'un Copperjet 816-2p, peut se transformer en vrai modem PPPoE tout en gardant la VoDSL active.

    Ca simplifie grandement la mise-à-jour d'un service comme DynDNS et la stabilité est également très profitable, croyez-moi !

    Comment faire ? Switcher la connexion WAN en mode RFC1483 Bridged

Suivre le flux des commentaires

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