OVH Cloud OVH Cloud

quelle carte PCI WIFI pour creer un AP !!

39 réponses
Avatar
Bidibul
Bonjour

ma petite question ce trouve dans l'objet de ce message
si qqun pouvait me donner une marque et model

un grand merci d'avance

10 réponses

1 2 3 4
Avatar
David
"Dominique Blas" a écrit dans le message de news:
425d03d7$0$6572$

Mouais. Ca ne prouve pas grand chose. Combien disposent d'un Linux en
tant que serveur mais n'ont pas franchi le pas en ce qui concerne le
poste de travail ?


Vi enfin je reconnais suivant la qualité des posts sur Usenet [pas forcément
la syntaxe et l'orthographe, hein!] le niveau informatique de mes
interlocuteurs, surtout sur un forum technique. Le classique: je me demande
comment monter une AP à partir du seul Windows est courant;-)

Mais je te l'accorde, la probabilité d'avoir Outlook Express et Linux
(ou xBSD) dans un même environnement est plutôt faible, le couple
Mozilla (Thunderbird) - OS libre est plus courant.
Ceci dit, cela ne constitue pas une preuve mais une bonne présomption.
Le gars vient peut-être juste d'aquérir un Mac :-)


Ou ressortir son vieil Atari:p) Ptain qu'est-ce que je pourrais bien en
faire? Mais une AP of course;-)

J'ai répondu avec du Linux par réflexe. Non pas que j'ignore windows
mais autant il est incontournable en tant que serveur applicatif autant
en tant qu'élément d'infrastructure ... bof (*).


Certains veulent tout faire avec leur seule machine pour différentes
raisons.

En effet, j'imagine mal un AP sous la forme d'un minitour. Pour moi (et
ça n'engage que moi) un AP c'est plutôt de l'embarqué qui plus est sans
licence supplémenataire qui vient en gréver le prix (**).


Il est encore moins cher de monter un softAP sur son PC fixe sous XP qui
partage la connexion Internet pour un ou deux portables familiaux... C'est
tout de même la typologie d'utilisateurs la plus facilement rencontrée ici
et là.

Et franchement, Windows et embarqué ça dissonne un peu non ? Ca fait
sourire.
Je vois mal un Soekris avec 1Go de Flash et 256 Mo de MEV surtout
qu'avec un 486 le XP on risque de ne jamais le voir booter :-)
Et je ne parle pas des ARM.


T'es mauvaise langue;-), AMDMicrosoft va sortir l'ordinateur du pauvre à 150
euros:

http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_9883^9888,00.html

dont le processeur fait la chasse à la copie...

Mais je reconnais qu'il existe un marché pour l'AP de type Windows. Un
marché de riches à n'en pas douter.


Tu y tiens à ton dédié:-)

Et je te remercie vivement (je ne plaisante pas) d'avoir éclairé ma
lanterne ainsi que celle de tous ceux qui transitent par ici sur les
possibilités de fabriquer un AP (un vrai moniteur IBSS) sous Windows.


C'est parfait pour du grand public, qui n'a pas envie de racheter du
matériel supplémentaire ou qui ne saurait se débrouiller avec un montage sur
une vieille bécane.

Au fait, la licence XP est à combien déjà ? 150 euros HT ?


Tu dois te faire arnaquer par ton fournisseur;-)

Quoi qu'il en soit cela ne vaut pas un flame ni des engueulades, n'est ce
pas ?


Vi on va baisser le ton en dB;-)

(*) Mirosoft rêve probablmenet ne secret de remplacer tous les IOS par un
XP/2003 et d'implanter son OS favori (Longhorn ?) dans chaque switch du
marché.


Hem, hem je vois que tu ne suis pas les loups actuel... L'enjeu est
désormais sur la mobilité et Microsoft met le paquet sur les windows mobile
2003 pour revenir en thème sur le sans-fil...

(**) Un AP de base (transducteur filaire - sans-fil) c'est 50 euros HT
voire moins.


Vi un Wrt54G se trouve à ces prix là en HT.

Bien entendu si on veut faire dans le sophistiqué on peut acheter du
Cisco, de l'Aruba, de l'Avaya, du Symbol et on tape alors
systématiquement au-delà des 600 euros HT. Mais pour ce prix on a bien
d'autres fonctionnalités accessibles qu'avec un SoftAP auquel il faudra
ajouter d'autres softs (s'ils existent) pour faire du IIOP, du 802.1x, du
pontage 802.1, de la gestion de QoS, du réglage dynamique de niveau
d'émission, etc.


Bon là tu confonds les fonctions d'AP et de routage, qui dans XP sont
élaborées, pour qui sait les configurer. Tu bénéficies tout de même de
toutes fonctionnalités apportées par l'OS en dehors de l'add-on qu'est
SoftAP. Et je te prie de croire que configurer du Microsoft est tout à fait
loin d'être simple dès lors qu'on sort des sentiers battus: serveur radius,
QOS, pontage... SoftAP n'est qu'une couche. Mais comparer des OS/ machines
dédiées avec des machines/ OS multifonctions n'est pas une bonne idée!
N'est-ce pas;-)

Avatar
Dominique ROUSSEAU
En effet, j'imagine mal un AP sous la forme d'un minitour. Pour moi
(et ça n'engage que moi) un AP c'est plutôt de l'embarqué qui plus
est sans licence supplémenataire qui vient en gréver le prix (**).


Il est encore moins cher de monter un softAP sur son PC fixe sous XP
qui partage la connexion Internet pour un ou deux portables
familiaux... C'est tout de même la typologie d'utilisateurs la plus
facilement rencontrée ici et là.


Passer en mode ad-hoc et ne pas avoir besoin de SoftAP (ou autre), ça va
meme couter encore moins cher, et marcher tout aussi bien pour le besoin
en question.
(et très peu de matériel non compatible)


Dom


Avatar
David
"Dominique ROUSSEAU" a écrit dans le message de news:


Passer en mode ad-hoc et ne pas avoir besoin de SoftAP (ou autre), ça va
meme couter encore moins cher, et marcher tout aussi bien pour le besoin
en question.
(et très peu de matériel non compatible)


Je suivrais ce point de vu si a posteriori, la liaison ad hoc était stable.
Comparativement le mode AP est nettement plus robuste... En cas de perte de
signal, ça se reconnecte automatiquement, alors que j'ai mille fois observé
qu'en mode ad hoc c'était foutu sans manip manuelle:-( [malgré
l'automatisation des options kivonbien of course!]

En gros, si tu prends le contrôle à distance, genre VNC via une liaison ad
hoc, t'es souvent dans les choux:-(

Avatar
Thomas Clavier
David wrote:
En gros, si tu prends le contrôle à distance, genre VNC via une liaison ad
hoc, t'es souvent dans les choux:-(


as tu un exemple (matos + soft) de ce cas, en effet, pour le réseau
métropolitain de lille, nous n'utilisons que de l'ad-hoc, et nous
n'avons jamais rencontré ce point, or nous avons pas loing de 150
utilisateurs.

--
Thomas Clavier http://www.tcweb.org
Lille Sans Fil http://www.lillesansfil.org
+33 (0)6 20 81 81 30 JabberID :

Avatar
David
"Thomas Clavier" a écrit dans le message de news:
425e08f0$0$1953$

as tu un exemple (matos + soft) de ce cas, en effet, pour le réseau
métropolitain de lille, nous n'utilisons que de l'ad-hoc, et nous n'avons
jamais rencontré ce point, or nous avons pas loing de 150 utilisateurs.


T'es en OLSR ce qui n'est pas l'ad hoc traditionnel [OLSR prend en compte la
qualité de la liaison grâce à la méthode du Link Hysteresis]...

Avatar
Dominique ROUSSEAU
"Thomas Clavier" a écrit dans le message de news:
425e08f0$0$1953$

as tu un exemple (matos + soft) de ce cas, en effet, pour le réseau
métropolitain de lille, nous n'utilisons que de l'ad-hoc, et nous
n'avons jamais rencontré ce point, or nous avons pas loing de 150
utilisateurs.


T'es en OLSR ce qui n'est pas l'ad hoc traditionnel [OLSR prend en
compte la qualité de la liaison grâce à la méthode du Link
Hysteresis]...


OLSR, ça met juste à jour la table de routage, au niveau IP, donc au
_dessus_ de la couche 802.11*, sur laquelle il n'intervient pas.

Autour de moi, la plupart des gens que je connais utilisent le mode
ad-hoc, sans OLSR, et sans problèmes de "décrochage".


Dom


Avatar
Cedric Blancher
Le Thu, 14 Apr 2005 10:27:30 +0200, Dominique ROUSSEAU a écrit :
OLSR, ça met juste à jour la table de routage, au niveau IP, donc au
_dessus_ de la couche 802.11*, sur laquelle il n'intervient pas.


Nope.
OSLR intègre la _possibilité_ de fournir dans ses messages des
informations sur la qualité des liens qui seront prises en compte dans
la calcul de l'arbre couvrant. C'est une bonne chose dans la mesure où ce
protocole a quand même été défini principalement pour une utilisation
sur des MANET. Ces informations sont récupérées sur le système par
l'agent OSLR au niveau du driver (link layer) en plus des informations de
disponibilité effective du lien.

Cf.RFC 3626, section 14.

Si tu prends Unik OSLR par exemple, tu vas trouver dans le fichier de
configuration une directive UseHysteresis pour gérer ce type de choses.

Autour de moi, la plupart des gens que je connais utilisent le mode
ad-hoc, sans OLSR, et sans problèmes de "décrochage".


Idem. D'ailleurs, en cas de perte (je viens de tester), mes interfaces
remontent toutes seules, en infra comme en ad-hoc.


--
Une autre solution serait de créer un fr.comp.os.linux.blackhole. Si un
message y est posté, un robot recherche et flingue tout message dont le
contenu et le from seraient identiques.
-+- TP in Guide du Fmblien Assassin : "Flinguez les tous !!!" -+-

Avatar
David
"Cedric Blancher" a écrit dans le message de
news:

Idem. D'ailleurs, en cas de perte (je viens de tester), mes interfaces
remontent toutes seules, en infra comme en ad-hoc.


Salut Cédric;-)

Quel est ton parc de matériel en ad-hoc? En gros?

Avatar
Cedric Blancher
Le Thu, 14 Apr 2005 11:01:31 +0200, David a écrit :
Idem. D'ailleurs, en cas de perte (je viens de tester), mes interfaces
remontent toutes seules, en infra comme en ad-hoc.
Quel est ton parc de matériel en ad-hoc? En gros?



En gros, je viens de tester entre une Intel IPW2200 et une Dlink DWL650,
les deux sous GNU/Linux (drivers ipw2200 et hostap).


--
Je voudrais savoir s'il existe un compteur de vitesse (?) pour savoir
à quelle vitesse on est réellement connecté au FAI et surtout si une
telle bête existe... oû la trouver.
-+- RJ in: Guide du Neuneu d'Usenet - Baisse la tête et pédale -+-


Avatar
Dominique ROUSSEAU
Le Thu, 14 Apr 2005 10:27:30 +0200, Dominique ROUSSEAU a écrit :
OLSR, ça met juste à jour la table de routage, au niveau IP, donc au
_dessus_ de la couche 802.11*, sur laquelle il n'intervient pas.


Nope.
OSLR intègre la _possibilité_ de fournir dans ses messages des
informations sur la qualité des liens qui seront prises en compte dans
la calcul de l'arbre couvrant.


Certes, mais il n'évite pas que la couche physique "décroche" si elle doit
décrocher.

C'est une bonne chose dans la mesure où ce protocole a quand même été
défini principalement pour une utilisation sur des MANET. Ces
informations sont récupérées sur le système par l'agent OSLR au niveau
du driver (link layer) en plus des informations de disponibilité
effective du lien.


C'est surtout intéressant quand le maillage devient important et que le
nombre de chemins pour une destination donnée devient > 1.



Dom


1 2 3 4