Home ¦ Archives ¦ Atom

Routeur OpenWrt hybride (Mesh babel + Access Point)

27 octobre 2013: Ajout d'une précision concernant l'option proto de la configuration de babel, en fin d'article


Je détaille ici la configuration d'un routeur sous OpenWrt, ici le MR3020 mais ça doit être la même chose pour d'autres routeurs, en tant que machine « hybride » qui fait office de nœud d'un réseau Wifi mesh utilisant babel (babel mesh), et de point d'accès. La machine peut éventuellement posséder un accès internet, c'est comme on veut.


/etc/config/network

config interface 'lan'
    option ifname 'eth0'
    option proto 'dhcp'

config interface 'wan'
    option proto 'static'
    option ipaddr '172.16.1.1'
    option netmask '255.255.255.255'

config interface 'wifi'
    option proto 'static'
    option ipaddr '10.0.0.1'
    option netmask '255.255.255.0'

lan, wan et wifi sont les noms uniques des interfaces logiques. On précise aussi de quelle manière on assigne des ip aux interfaces:

  • On utilise dhcp pour l'interface physique eth0: on peut ainsi brancher par ethernet le mr3020 à n'importe quelle machin box sans plus de configuration que celà

  • Côté wan (pour babel) j'assigne l'ip statiquement en espérant que personne sur le réseau mesh n'a la même. Il faut donc un tableau quelque part qui récapitule ce qui est utilisé et ce qui ne l'est pas, ou passer par un protocole du type ahcp

  • Enfin, pour wifi, le hotspot, je m'assigne l'ip que je veux statiquement, sachant que c'est moi qui fait tout dans ce réseau: passerelle vers internet, serveur dhcp, etc… C'est le réseau pour gens.


/etc/config/wireless

config wifi-iface
    option device 'radio0'
    option encryption 'none'
    option ssid 'Mesh'
    option mode 'adhoc'
    option bssid 'CA:FE:CA:FE:CA:FE'
    option network 'wan'

config wifi-iface
    option device 'radio0'
    option mode 'ap'
    option ssid 'OpenWrt'
    option encryption 'none'
    option network 'wifi'
    option wmm '0'

On configure ici l'interface physique correspondant aux deux interfaces logiques wan et wifi. On configure wan en mode Ad-Hoc, pour le mesh, et wifi en point d'accès (AP) pour un hotspot plus classique. Si on le souhaite, on peut configurer un portail captif sur ce dernier.


/etc/config/babeld

package babeld

config general
    option 'local_server' '33123'

config interface 'wan'

config filter
    option type 'redistribute'
    # This entry only applies to local addresses. 
    option local 'true'
    # Route installed by kernel.   
    option proto '2'
    # This entry only applies to routes in the given prefix. 
    option ip '172.16.1.1/24'
    # Allow this route, without changing its metric (or setting 
    # its metric to 0 in case of a redistribute filter). 
    option action 'allow'


# Redistribute the internet !
config filter
    option type 'redistribute'
    option ip '0.0.0.0/0'
    option le '0'
    option metric '128'

# Refuse anything else locally
config filter
    option type 'redistribute'
    option local 'true'
    option action 'deny'

# Refuse anything else globally
config filter
    option type 'redistribute'
    option action 'deny'

Enfin, le fichier de configuration babeld qui va déterminer quelles routes on annonce, quelles routes on accepte, quelles routes (installées par un programme tiers par exemple) on redistribue.

C'est dans ce fichier de configuration que toute la magie du mesh opère.

On commence par les derniers blocs qui précisent qu'on accepte rien par défaut: on va donc devoir autoriser au cas par cas les routes que l'on souhaite voir redistribuées.

Juste avant ces deux blocs, on dit qu'on redistribue la route par défaut (si elle existe bien sûr) pour permettre un accès à internet. La métrique est statique, ce qui est un peu sale, on pourrait imaginer une métrique qui dépend de la qualité de l'accès à internet.

Enfin, le premier bloc redistribute s'occupe de donner l'accès aux autres machines du mesh, il est commenté donc ça devrait être assez simple à comprendre.

Voilà voilà, faudrait tester ça pour un véritable réseau utilisé par des gens et pas uniquement comme proof-of-concept.


Note:

Dans la configuration de babel, l'option proto (« proto p: This entry only applies to kernel routes with kernel protocol number p. […] ») utilise les numéros tels que définis dans le fichier /usr/include/linux/rtnetlink.h.

Ainsi, on a:


/usr/include/linux/rtnetlink.h

/* rtm_protocol */

#define RTPROT_UNSPEC   0
#define RTPROT_REDIRECT 1   /* Route installed by ICMP redirects;
                               not used by current IPv4 */
#define RTPROT_KERNEL   2   /* Route installed by kernel        */
#define RTPROT_BOOT 3   /* Route installed during boot      */
#define RTPROT_STATIC   4   /* Route installed by administrator */

/* Values of protocol >= RTPROT_STATIC are not interpreted by kernel;
   they are just passed from user and back as is.
   It will be used by hypothetical multiple routing daemons.
   Note that protocol values should be standardized in order to
   avoid conflicts.
 */

#define RTPROT_GATED    8   /* Apparently, GateD */
#define RTPROT_RA   9   /* RDISC/ND router advertisements */
#define RTPROT_MRT  10  /* Merit MRT */
#define RTPROT_ZEBRA    11  /* Zebra */
#define RTPROT_BIRD 12  /* BIRD */
#define RTPROT_DNROUTED 13  /* DECnet routing daemon */
#define RTPROT_XORP 14  /* XORP */
#define RTPROT_NTK  15  /* Netsukuku */
#define RTPROT_DHCP 16      /* DHCP client */
#define RTPROT_MROUTED  17      /* Multicast daemon */

© Rémy G.. Built using Pelican. Theme by Giulio Fidente on github.