[gull] Drivers 802.11g

Leopoldo Ghielmetti Leopoldo.Ghielmetti at a3.epfl.ch
Thu Aug 14 09:23:02 CEST 2003


On Tue, 2003-08-12 at 11:34, Martial Guex wrote:
> On Tuesday 12 August 2003 04:21, FLUO wrote:
> > ----- Original Message -----
> > Il semble que ce soit plutôt pour la carte wireless a, a/b, a/b/g
> 
> Comprend pas la remarque !
> 
> > Sont-elles achetables en Suisse?
> 
> Il faut voir chez:
> 
> http://www.comattack.ch
> 
> Je pense qu'il faut attendre quelques mois car il ne doit pas avoir beaucoup 
> homologuée par l'OFCOM actuellement.
> 
> > La théorie de la protection par l'obscure semble fonctionner. La grande
> > raison mise en avant est que vu que les fréquences sont contrôlables au
> > niveau logiciel, ils seraient possibles d'aller sur d'autres fréquences
> > dont celles de la grande muette et serait incompatible avec les volontés
> > de la FCC (The Federal Communications Commission (FCC) is an independent
> > US government agency: n'étant ni américain,ni résident aux USA, je ne
> > vois pas pourquoi je devrais me sentir concerné par ce que veut cette
> > agence.). Mais un logiciel closed-source pourrait tout autant réussir
> > cela.
> 
> Il ne faut pas faire de l'anti US primaire. L'homologation d'un produits ne 
> concerne pas uniquement les fréquences mais également la puissance d'émission 
> que ce soit dans le canal central ou celles des canaux contigus. Des 
> contraintes sont nécessaires pour que tous les produits utilisant des ondes 
> radios puissent travailler ensembles. De plus il faut bien avoir une identité 
> qui prend sur elle l'homologation et qui va prendre sur elle la 
> responsabilité juridique si leur produit permet de contourner la norme.
> Si l'on veux bidouillé avec de ondes radio il faut faire un brevet de radio 
> amateur et ensuite on a des plages de fréquences permettant une plus grande 
> liberté mais les contraintes sont toujours là.
> Comme on dît la liberté des uns commence ou celle des autres finissent.

Et qui empêche de modifier le firmware binaire (p.e. avec un
décompilateur) pour lui faire faire ce qu' on veut?
ou l'analiser pour en écrire un autre?

La protection par l'obscurité ne marche pas, il suffit que quelqu'un ait
la lampe pour eclaircir le problème.

Ce qu'ils doivent faire c'est coder les fréquences d'émission sur des
valeurs discrètes (p.e. 1, 2, 3, 4) ensuite faire un driveur open. A ce
moment la seule chose qu'on peut faire depuis le driveur sera de choisir
la valeur discrète corréspondante à la fréquence à utiliser, mais pas
moyen de changer la fréquence.

> > Le fait que des fabricants sortent des produits basés sur le brouillon
> > de la norme 802.11g ne gène pas grand monde.
> 
> Je pense que les produits qui sortes on la possibilité de suivre les 
> évolutions future de la norme par mise à jour de leur firmware.
> 
> >
> > Le HAL (Hardware Access Layer ) n'est pas exempt de bug, mais on ne peut
> > pas vérifier. La compilation du binaire pour ta plateforme est au bon
> > vouloir de l'auteur. S'il venait à arrêter le projet, à devenir
> > amnésique ou  à décéder, on se retrouve avec une version figée.
> 
> Une alternative serai d'avoir une partie du firmware ne pouvant être chargé 
> que depuis un binaire préparé par le constructeur mais avec les source en 
> open et une autre partie totalement en libre. Le risque c'est que quelqu'un 
> découvre la méthode que le constructeur utilise pour préparer le firmware qui 
> est sous la responsabilité du constructeur. Ce qui arrivera probablement 
> (comme le cryptage de zone pour les DVD).
> Personnellement je préfaire avoir un firmware d'une bonne boîte prenant sur 
> elle toute la partie homologation et juridique en cas de problème.

Oui, si le firmware est codé en dur sur une ROM. Si le firmware est à
charger dans le système je ne suis pas d'accord, car à ce moment la le
discours d'avant s'applique à nouveau.

> > Je ne suis pas certain que le reste du pilote puisse être GPL s'il est
> > linké sur un objet closed-source.
> >
> > Le noyau est teinté.
> 
> Il est tout à fait possible pour un constructeur de faire un module en open 
> qui charge dynamiquement un binaire. C'est par exemple la méthode qui est 
> utilisée par AVM pour le driver de ces carte ISDN et ADSL (Fritz, C2, C4 etc)

Bien sur, mais comme je disait avant, qui va empêcher la décompilation
ou la reécriture d'un nouveau driveur?
Seul la solution ROM est envisageable si on veut un code propriétaire,
ou sinon le système Palladium de MS, car comme ça plus moyen de modifier
quoi que ce soit.

Mais je crois qu'il est inutile de dire que je préfère la solution open
à toute autre.

> > Cela montre le mauvais exemple aux autres constructeurs.
> 
> Je pense que les constructeurs n'ont pas trop le choix si ils veulent 
> homologuer leurs produits et garder la possibilité de faire évoluer le 
> firmware. Par ailleur c'est logique que les autorités n'aillent qu'un seul 
> responsable pour un produit donné.
> 
> Par ailleur je signale que les autorités exige que les constructeurs offre un 
> méthode afin d'identifier le produits émettant des ondes hertziennes en 
> digital, ceci afin de permettre de contrôle du respect de la norme par le 
> constructeurs.
> 
> Pour plus d'info, voir le site de l'OFCOM (http://www.bakom.ch/fr/)
> 
> A+
> Martial Guex

Tous ces discours ne servent qu'a justifier des systèmes de contrôle à
la Palladium, et c'est surement un des points à faveur de ce système "vu
qu'à l'état actuel on ne peut pas garantir que le code ne soit pas
modifié, on Palladiumize les logiciels comme ça on est sur qu'ils ne
seront pas modifiés".

Belle solution!

ciao, Leo





More information about the gull mailing list