j'ai 11 AP Wifi à préconfigurer pour une utilisation "nomade" à court
terme des différents AP qui, à terme, devraient être mis en place en fixe.
Le but est ici de pouvoir couvrir au besoin différentes surfaces avec
une configuration "cliente" la plus basique du monde (=> moins on en
fait...).
Je me demande tout simplement le paramétrage que je dois adopter sur ces
AP en terme de wifi.
Canaux : tous sur le même canal ou répartition sur les canaux autorisés
? J'ai cru comprendre qu'en mettant des canaux différents, on peut avoir
un recouvrement des cellules -> faire jouer le roaming pour quand on se
déplace d'une cellule à l'autre.
ESSID : tous le même ou chaque AP doit avoir son propre ESSID ?
J'imagine que c'est le même pour tous si on veut ne pas changer de
"réseau" toutes les 20 secondes.
Si quelqu'un peut me confirmer tout ça...
J'ai pas trouvé de doc de référence sur cette problématique de
déploiement d'AP.
C'est bon à savoir/confirmer. Donc si certains clients sont vieux, y'a bien un intérêt à éviter les canaux proches quand même, non ? Non, j'ai travaillé sur le WiFi (et sur le 802.11 en 1997) à un niveau
fin dès avril 2002 et qu'il s'agisse de Linux, de FreeBSD ou de Windows WP j'ai rarement rencontré des clients << collants >>. C'est arrivé bien entendu mais c'était rare. La stratégie commune adoptée par les vendeurs est de s'associer avec l'AP dont le niveau de réception est le plus elevé et ce, depuis le début. Bien entendu lorsqu'on a la maîtrise du firmware (MadWifi et, à un moindre degré, HostAP ainsi que le pilote générique sous MacOS/X) on peut définir d'autres stratégie (coller au précédent AP, définir, comme dans le GSM, un CO, mesurer en permanence le niveau des autres AP environants et estimer la probabilité de se rapprocher de tel ou tel AP, tout cela pour minimiser la durée du handover). Les << grands >> constructeurs (Cisco, Symbol, Aruba) adoptent de telles stratégies, à condition d'avoir un tel matériel partout.
[...]
Là, je comprends pas bien la phrase. Le ESSID, c'est sur les AP qu'on le configure Euh, on le configure bien côté client non que ce dernier le découvre
automatiquement (via les trames beacon) ou non.
(en fait, ici, le terme "nomades" que j'avais utilisé, c'était
pour les AP qui vont être mobiles au début du déploiement) => tu me confirmes qu'il faut que je colle les 11 AP dans le même ESSID ? Comme tu le sens. Dans le cadre d'un accès public c'est préférable ,
le contraire ferait plutôt fuir les clients mais dans un cadre privé tu peux très bien définir des zones d'accès différentes. Encore une chose : l'idée selon laquelle ne pas diffuser le xSSID est un plus sécuritaire est fausse. Les stations émettent également le SSID auquel elles sont << accrochées >>.
Réfléchis un peu : si chaque AP dispose d'un ESSID différent que se passe-t-il côté utilisateur ?
Bah dis donc, apparemment, il faut pas trop te titiller... Disons que je suis plutôt partisant du << Aide-toi le Ciel t'aidera >>.
On se prend des "réfléchis un peu" alors qu'il me semble que je n'avais pas posé des questions si débiles que ça vu que j'ai obtenu des réponses parfois diagonalement opposées (pas que sur ce newsgroup). Le déploiement de 11 bornes dans un même espace n'est pas le cas le + courant qu'on rencontre il me semble. En fait c'est très courant (dès qu'on déploie une infrastructure
sans-fil dans une entreprise on arrive vite à 10 AP ainsi que lorsqu'on déploie des hotspots en aéroport, gare, etc) mais ceux ou celles qui réalisent ces déploiements n'en parlent pas forcément dans les news.
Par ailleurs, rapporté au nombre d'AP vendu, il n'est pas forcément évident que la majorité (toutes marques confondues) soit commercialisée sur les marchés grand public.
C'est en tout cas suffisamment peu fréquent pour qu'il y ait peu de doc de référence sur le sujet. J'ai pas vraiment le temps de m'y amuser, mais l'expérience serait intéressante pour être fixé sur la question (est-ce que le client ferait des sauts d'AP en AP sans arrêt tant qu'il a un signal correct sur une borne et le changement d'ESSID serait-il si perturbant que ça en terme de "reconnexion" sur le prochain AP dispo ?).
Il y a des documents sur le handover rédigés par des chercheurs ou quelques rares entreprises. Ces documents datent un peu en général (2000-2003). Ce qu'il faut retenir c'est que le handover (l'itinérance microscopique) n'est pas pénalisant (il dure au pire 0,1 s) dans le cas général. En revanche, il le devient dans le cadre de la fourniture de services évolués comme l'audio et la video. En effet, se prendre 0,1s de délai toutes les secondes sur un flux HTML passe inaperçu. Se prendre les mêmes délais dans un flux audio non tamponné ...
C'est la raison pour laquelle il existe des stratégies élaborées visant à réduire la durée du handover par des règles de prévision, d'écoute permanente des autres AP. Réduire le nombre de << différences >> de configuration entre les AP ne réduit pas, A PRIORI, le délai de handover. La décision de << basculer
se déroule en arrière-plan. Toutefois, cela s'est en théorie, car, pratiquement, si le combiné
firmware/pilote est mal conçu (*) on peut observer des comportements différents selon les différences. Ce qui ne devrait pas être.
db
(*) Et je prie de croire qu'il y a vraiment des firmwares pourris dans ce domaine (cf. DLink).
--
Courriel : usenet blas net
[...]
C'est bon à savoir/confirmer. Donc si certains clients sont vieux, y'a
bien un intérêt à éviter les canaux proches quand même, non ?
Non, j'ai travaillé sur le WiFi (et sur le 802.11 en 1997) à un niveau
fin dès avril 2002 et qu'il s'agisse de Linux, de FreeBSD ou de Windows
WP j'ai rarement rencontré des clients << collants >>. C'est arrivé bien
entendu mais c'était rare.
La stratégie commune adoptée par les vendeurs est de s'associer avec
l'AP dont le niveau de réception est le plus elevé et ce, depuis le début.
Bien entendu lorsqu'on a la maîtrise du firmware (MadWifi et, à un
moindre degré, HostAP ainsi que le pilote générique sous MacOS/X) on
peut définir d'autres stratégie (coller au précédent AP, définir, comme
dans le GSM, un CO, mesurer en permanence le niveau des autres AP
environants et estimer la probabilité de se rapprocher de tel ou tel AP,
tout cela pour minimiser la durée du handover). Les << grands >>
constructeurs (Cisco, Symbol, Aruba) adoptent de telles stratégies, à
condition d'avoir un tel matériel partout.
[...]
Là, je comprends pas bien la phrase. Le ESSID, c'est sur les AP qu'on le
configure
Euh, on le configure bien côté client non que ce dernier le découvre
automatiquement (via les trames beacon) ou non.
(en fait, ici, le terme "nomades" que j'avais utilisé, c'était
pour les AP qui vont être mobiles au début du déploiement) => tu me
confirmes qu'il faut que je colle les 11 AP dans le même ESSID ?
Comme tu le sens. Dans le cadre d'un accès public c'est préférable ,
le contraire ferait plutôt fuir les clients mais dans un cadre privé tu peux
très bien définir des zones d'accès différentes.
Encore une chose : l'idée selon laquelle ne pas diffuser le xSSID est un
plus sécuritaire est fausse.
Les stations émettent également le SSID auquel elles sont << accrochées >>.
Réfléchis un peu : si chaque AP dispose d'un ESSID différent que se
passe-t-il côté utilisateur ?
Bah dis donc, apparemment, il faut pas trop te titiller...
Disons que je suis plutôt partisant du << Aide-toi le Ciel t'aidera >>.
On se prend
des "réfléchis un peu" alors qu'il me semble que je n'avais pas posé des
questions si débiles que ça vu que j'ai obtenu des réponses parfois
diagonalement opposées (pas que sur ce newsgroup). Le déploiement de 11
bornes dans un même espace n'est pas le cas le + courant qu'on rencontre
il me semble.
En fait c'est très courant (dès qu'on déploie une infrastructure
sans-fil dans une entreprise on arrive vite à 10 AP ainsi que lorsqu'on
déploie des hotspots en aéroport, gare, etc) mais ceux ou celles qui
réalisent ces déploiements n'en parlent pas forcément dans les news.
Par ailleurs, rapporté au nombre d'AP vendu, il n'est pas forcément
évident que la majorité (toutes marques confondues) soit commercialisée
sur les marchés grand public.
C'est en tout cas suffisamment peu fréquent pour qu'il y
ait peu de doc de référence sur le sujet.
J'ai pas vraiment le temps de m'y amuser, mais l'expérience serait
intéressante pour être fixé sur la question (est-ce que le client ferait
des sauts d'AP en AP sans arrêt tant qu'il a un signal correct sur une
borne et le changement d'ESSID serait-il si perturbant que ça en terme
de "reconnexion" sur le prochain AP dispo ?).
Il y a des documents sur le handover rédigés par des chercheurs ou
quelques rares entreprises. Ces documents datent un peu en général
(2000-2003).
Ce qu'il faut retenir c'est que le handover (l'itinérance microscopique)
n'est pas pénalisant (il dure au pire 0,1 s) dans le cas général.
En revanche, il le devient dans le cadre de la fourniture de services
évolués comme l'audio et la video. En effet, se prendre 0,1s de délai
toutes les secondes sur un flux HTML passe inaperçu. Se prendre les
mêmes délais dans un flux audio non tamponné ...
C'est la raison pour laquelle il existe des stratégies élaborées visant
à réduire la durée du handover par des règles de prévision, d'écoute
permanente des autres AP.
Réduire le nombre de << différences >> de configuration entre les AP ne
réduit pas, A PRIORI, le délai de handover. La décision de << basculer
se déroule en arrière-plan.
Toutefois, cela s'est en théorie, car, pratiquement, si le combiné
firmware/pilote est mal conçu (*) on peut observer des comportements
différents selon les différences. Ce qui ne devrait pas être.
db
(*) Et je prie de croire qu'il y a vraiment des firmwares pourris dans
ce domaine (cf. DLink).
C'est bon à savoir/confirmer. Donc si certains clients sont vieux, y'a bien un intérêt à éviter les canaux proches quand même, non ? Non, j'ai travaillé sur le WiFi (et sur le 802.11 en 1997) à un niveau
fin dès avril 2002 et qu'il s'agisse de Linux, de FreeBSD ou de Windows WP j'ai rarement rencontré des clients << collants >>. C'est arrivé bien entendu mais c'était rare. La stratégie commune adoptée par les vendeurs est de s'associer avec l'AP dont le niveau de réception est le plus elevé et ce, depuis le début. Bien entendu lorsqu'on a la maîtrise du firmware (MadWifi et, à un moindre degré, HostAP ainsi que le pilote générique sous MacOS/X) on peut définir d'autres stratégie (coller au précédent AP, définir, comme dans le GSM, un CO, mesurer en permanence le niveau des autres AP environants et estimer la probabilité de se rapprocher de tel ou tel AP, tout cela pour minimiser la durée du handover). Les << grands >> constructeurs (Cisco, Symbol, Aruba) adoptent de telles stratégies, à condition d'avoir un tel matériel partout.
[...]
Là, je comprends pas bien la phrase. Le ESSID, c'est sur les AP qu'on le configure Euh, on le configure bien côté client non que ce dernier le découvre
automatiquement (via les trames beacon) ou non.
(en fait, ici, le terme "nomades" que j'avais utilisé, c'était
pour les AP qui vont être mobiles au début du déploiement) => tu me confirmes qu'il faut que je colle les 11 AP dans le même ESSID ? Comme tu le sens. Dans le cadre d'un accès public c'est préférable ,
le contraire ferait plutôt fuir les clients mais dans un cadre privé tu peux très bien définir des zones d'accès différentes. Encore une chose : l'idée selon laquelle ne pas diffuser le xSSID est un plus sécuritaire est fausse. Les stations émettent également le SSID auquel elles sont << accrochées >>.
Réfléchis un peu : si chaque AP dispose d'un ESSID différent que se passe-t-il côté utilisateur ?
Bah dis donc, apparemment, il faut pas trop te titiller... Disons que je suis plutôt partisant du << Aide-toi le Ciel t'aidera >>.
On se prend des "réfléchis un peu" alors qu'il me semble que je n'avais pas posé des questions si débiles que ça vu que j'ai obtenu des réponses parfois diagonalement opposées (pas que sur ce newsgroup). Le déploiement de 11 bornes dans un même espace n'est pas le cas le + courant qu'on rencontre il me semble. En fait c'est très courant (dès qu'on déploie une infrastructure
sans-fil dans une entreprise on arrive vite à 10 AP ainsi que lorsqu'on déploie des hotspots en aéroport, gare, etc) mais ceux ou celles qui réalisent ces déploiements n'en parlent pas forcément dans les news.
Par ailleurs, rapporté au nombre d'AP vendu, il n'est pas forcément évident que la majorité (toutes marques confondues) soit commercialisée sur les marchés grand public.
C'est en tout cas suffisamment peu fréquent pour qu'il y ait peu de doc de référence sur le sujet. J'ai pas vraiment le temps de m'y amuser, mais l'expérience serait intéressante pour être fixé sur la question (est-ce que le client ferait des sauts d'AP en AP sans arrêt tant qu'il a un signal correct sur une borne et le changement d'ESSID serait-il si perturbant que ça en terme de "reconnexion" sur le prochain AP dispo ?).
Il y a des documents sur le handover rédigés par des chercheurs ou quelques rares entreprises. Ces documents datent un peu en général (2000-2003). Ce qu'il faut retenir c'est que le handover (l'itinérance microscopique) n'est pas pénalisant (il dure au pire 0,1 s) dans le cas général. En revanche, il le devient dans le cadre de la fourniture de services évolués comme l'audio et la video. En effet, se prendre 0,1s de délai toutes les secondes sur un flux HTML passe inaperçu. Se prendre les mêmes délais dans un flux audio non tamponné ...
C'est la raison pour laquelle il existe des stratégies élaborées visant à réduire la durée du handover par des règles de prévision, d'écoute permanente des autres AP. Réduire le nombre de << différences >> de configuration entre les AP ne réduit pas, A PRIORI, le délai de handover. La décision de << basculer
se déroule en arrière-plan. Toutefois, cela s'est en théorie, car, pratiquement, si le combiné
firmware/pilote est mal conçu (*) on peut observer des comportements différents selon les différences. Ce qui ne devrait pas être.
db
(*) Et je prie de croire qu'il y a vraiment des firmwares pourris dans ce domaine (cf. DLink).
