- Ce qui est fait
- Le fonctionnement des bornes, plus en détail
- Power Over Ethernet
- Ce qu'il reste à faire
- Des liens
Ce qui est fait
- La portée de la borne a été testée au G :
- en la mettant dans une chambre au milieu du 3ième étage côté Cournot et butte, on reçoit dans tout le couloir du troisième étage, dans toute la partie centrale du couloir du 4ième (entre les deux douches/WC) et même au 5ième, à la verticale de la borne.
- donc 4 bornes devraient suffire pour couvrir tout le bâtiment, en en mettant une par étage au niveau des douches, en alternance (par exemple : côté campus au 1ier, côté C. Desmoulins au 2ième, côté campus au 3ième, côté C. Desmoulins au 4ième)
- La portée de la borne a été testée à la Kfet, bon signal partout, y compris vers l'extérieur de la Kfet, si on place la borne dans le fauxplafond derrière le bar. On a l'accord du BdE. La borne est installée pour la phase de test. Elle est reliée au réseau en 10 MBits à cause de la distance entre la Kfet et le local du B. Une solution à base de fibre/switch intermédiaire est à l'étude.
- On a aussi testé au J et au B. Ca passe moins bien qu'au G.
- Au B, on peut mettre la borne dans le faux plafond en espérant faire une dérivation de l'alimentation par des boîtiers de dérivations (JPD nous a déconseillé d'utiliser l'alimentation des plafonniers pour des raisons de norme et de sécurité). Pour le réseau, intercepter un câble et y coller un T (et pareil en bas). Il faudra voir JPD pour les détails. A priori, si on la met près de l'endroit où le bâtiment fait un T, cela devrait passer, une par étage, en alternant un peu, gauche/droite. En un mettant une à un étage, on reçoit à l'étage du dessus sur presque tout le couloir.
- Au J, on peut utiliser les locaux associatifs, ça a l'air alors de porter sur presque tout l'étage (les chambres côté butte ont du mal à recevoir à cause du dernier mur porteur). Il n'y a pas de fond plafond, mais l'électricité arrive facilement ainsi que le réseau. Si on essaie de mettre dans le fond plafond dans le couloir, il faut au moins trouver l'électricité, on a pas pu tester à cause de l'absence de prise dans le couloir (contrairement au B). On a regardé aussi les petits locaux techniques, certains font passer l'électricité, d'autres le réseau, d'autres l'eau. Mais aucun n'a tout ce qu'il faut. Après discussion avec JPD, il semble qu'une solution sous le faux-plafond dans les nouveaux bâtiments est aussi envisageable que comme au B.
- Un firmware spécialisé, une configuration automatique, la mise en place d'IPsec, bref, le gros du travail est fait !
Un DNS *.wifi.crans.org est en place. Pour les ../NomsPourLesBornes, on se base sur les dieux vikings pour le moment.
- Le wifi a sa zone d'IP : 138.231.148.0/22
- Le routage est fonctionnel, les firewalls ont été mis à jours
- Le serveur de clefs est assuré par ISAKMPd
- Les bornes logguent pas mal de chose via syslog
- Le serveur vient de passer sous OpenBSD qui supporte mieux ISAKMPd
- Un proxy transparent est en place au cas où la détection de proxy échoue (car a pris trop de temps à cause de la négociation des clefs)
Un autostatus des bornes a été réalisé.
Il y a des bornes au G, à la Kfet, au CRAP, au B, au J, au Krobot et dans l'ENS ! (cf ../PositionnementDesBornes)
- Il y a des stats sur les bornes (et snmpd a été installé dessus)
Le fonctionnement des bornes, plus en détail
Les bornes pouvaient être opérées selon deux modes :
- en routeur
- en bridge (comme un switch)
De plus, il fallait à un moment utiliser de l'IPsec pour sécuriser le bidule.
La solution routeur a été écartée :
- le premier avantage d'un tel mode aurait été de coller IPsec sur la borne, mais cela aurait nécessité un 2.6 (implémentation KAME).
- il aurait fallu segmenter les IP dispos par borne, vu que l'on va prendre des IP publiques, c'est un peu dommage.
Upload new attachment "solution1.jpg"
- Et un petit schéma :
- en vert, la solution bridge
- en bleu, la solution routeur
- le rouge, c'est IPsec
Solution bridge avec machine séparée qui fait de l'IPsec
Maintenant, comment configurer CransNounous/IpSec ? On utilise un serveur ISAKMP, racoon en l'occurrence. On l'utilise en mode clefs partagées.
![/!\](/wiki/crans-www/img/alert.png "/!\"){kind=small}
Cette solution permet aux utilisateurs de Windows d'utiliser IPsec à peu de frais, même si cela nécessite d'installer des outils supplémentaires.. L2TP a l'air assez compliqué à mettre en oeuvre...
Maintenant, il faut empêcher les gens qui ne font pas de l'IPsec d'utiliser le wifi, sinon, ils sont branchés physiquement sur le CRANS. Une première solution aurait été d'utiliser les VLAN pour être sûr que tout le trafic des bornes arrive sur egon. Cependant, la borne ne sait pas tagguer les vlan1. La solution de mettre un switch taggueur derrière la borne est un peu coûteuse.
Si la borne ne laisse passer que l'IPsec à destination de egon, il n'est pas nécessaire de faire des VLAN. On procède donc comme ça : la borne fait bridge filtrant et ne laisse passer que l'IPsec et le DHCP (à améliorer).
Firmware personnalisé pour la borne
Afin d'avoir une borne presque tout bien configurée dès le début, pour avoir un bridge filtrant, pour avoir un serveur ssh et pour éviter les services inutiles, on va faire notre propre firmware.
Comme point de départ, on prend un firmware de Sveasoft dont les sources sont disponibles sur le FTP du CRANS. Les instructions pour la construction sont sur http://sveasoft.cyberemail.org/SV-BuildingFromSource.html. Un point important est que l'on doit partir de la version 2.00.8 et non de la dernière version. Le patch pour la version 6 est aussi dispo sur sila.
En modifiant release/src/router/shared/defaults.c, on peut personnaliser dès le départ certains paramètres, dont notamment l'activation du serveur SSH avec mot de passe et clef personnalisée. On désactive donc les services inutiles, on donne une IP presque correcte (que l'on modifiera une fois).
Voici le diff avec l'original :
--- defaults.c 2004-01-07 00:24:34.000000000 +0100
+++ defaults.c~ 2004-04-08 15:37:02.090364000 +0200
@@ -35,13 +35,8 @@
{ "timer_interval", "3600", 0 }, /* Timer interval in seconds */
{ "ntp_server", "", 0 }, /* NTP server */ /* Modify */
//{ "time_zone", "PST8PDT", 0 }, /* Time zone (GNU TZ format) */
-#if COUNTRY == JAPAN
- { "time_zone", "+09 1 0", 0 }, /* Time zone (GNU TZ format) Japan */
- { "daylight_time", "0", 0 }, /* Automatically adjust clock for daylight */
-#else
- { "time_zone", "-08 1 1", 0 }, /* Time zone (GNU TZ format) USA */
+ { "time_zone", "+01 1 1", 0 }, /* Time zone (GNU TZ format) USA */
{ "daylight_time", "1", 0 }, /* Automatically adjust clock for daylight */
-#endif
{ "log_level", "0", 0 }, /* Bitmask 0:off 1:denied 2:accepted */
{ "upnp_enable", "0", 0 }, /* 0:Disable 1:Enable */
@@ -50,13 +45,13 @@
{ "console_loglevel", "1", 0 }, /* Kernel panics only */
/* Big switches */
- { "router_disable", "0", 0 }, /* lan_proto=static lan_stp=0 wan_proto=disabled */
- { "fw_disable", "0", 0 }, /* Disable firewall (allow new connections from the WAN) */
+ { "router_disable", "1", 0 }, /* lan_proto=static lan_stp=0 wan_proto=disabled */
+ { "fw_disable", "1", 0 }, /* Disable firewall (allow new connections from the WAN) */
/* TCP/IP parameters */
{ "log_enable", "0", 0 }, /* 0:Disable 1:Eanble */ /* Add */
- { "log_ipaddr", "0", 0 }, /* syslog recipient */
- { "log_show_all", "0", 0 }, /* show all message */
+ { "log_ipaddr", "", 0 }, /* syslog recipient */
+ { "log_show_all", "1", 0 }, /* show all message */
/* LAN H/W parameters */
{ "lan_ifname", "", 0 }, /* LAN interface name */
@@ -65,9 +60,9 @@
{ "lan_hwaddr", "", 0 }, /* LAN interface MAC address */
/* LAN TCP/IP parameters */
- { "lan_proto", "dhcp", 0 }, /* [static|dhcp] */
- { "lan_ipaddr", "192.168.1.1", 0 }, /* LAN IP address */
- { "lan_netmask", "255.255.255.0", 0 }, /* LAN netmask */
+ { "lan_proto", "static", 0 }, /* [static|dhcp] */
+ { "lan_ipaddr", "138.231.148.254", 0 }, /* LAN IP address */
+ { "lan_netmask", "255.255.252.0", 0 }, /* LAN netmask */
{ "lan_stp", "0", 0 }, /* LAN spanning tree protocol */ /* Please set to 0 */
{ "lan_wins", "", 0 }, /* x.x.x.x x.x.x.x ... */
{ "lan_domain", "", 0 }, /* LAN domain name */
@@ -80,10 +75,10 @@
{ "wan_hwaddr", "", 0 }, /* WAN interface MAC address */
/* WAN TCP/IP parameters */
- { "wan_proto", "dhcp", 0 }, /* [static|dhcp|pppoe|disabled] */
+ { "wan_proto", "disabled", 0 }, /* [static|dhcp|pppoe|disabled] */
{ "wan_ipaddr", "0.0.0.0", 0 }, /* WAN IP address */
{ "wan_netmask", "0.0.0.0", 0 }, /* WAN netmask */
- { "wan_gateway", "0.0.0.0", 0 }, /* WAN gateway */
+ { "wan_gateway", "138.231.148.1", 0 }, /* WAN gateway */
{ "wan_dns", "", 0 }, /* x.x.x.x x.x.x.x ... */
{ "wan_wins", "", 0 }, /* x.x.x.x x.x.x.x ... */
{ "wan_hostname", "", 0 }, /* WAN hostname */
@@ -100,7 +95,7 @@
{ "filter_macmode", "deny", 0 }, /* "allow" only, "deny" only, or "disabled" (allow all) */
{ "filter_client0", "", 0 }, /* [lan_ipaddr0-lan_ipaddr1|*]:lan_port0-lan_port1,proto,enable,day_start-day_end,sec_start-sec_end,desc */
- { "filter", "on", 0 }, /* [on | off] Firewall Protection */
+ { "filter", "off", 0 }, /* [on | off] Firewall Protection */
{ "filter_port", "", 0 }, /* [lan_ipaddr|*]:lan_port0-lan_port1 */
{ "filter_rule1", "", 0 }, /* $STAT: $NAME:$$ */
{ "filter_rule2", "", 0 }, /* $STAT: $NAME:$$ */
@@ -211,7 +206,7 @@
/* Web server parameters */
{ "http_username", "", 0 }, /* Username */
- { "http_passwd", "admin", 0 }, /* Password */
+ { "http_passwd", "xxxxxxxx", 0 }, /* Password */
{ "http_wanport", "8080", 0 }, /* WAN port to listen on */
{ "http_lanport", "80", 0 }, /* LAN port to listen on */
@@ -237,8 +232,8 @@
{ "wl_corerev", "", 0 }, /* Current core revision */
{ "wl_phytypes", "", 0 }, /* List of supported wireless bands (e.g. "ga") */
{ "wl_radioids", "", 0 }, /* List of radio IDs */
- { "wl_ssid", "linksys", 0 }, /* Service set ID (network name) */
- { "wl_country", "Japan", 0 }, /* Country (default obtained from driver) */
+ { "wl_ssid", "Cr@ns", 0 }, /* Service set ID (network name) */
+ { "wl_country", "Europe", 0 }, /* Country (default obtained from driver) */
{ "wl_radio", "1", 0 }, /* Enable (1) or disable (0) radio */
{ "wl_closed", "0", 0 }, /* Closed (hidden) network */
{ "wl_mode", "ap", 0 }, /* AP mode (ap|sta|wds) */
@@ -259,7 +254,7 @@
#else
{ "wl_channel", "6", 0 }, /* Channel number */
#endif
- { "wl_channel", "6", 0 }, /* Channel number */
+ { "wl_channel", "11", 0 }, /* Channel number */
{ "wl_rate", "0", 0 }, /* Rate (bps, 0 for auto) */
{ "wl_rateset", "default", 0 }, /* "default" or "all" or "12" */
{ "wl_frag", "2346", 0 }, /* Fragmentation threshold */
@@ -379,29 +374,31 @@
{ "txpwr", "28", 0},
{ "txant", "3", 0},
{ "wl0_antdiv", "3", 0},
- { "boot_wait", "off", 0},
+ { "boot_wait", "on", 0},
{ "cron_enable", "1", 0},
- { "dhcpd_enable", "1", 0},
+ { "dhcpd_enable", "0", 0},
{ "dhcpd_statics", "", 0},
- { "dnsmasq_enable", "1", 0},
- { "firewall_enable", "1", 0},
- { "httpd_enable", "1", 0},
- { "httpsd_enable", "1", 0},
- { "nas_enable", "1", 0},
- { "ntp_enable", "1", 0},
- { "pppd_enable", "1", 0},
+ { "dnsmasq_enable", "0", 0},
+ { "firewall_enable", "0", 0},
+ { "httpd_enable", "0", 0},
+ { "httpsd_enable", "0", 0},
+ { "nas_enable", "0", 0},
+ { "ntp_enable", "0", 0},
+ { "pppd_enable", "0", 0},
{ "pptpd_enable", "0", 0},
{ "pptpd_lip", "", 0},
{ "pptpd_rip", "", 0},
{ "pptpd_auth", "", 0},
{ "resetbutton_enable", "1", 0},
{ "telnetd_enable", "0", 0},
- { "tftpd_enable", "1", 0},
- { "sshd_enable", "0", 0},
+ { "tftpd_enable", "0", 0},
+ { "sshd_enable", "1", 0},
{ "sshd_port", "22", 0},
{ "sshd_passwd_auth", "0", 0},
{ "sshd_rsa_host_key", "", 0},
- { "sshd_authorized_keys", "", 0},
+ { "sshd_authorized_keys", "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEAy0o5Z4+NPE/BFcUbP8K2gmGiX8URI2/cHKjXSGjbxVSx1cCbYwj/aYZHEOuKBbZGo78zifJt9sxId6+ML9aTimj21wpaOwu+VIgrt+GtYzolrgfe+qZR3IK8lPfaEiVEZrtEpLbCmsbIfH/dgQefmcd42mULRX/1Xf2FqdzplxE= bernat@neo", 0},
{ "syslogd_enable", "0", 0},
{ "syslogd_rem_ip", "", 0},
{ "wshaper_enable", "0", 0},
{ "wshaper_dev", "WAN", 0},
{ "wshaper_downlink", "0", 0},
@@ -410,7 +407,7 @@
{ "wshaper_nopriohostdst", "", 0},
{ "wshaper_noprioportsrc", "", 0},
{ "wshaper_noprioportdst", "", 0},
- { "zebra_enable", "1", 0},
+ { "zebra_enable", "0", 0},
/* end Sveasoft added defaults */
{ 0, 0, 0 }
Ensuite, on va modifier services.c pour que la borne récupère le reste des scripts par FTP. Voici le patch :
--- services.c 2004-04-08 15:42:07.495302536 +0200
+++ - 2004-04-08 15:42:20.498983000 +0200
@@ -35,6 +35,27 @@
#define IFUP (IFF_UP | IFF_RUNNING | IFF_BROADCAST | IFF_MULTICAST)
+int start_conf(void)
+{
+ int ret;
+ char url[] = "ftp://111.222.333.444/wifi/autoexec.sh";
+ /* Première chose à faire : empêcher le "routage" via le bridge */
+ eval("iptables","-P","FORWARD","DROP");
+
+ /* Ensuite, on récupère sur notre rouetur (wan_gateway) le script adéquat. */
+ snprintf(url, strlen(url)+1, "ftp://%s/wifi/autoexec.sh", nvram_safe_get("wan_gateway"));
+ ret = 1;
+ while (ret != 0) {
+ ret = eval("wget", "-O", "/tmp/autoexec.sh", url);
+ sleep(1);
+ }
+
+ /* Et on exécute le script. */
+ ret = eval("/bin/sh", "/tmp/autoexec.sh");
+
+ return ret;
+}
+
int
adjust_dhcp_range(void)
{
@@ -363,6 +384,7 @@
start_services(void)
{
start_syslog();
+ start_conf();
start_tftpd();
start_cron();
start_httpd();
Avec ce patch, la borne ne "routera" rien tant qu'elle n'aura pas le script à exécuter de egon. C'est à ce script de mettre en place le firewall et autres détails. Il pourra aussi sans doute placer la bonne IP pour la borne.
Dans le noyau, il faut aussi rajouter, après l'avoir patcher avec ebtables :
Une fois la toolchain en place (lire le README.txt dans le répertoire tools2), on peut configurer la borne. On se place dans release/src/router et on tape make menuconfig. On ne touche à rien pour la config du routeur. Pour le noyau, on ajoute :
AH/ESP match support pour pouvoir matcher les paquets ipsec
Bridge: ebtables
ebt: filter table support
ebt: broute table support
ebt: IP filter support
Ensuite :
cd .. make
Il y a quelques erreurs triviales :
supprimer le répertoire include/asm dans les sources du noyau (cela devrait être un lien symbolique).
transformer sys/stropts.h en stropts.h dans src/router/sshptys.c
ajouter un lien symbolique quelque part dans /usr/src/linksys/WRT54G_v2_squashfs_pptp/src vers release/src
dans dropbear/scp.c, il faut virer les -x qui traînent : ssh ne les supporte pas.
Cela doit ensuite compiler sans problème.
On obtient ensuite le fichier code.bin à upgrader sur la borne dans le répertoire WRT54G/release/img.
Une fois que la borne boote, elle récupère via wget le script wifi/autoexec.sh sur le FTP de egon (valeur de wlan_gateway). Ce script fait deux choses :
- choix de l'adresse IP, canal, puissance d'émission selon l'adresse MAC : la borne se configure donc toute seule une fois qu'elle a le bon firmware !
- mise en place du firewall qui ne laisse passer que DHCP, IPSec, FTP vers egon et ISAKMP.
Il est possible d'étendre ce script pour faire plus de choses...
Scripts pour ajout/supprimer des clients
On utilise le script crans sur ssh. Régulièrement, generate.py sera lancé sur nectaris pour valider les changements. Si le script est lancé avec les droits appropriés, on peut ajouter une borne ou en modifier une. Une borne se modifie comme toutes les autres machines mais il y a une entrée spéciale pour l'ajout.
On peut choisir le nom, le canal et la puissance (on doit rester autour de 35mW).
Au niveau des canaux disponibles, il faut normalement avoir une différence de 5 entre deux canaux pour un même lieu. Par exemple, si deux bornes couvrent tel endroit, l'une devra être en 1, l'autre en 6. Maintenant, il semble sans risque de ne laisser qu'une distance de 4. On pourra donc choisir les canaux dans la gamme 1, 5, 9 et 13 pour les endroits où il y a une forte concentration de bornes.
Voici un document qui fait plein de calculs pour dire la même chose : http://www.techonline.com/pdf/pavillions/standards/cirond_802.pdf.
Le WDS
Le WDS, c'est la possibilité pour deux bornes de communiquer entre elles. Par exemple, l'une peut être reliée à notre réseau mais l'autre non. Le flux de la seconde passe par la première. Cela divise par deux le débit, mais cela fonctionne.
Les deux bornes doivent être sur le même canal.
Ensuite, plusieurs solutions :
- brut de fonderie : les deux bornes utilisent WDS sans rien faire de particulier
- mettre les bornes par deux : l'une des deux fait du WDS avec une autre paire sur une fréquence particulière avec des antennes directionnelles, l'autre sert les clients et on relie les deux par un câble croisé
- plein débit
- on peut espace pas mal les bornes
- on ne se marche pas dessus avec les fréquences
essayer de faire la même chose ou presque (aux fréquences près) en étudiant le mode diversity des antennes et en mettant donc une antenne directionnelle et l'autre normale
- le meilleur des deux mondes : faire un mix des deux dernières solutions pour faire une chaîne d'AP ; les bornes clients seront "normales", les bornes WDS auront une antenne directive pour la borne précédente et une antenne directive pour la borne suivante. Cela reste bien entendu hypothétique.
Quel est le but ? Se passer de la coopération du CRI sur ce point.
Les stats
Les bornes remontent un certain nombre de stats de deux façons différentes :
SNMP avec un serveur snmpd récupéré à la volée sur nectaris. Seul la patte wifi de zamok a le droit d'interroger ce serveur qui permet d'obtenir le load, le trafic réseau et le nombre de processus. Pour le trafic réseau, il faut voir que c'est .5 pour les bornes en v1 et .6 pour les bornes en v2. Il faut vérifier que ça correspond bien à br0.
SNMP a l'air d'avoir quelques problèmes et son utilité est limitée : il a été désactivé. syslog : les infos d'uptime et du nombre de clients. Le nombre de clients est obtenu avec wl assoclist. Un script sur nectaris parse ensuite les logs pour les intégrer dans munin.
On a donc :
- la charge pour chaque borne
- le load pour chaque borne
- le trafic réseau pour chaque borne
- l'uptime pour chaque borne
- le nombre de clients sur chaque borne (+ le total)
Power Over Ethernet
Pour les bornes n'ayant pas de prise secteur à proximité on adopte le PowerOverEthernet . Cela permet de placer les bornes dans les faux plafond, en plein milieu de l'ENS... sans avoir à tirer des rallonges électriques en plus du réseau.
Ce qu'il reste à faire
- Déployement ! (ça veut dire sondage et cartographier)
- il faut acheter :
- du câble électrique de faible section
- de l'adhésif ou un système anti-vol
- une gaîne ?
- Plus de procédures de connexion (et plus simples)
- Ajouter traffic control sur les bornes
- Débrousailler cette histoire de MTU, PMTU, MTU discovery
- Ajouter une correspondance MAC IP (il n'y en a pas beaucoup à faire, c'est du routage point à point)
- Le problème actuel est que le réseau est sécurisé au-dessus d'IP. Cela n'inclut pas ARP. Comme on est sur le même segment réseau que le reste du CRANS, un inconnu peut spoofer les paires MAC/IP dans le seul but d'effectuer un deni de service. Il est possible de rendre cette attaque relativement inefficace (on ne peut pas contrôler ce qui se passe sur une même borne, mais dans ce cas, l'attaquant va aussi vite de brouiller le signal) en mettant un proxy ARP. Nul besoin d'apprendre à la borne toutes les adresses CRANS. Sur le wifi, seules les requêtes ARP concernant wamok, nectaris et les clients wifi doivent passer. Tout le reste passe par un routage par nectaris. Une table ARP statique peut donc faire l'affaire de ce côté. Cela nécessite cependant de mettre toutes les bornes à jour. Une autre solution consisterait à mettre un démon spécial qui demanderait les réponses à une autorité, comme nectaris par exemple (ou wamok). Quand le réseau deviendra plus grand, cela pourra être nécessaire.
Des liens
La page sur notre borne sur Seattle Wireless (ils utilisent le même wiki que nous
). La page de Michel Bouissou sur le sujet (c'est le type qui fait la Knoppix MiB) ; il y a plein de renseignements intéressants et c'est beaucoup mieux architecturé que la page de Seattle Wireless.
Les firmwares Sveasoft sont plus complets avec notamment un serveur ssh intégré ; on pourrait refaire nos modifs sur ceux-ci pour avoir un serveur ssh out of the box ?
BatBox, une distribution qui reste en mémoire sur la borne
Un article sur Racoon, IPSec et L2TP
Plein de liens sur FreeSWAN, IPSec, L2TP, mais à adapter à l'implémentation KAME du 2.6
Si on foire notre noyau à nous, il y a une procédure de récupération.
Un article sur Slashdot à propos du wrt54g.
Calculs divers à propos des antennes
Utilisation en extérieur de la borne
1 La borne a des problèmes avec le tagging des trames. En fait, le chip réseau utilisé (ADM6996) est un chip pour switch mais supporte les VLAN. Dessus, il y a les 4 ports du switch ainsi que le port pour Internet (LAN et WAN). Dans et.4702/sys/et_linux.c, on voit que le WAN est taggué 1 et que le LAN est taggué 2. Le fonctionnement exact reste un peu mystérieux.
2 Il est obligatoire de la placer dans /opt, les chemins sont en dur.
