En gros, la-bas, le système bancaire est un peu différent, et s'appuie en particulier sur le SSN (Social Security Number) comme numéro d'identifiant unique d'une personne. A la différence du notre, il s'utilise un peu à tord et a travers, et en particulier pour ouvrir des comptes bancaires, payer des factures, prendre des abonnements de gaz, ...
Bref, il est énormément manipulé par beaucoup de monde, et ne comporte que peu de chiffres (8 si je me souviens bien).
De plus, la bas il n'y a pas trop de "droit au découvert bancaire", mais plutôt un système de carte de crédit qui se comporte comme un prêt à la consomation, cad qu'il y a un taux d'intérêts (souvent entre 13 et 19%) sur l'utilisation, juqu'a hauteur de $1000 souvent. Ces cartes de crédits s'obtiennent quasi automatiquement à l'ouverture d'un compte bancaire.
La technique est donc simple: Quelqu'un récupère (très facilement, donc, sur un courrier, facture de gaz, téléphone, ou dans un fichier d'ordinateur) ton nom, prénom, SSN et addresse.
Muni de ces seules information, il va ouvrir un compte bancaire, il récupère une carte de crédit, et va immédiatement acheter tout ce qu'il veux, ou bien retirer du cash. Ensuite, il détruit la carte.
Quelques mois plus tard, en voyant le solde débiteur et le non approvisionnement du compte, la banque va frapper à ta porte, en te demandant de rembourser les somme + les intêrets accumulés (Et 15% par mois sur $1000 ca chiffre vite).
Le problème est que, en plus de cela, ton "credit history", cad une valeur globale qui représente ta capacité à rembourser tes crédits, va baisser. Et ca, c'est très gênant, un peu comme en france se faire classer "interdit bancaire", car c'est très difficile à faire annuler.
La seule solution est de porter plainte, et de prouver ta bonne foi aux banques et instituts de crédits, ce qui prend plusieurs mois.
Pendant ce temps la, plus de crédits, toutes les factures se payent en cash au guichet (les banques ne prennent plus ni chèques ni cartes), et tu recois tous les jourts des lettre de menace des sociétés de collection de fonds (qui elles ne sont pas au courant de la procédure)
Il n'est pas possible de changer de numéro SSN, ce qui fait que si le tiens se balade dans la nature, il se peux très bien que 2 mois après, rebelotte.
C'est très difficile de chopper les gens qui font ca, en général ca demande des flagrant délis, si par exemple ils utilisent la même carte plusieurs fois. Si il ne sont pas trop bêtes, ils ne le font pas, et là... C'est coup de bol.
Les banques pendant longtemps s'en foutaient royalement: Elles augmentais simplement leurs assurances en conséquence, et en répartissait le coût sur les clients.
Là les choses évoluent, parceque vu le nombre de cas, ca bouge au niveau fédéral pour obliger les banques à être plus sérieuses sur l'ouverture des comptes.
Voilà donc les "bienfaits" des numéros d'identification unique, voilà pourquoi la CNIL s'oppose fermement à ce genre de numéro. (pour ce qu'elle est écoutée...)
A mon avis, et comme le veux la légende, tous ce que fait l'amérique, 10ans plus tard ca arrive chez nous, alors...
Pourtant, là, on a la chance d'avoir en direct l'exemple de ce qu'il ne faut pas faire.
Est-ce qu'il ne serais pas suffisant, déjà, de prévenir l'acheteur potentiel que l'équippement a recours à la "tivoization" ?
Avec, par exemple, un sticker sur la boite et une mention sur les sites web genre:
"Attention: Ce matériel contient des protection logicelles et matériel qui sont concue pour vous empêcher d'exercer vos droits"
En anglais, ca donnerais:
"Warning: This equippment contains software and hardware protections that prevent it usage under the Fair Use Act."
Déjà, ca éviterais à tous les bidouilleurs d'acheter ces appareils.
Ensuite, ca serais suffisament négatif, je pense, pour que les gens qui ne s'y connaissent pas choisissent un appareil sans le sticker.
A la fin, soit Tivo re-négocie avec les société de production, soient ils meurent.
On pourrais coller la même chose sur les Livebox signées, aussi.
Cela dis, je pense vraiment qu'un jour ou l'autre, ils finiront tous par libérer leurs sources:
Rien que Linksys par exemple, à mon avis ils ont été (avec le recul) très contents de libérer les sources du routeur WRT-54G : Les geeks se sont jeté dessus comme des petits pains (alors meme qu'il y a des parties non libre dedans), des business se sont montées autour de ca,...
Lorsque il y en a un qui entend l'appel feutré de la liasse de billets, le soir au fond des bois, très vite la meute arrive...
Bon, ok désolé je me suis emporté la dernière fois.
Quelques réaction tout de même:
- Qualité technique de flash:
Comment savoir ? c'est proprio, donc on peux pas aller voir exactement comment ca marche. D'autre part, si chez toi c'est stable, c'est loin d'être le cas chez tout le monde. Et me dis pas que t'est jamais tombé sur une appli flash qui fait planter le navigateur avec 100% de CPU utilisé. (Je sais tu va me dire c'est pas de la faute du flash si les dévelopeurs codent mal les applet... C'est pas mon avis)
De plus, les critères ne sont pas pour tout le monde les mêmes: Une machine virtuelle, une API complète et multi-plateforme unique en son genre, des routines d'affichage performantes, tout ça dans un téléchargement de 2 Mo fonctionnant sans accroc sur une foultitude de configurations. Aucun projet libre n'arrive à la hauteur de ces quelques caractéristiques.
Si pour toi cela c'est de la qualité technique, c'est bien.
Pour moi, la qualité viens surtout de l'absence de bugs ET de la portabilité.
La portabilité, justement, ca se prévois, dès le début d'un projet. Or, il est TRES clair que le flash n'a JAMAIS été concu pour la portabilité, tu l'a toi-même montré lorsque tu cite du code asm dans le source du flash player (bon, ya peut-etre des routines de fallback, je sais pas)
Ce que je n'accepte pas, c'est que ca fonctionne sur un Linux x86 et PAS sur un linux PPC, ARM ou pire, x86-64: Là, normallement, une simple recompilation suffi, à condition de ne pas truffer le code d'asm et d'utiliser les librairies de l'OS.
Je suis bien d'accord que pour le porter sur Windows/MacOS/solaris/*BSD/... il faut adapter les couches basse, et selon le cas c'est pas un boulot facile.
J'ai *exactement* la même critique pour la JVM Java: Heureuement qu'il y a des jvm libre qui on tant bien que mal réussies a régler le problème, et il faut espérer que maintenant que la jvm est GPL les portages et simplifications vont arriver.
Il y a des tas d'autres exemples: Picasa, GoogleEarth (qui eux ont pu utiliser wine, effectivement c'est pas donné à toute les architectures). Et là, surtout pour GE, il y a le problème de la 3D.
C'est regrettable, mais le défi technologique est autrement compliqué que celui du flash, qui reste une virtual machine.
Et le rapport entre Flash et Javascript, c'est quoi, à part tes aversions gratuites et incompétentes ?
C'est 2 techno qui s'execute sur le poste client, et qui posent des TAS de problèmes a tout le monde, entre les plantages navigateurs (100% CPU et j'en passe) et les derniers développements de virus en JS.
(Qui, pour veux qui ne sont pas au courant, lorsqu'ils s'executent sur la machien client via une page web, vienne attaquer par brute-force le
routeur ou la box avec des mot de passe courant genre admin/admin sur le port telnet ou meme HTTP, puis ensuite identifie la marque/modèle, vont télécharger un "profil", et prennent le controle du routeur en le faisant rediriger des ports, envoyer des pings, faire du scan de port, etc... Le tout sans que l'utilisateur n'y vois rien, et aucun antivirus n'y peux rien car rien n'est installé sur le PC utilisateur)
Ok, vendredi prochain tu nous codes un équivalent du lecteur Flash en mieux et plus portable, hein, dis ?
Justement pas, non, parceque ce genre de techno sur le poste client, ca se travaille à long terme, il faut essayer de penser à toute les utilisation possible, éviter les enfermements, penser à la sécurité...
(Autant de choses qui sont pas forcément en accord avec les objectifs privées des companies privées, surtout les très très grosses).
C'est censé tourner sur un poste *Client*, potentiellement mal protégé, voire critique (téléphone ou poste public) et dont l'utilisateur n'a pas les compétences pour gérer la sécurité.
Pour moi, le flash n'est vraiment qu'une "démo technologique", il reste à inventer un système mature qui fasse la même chose, peut-etre à l'initiative d'un organisme de normalisation style W3C ou ISO.
Ok ca sera pas fait en 3j, mais au moins :
- ca marchera,
- ca marchera tout le temps,
- ca marchera tout le temps pareil,
- ca marchera partout.
Et moi ce que je supporte pas dans le flash, c'est que non seulement c'est proprio, mais en plus, ils ne livre la version compilé QUE pour x86.
Conséquence: Impossible d'utiliser flash (en tous cas dans ses dernières versions) sur ARM (PDA, Nintendo DS, ...), MIPS ou PowerPC (Set top box), et même sur des x86 avec des architectures un peu spéciales (type AMD Geode, trouvé sur des network PC).
Même sur architecture x86-64, pourtant de plus en plus répandues, ca n'existe pas (ils y travaillent, parait-il... Ca dois pas être bien brillant, leur code, si une simple recompilation ne suffit pas).
Et je parle même pas des autres OS, Free- ou Net- BSD.
Bref, ca m'horripile cette habitude de mettre du flash ou du javascript partout ou on peux.
Tiens autre chose:
C'est quoi, aussi, cette habitudes qu'on tous les sites de proposer systématiquement le téléchargement des versions adapté a l'OS sur lequel on est (ex: Adobe, pour Télécharger le plugin flash justement) ?
OK, ca aide le plus grand nombre, mais c'est vraiment relou quand on veux télécharger pour une autre plateforme, c'est la croix et la bannière, ca m'est arrivé de devoir changer le user-id pour pouvoir avoir le lien.
(Mozilla, au moins, propose un lien en bas "get another version". Adobe, rien du tout)
Franchement, à vouloir tout simplifier on en viens a tout compliquer... :-(
Bon, coup de geule du vendredi, je sais ca sert à rien mais ca défoule.
Tout dépend de la caméra que tu veux et de la résolution d'affichage, mais pour cette utilisation (streaming des données vers un portable), toutes les cartes vont suffire.
Par contre la puissance requise pour cette "simple" tache augmente vachement dès que la résolution augmente: Nous, on avais dû streamer de la full-HD (1080*720, 30img/sec en MPEG2, en firewire), ca mettait à genou un mac mini.
Je vois pas trop comment tu veux faire en FTP, par contre... Mais bon.
Tu ne donne pas trop d'infos concernant les besoins en poids/taille, conso, et nombre de cartes, ce que je vais dire est à prendre avec les pincettes...
- Foxboard: http://www.acmesystems.it/?id=4
+ : Ethernet intégré, RoHS-compliant, déjà utilisé pour des trucs de caméra, une carte additionelle FPGA existe (a rajouter dessus)
- : Pas trop de RAM, encore moins de flash, vitesse de traitement limitée.
- Armadeus: http://www.armadeus.com/products_APF9328.html
+ A peu près la même taille & meme puissance que les gumstix, meme taille de carte, possibilité d'inclure une FPGA, RoHS (marché européen)
- C'est une assoc, alors je sais pas si tu peux commander 10K cartes pour après-demain. Utilise aussi les connecteurs Hirose super-chiants, comme la gumstix. Du dev hardware à prévoir autour, si tu ne peux pas utiliser la carte de support directement
-Embedian: http://www.embedian.com/index.php?main_page=index&cPath=(...)
+ Puissance de traitement conséquante, pas mal de périphériques dispo en option (donc une carte graphique complete, avec 8Mo de ram dédié).
Ils font aussi des "computer on Modules", que je connais pas.
Je sais pas no, plus si ils sont RoHS.
- Vachement plus grosse (form factor 3 1/2), consome plus, seulement 12 GPIO de disponible, pas de flash intégré.
RED est une "classless" qdisc, ce qui veux dire qu'il ne supporte pas de fils.
Il s'utilise donc en 'qdisc' ou en 'class' terminale, avec tc.
Dans le script que j'ai posté la dernière fois, (http://linuxfr.org/forums/12/20943.html ) il faudrait le mettre en lieu et place de sfq ou de pfifo, avec ses paramètres.
ex:
tc qdisc add dev eth0 parent 1:21 handle 21: red limit 1000000 \
min 5000 max 100000 avpkt 1000 burst 50
ok, j'ai tous compris maintenant. cependant est ce qu'il y a un moyen de voir la valeur du champ MARK avec une commande pour un paquet donné?
J'ai pas compris: dans quel contexte ? Via un tcpdump par exemple ?
La marque est interne au noyau: dès que le paquet sort du noyau, elle n'existe plus. Elle n'existe que dans le contexte de netfilter.
Par contre avec iptables -t mangle -L on peux voir les stats des paquets pour chaques règles.
et je cherche également un logiciel qui me permetterai de voir graphiquement le traffic de chaque file d'attente que j'ai créer, est ce que vous en connaisez un ?
alors j'ai jamais fait (perso je me contente des chiffres) mais je sais que les solutions mises en places par ipcop & compagnie tournent autour de MRTG/rrdb et des scripts lancés périodiquement.
Voici le script en question: Je pense qu'il est gros, mais complet.
#!/bin/sh
#
# Control the bandwith management between connections.
# Works in close collaboration with the rc.firewall script, which must
# be called *BEFORE* this one. (because of tagging)
OUTDEV=ppp0
# CLASS1+CLASS2+CLASS3 must equal MAX_UPLOAD_RATE
MAX_UPLOAD_RATE=15kbps
CLASS1=8kbps
CLASS2=4kbps
CLASS3=3kbps
echo Clearing Netfilter rules for mangle table. Also clear counters
iptables -t mangle -F
iptables -t mangle -Z
if ! ifconfig $OUTDEV >/dev/null 2>&1 ; then
echo Cannot find output interface $OUTDEV, delaying a little....
sleep 8
if ! ifconfig $OUTDEV > /dev/null 2>&1 ; then
echo Cannot find output interface $OUTDEV. Abort.
exit 1
fi
fi
echo Clearing the QoS disciplines
tc qdisc del dev $OUTDEV root handle 1: prio bands 3
if [ "$1" == "del" ]; then
exit 0
fi
# Setup the flow control.
# This apply to the OUTGOING interface : the cable modem
# We assume that the packets arriving from the net come much slower
# than the internal network, so the output queue on the local
# interface is empty 99.9% of time.
# Here is the schema :
# /------\
# | PRIO |
# \------/
# / | \
# / | \
# 1/ 2| 3\
# / | \
# / | \
# /-------\ /-------\ /------\
# | pfifo | | SFQ | | HTB |
# \-------/ \-------/ \------/
# / | \
# / | \
# 3.1/ 3.2| 3.3\
# / | \
# /-----\ /-----\ /-----\
# | SFQ | | SFQ | | SFQ |
# \-----/ \-----/ \-----/
#
# Links 1, 2, 3 are absolute priorities : No packet comme from 2 or 3 if
# the pipe 1 is not empty.
# Pipe 1 is for UDP DNS request or answers, and TCP ACK or SYN.
# Pipe 2 is for SSH connections and FTP-control
# Pipe 3 is for anything else.
#
# The pipe 3 is classed throught a HTB (Hierarchical Tocken Bucket)
# The classes can share the load between them, BUT, in case of congestion :
# Class 3 is 80% of the traffic : client interactive traffic :
# HTTP, Mail, IRC(both client and server), Webcam
# Class 4 is 10% of the traffic : server traffic :
# HTTP , Mail, Webmin, and FTP (both client and server)
# Class 5 is everything else ( kazaa, edonkey ...)
echo "Tagging packets"
# Class 4 : server : HTTP(80,443), Webmin(10001:10254), FTP(21,20,27000-27999)
# client : FTP_data in Active Mode mode (20)
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 80 -j MARK --set-mark 4
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 443 -j MARK --set-mark 4
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 21 -j MARK --set-mark 4
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 20 -j MARK --set-mark 4
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 27000:27999 -j MARK --set-mark 4
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 10001:10254 -j MARK --set-mark 4
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 20 -j MARK --set-mark 4
# Class 3 : client : HTTP(80,443), Mail(25,110,143,993,1093), IRC(6666,6667),
# ,ICQ(5190/TCP+UDP), Yahoo chat (5050/TCP), news(119)
# FTP_control (21)
# : server : IRC(6667) , Mail(993,25)
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 80 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 443 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 21 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 25 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 143 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 110 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 993 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 1093 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 119 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 6666:6667 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 5190 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 5190 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 5050 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 25 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 993 -j MARK --set-mark 3
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 6667 -j MARK --set-mark 3
# Class 2 : ssh(22)
# Real-time traffic : Yahoo ( 5000/1/TCP, 5000/10/UDP, 5100/TCP)
# NetMeeting ( 1720/TCP, 20200/9/UDP+TCP ) via nmproxy (inetd)
# MSN ( 1863/TCP )
# Roger Wilco ( 3782/1/TCP+UDP ), ASRC ( 3290 TCP+UDP )
# VNC ( 5900/x/TCP , x is the number of simultaneous connection)
# Skype (27614)
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 22 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 22 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 5100 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 1863 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 5000:5001 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 5000:5010 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 3782:3783 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 3782:3783 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 3290 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 3290 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 5900:5902 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 1720 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 1720 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 1720 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --sport 1720 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 20200:20209 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 20200:20209 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 20200:20259 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --sport 20200:20259 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --sport 27614 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --sport 27614 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 27614 -j MARK --set-mark 2
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --dport 27614 -j MARK --set-mark 2
# Class 1 : TCP connection control (ACK,SYN,RST,FIN) , ICMP and DNS(53 UDP)
iptables -A POSTROUTING -t mangle -o $OUTDEV -p udp --dport 53 -j MARK --set-mark 1
iptables -A POSTROUTING -t mangle -o $OUTDEV -p icmp -j MARK --set-mark 1
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags SYN SYN -j MARK --set-mark 1
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags RST RST -j MARK --set-mark 1
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags FIN FIN -j MARK --set-mark 1
iptables -A POSTROUTING -t mangle -o $OUTDEV -p tcp --tcp-flags ACK ACK -m length --length :74 -j MARK --set-mark 1
echo Adding QoS rules :
echo " Adding root PRIO discipline"
# All packets goes throught the last and default pipe
# The other ones are selected using filters
tc qdisc add dev $OUTDEV root handle 1: prio bands 3 priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
echo " Adding first level disciplines"
# First pipe is a standard fifo
# Second is a sfq ( for ssh connections )
# Third is a HTB filter, that will be subdivided
tc qdisc add dev $OUTDEV parent 1:1 handle 11: sfq perturb 10
tc qdisc add dev $OUTDEV parent 1:2 handle 12: sfq perturb 10
tc qdisc add dev $OUTDEV parent 1:3 handle 13: htb r2q 1 default 30
echo " Adding HTB Classes"
tc class add dev $OUTDEV parent 13: classid 13:1 htb rate $MAX_UPLOAD_RATE ceil $MAX_UPLOAD_RATE
# All classes could take the whole bandwidth, BUT they are not equal in front of congestion
tc class add dev $OUTDEV parent 13:1 classid 13:10 htb rate $CLASS1 ceil $MAX_UPLOAD_RATE mtu 1492
tc class add dev $OUTDEV parent 13:1 classid 13:20 htb rate $CLASS2 ceil $MAX_UPLOAD_RATE mtu 1492
tc class add dev $OUTDEV parent 13:1 classid 13:30 htb rate $CLASS3 ceil $MAX_UPLOAD_RATE mtu 1492
echo " Adding last level disciplines"
# Finally, the connections selected by the CBQ are delivered with an SFQ discipline
tc qdisc add dev $OUTDEV parent 13:10 handle 131: sfq perturb 10
tc qdisc add dev $OUTDEV parent 13:20 handle 132: sfq perturb 10
tc qdisc add dev $OUTDEV parent 13:30 handle 133: sfq perturb 10
echo Applying tags to QoS filter
# Filter the connections with the tags as key values
tc filter add dev $OUTDEV protocol ip parent 1: handle 1 fw flowid 1:1
tc filter add dev $OUTDEV protocol ip parent 1: handle 2 fw flowid 1:2
tc filter add dev $OUTDEV protocol ip parent 1: handle 3 fw flowid 1:3
tc filter add dev $OUTDEV protocol ip parent 1: handle 4 fw flowid 1:3
tc filter add dev $OUTDEV protocol ip parent 1: handle 5 fw flowid 1:3
tc filter add dev $OUTDEV protocol ip parent 13: handle 3 fw flowid 13:10
tc filter add dev $OUTDEV protocol ip parent 13: handle 4 fw flowid 13:20
export FLOW_CONTROL="Yes"
Le script rc.firewall est:
#!/bin/sh
accept() {
if [ -z "$1" -o -z "$2" -o -z "$3" ] ; then
return 1
fi
if [ ! -z "$4" ]; then
dest=$2:$4
else
dest=$2
fi
iptables -t nat -A PREROUTING -i $OUTIF -p $3 --dport $1 -j DNAT --to-destination $dest
iptables -A FORWARD -i $OUTIF -d $2 -p $3 --dport $1 -j ACCEPT
echo " - Prerouting port $1 to $dest ( $3 )"
}
accept() {
if [ -z "$1" -o -z "$2" ] ; then
return 1
fi
iptables -A INPUT -p $2 --dport $1 -j ACCEPT
echo " - Accepting port $1 ( $2 )"
}
output() {
if [ -z "$1" -o -z "$2" ] ; then
return 1
fi
iptables -A OUTPUT -p $2 --dport $1 -j ACCEPT
iptables -A FORWARD -o $OUTIF -p $2 --dport $1 -j ACCEPT
echo " - Output port $1 ( $2 )"
}
OUTIF=ppp0
echo " - Setting internal network authorizations"
iptables -A INPUT -i lo -j ACCEPT
echo " - Setting default rules for masquerading and state control"
iptables -t nat -A POSTROUTING -o $OUTIF -j MASQUERADE
# ICMP are accepted. Floodping is avoid by icmp_ratelimit below
iptables -A INPUT -p icmp -j ACCEPT
# This ignore any packets in the NEW or INVALID state
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# This analysis any opening connection and close it immediatly if PG says so.
# (Warning, MoBlock must be running).
#iptables -A INPUT -i $OUTIF -m state --state NEW -j QUEUE
#iptables -A OUTPUT -o $OUTIF -m state --state NEW -j QUEUE
echo " - Setting various kernel parameters to counter DoS"
#### Prevent various DoS conditions
# Turn off ECN since it brings problems with some sites
echo 0 > /proc/sys/net/ipv4/tcp_ecn
# Turn on TCP_SYNCOOKIES (avoid total DoS when under attack)
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
# Set various icmp protections
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
echo 100 > /proc/sys/net/ipv4/icmp_ratelimit
# Augment the number or connectection tracking to keep in table
echo 250000 > /proc/sys/net/ipv4/ip_conntrack_max
En fait, le champ MARK ne se situe pas dans le paquet:
C'est un champ virtuel, attaché au paquet par linux lorsque le paquet est accepté par le noyau. (A l'occasion de la lecture sur une carte réseau, ou bien de la génération d'un paquet par une application locale).
C'est simplement un champ numérique, en lecture/écriture.
Par défault il n'est pas initialisé.
IPTable permet de mettre la MARK à une valeur arbitraire,
Par exemple, pour marquer tous les paquets sortant vers le port 80:
iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j MARK --set-mark 6
Bon jusque là, on est d'accord ca ne sert pas à grand chose.
Par contre, ce qu'il faut savoir, c'est que la QoS, dans la chaine de sortie du paquet, interviens *APRES* netfilter, y compris POST- routing. Et "tc filter" sait utiliser les MARK placés avant par Netfilter (iptables)...
L'idée est donc de définir ses qdisc et classes avec tc, comme d'habitude, puis ensuite, par une ou plusieurs commandes, intégrer les paquets dans les Class QoS comme ceci:
Cette ligne spécifie:
- l'interface de sortie où la QoS doit être appliqué (dev eth1),
- la QDisc parente, qui doit avoir été crée avec tc qdisc [...] handle 1: [..]
(parent 1:0)
- la priorité au cas ou plusieurs filtres sur le même qdisc existent (prio 1). Ceci défini l'ordre de parcourd des filtres si il y en a plusieurs.
- la MARK de iptables à utiliser (handle 6 fw) -> correspond, numériquement, au set-mark du iptables
- la classe à utilser en dessous de la QDisc, au cas ou le filter matche le paquet
(flowid 1:1). La classe doit avoir été crée auparavant avec tc class.
Voilà!
J'avais fabriqué (avec un ami) un script basé sur ces notions pour une colloc, ca marchais nickel: Les personnes pouvaint surfer sans problèmes, sur une ligne ADSL, alros que il y avait en permanence plus de 4 ordis avec emule/torrent en permanence. La même machine, un pautre Pentium 300, gérait aussi un webmail, et un site LAMP sans aucun soucis.
C'était basé autour de HTB, que j'avais trouvé très efficace.
Si tu veux, ce soir j'essaye de retrouver ce script et de le poster !
> j'ai cru comprendre que la fonera tournait avec http://openwrt.org/ .c'est donc open source et libre .
Ok.
C'est cool pour la QoS: C'est vraiment un point essentiel, c'est LA raison pour placer les routeur ADSL en mode modem et tout gérer sur un pc.
> je ne pensait de toute façon pas utilisé la fonera comme point d'accé wifi perso , la freebox v5 le fait déjà . pour moi c'est sutout pour accéder au réseau fon en déplacement en échange du partage de ma connexion à la maison .
Heu... Une Fonera n'est pas censé être transportée:
C'est juste un point d'accès Wifi suplémentaire.
OB
D'ailleurs, quelqu'un sait si la Fonera est open-source alors, ou pas ?
Est-ce qu'il y aurais quoique ce soit a l'intérieur qui s'y opposerais ?
Parceque que, en particulier, je ne veux pas brancher sur mon réseau un boitier "opaque" qui envoie des trucs depuis mon réseau sans que je puisse savoir a qui.
Bien sur je sais que les gens qui viendront s'y connecter pourront aller ou ils veulent, ca fait parti du deal.
Mais, ce que je ne veux pas ca serais , par exemple, que à la suite d'une maj de firmwarela Fonera envoie à FON (ou autre boite) la liste de mes machines & ports ouverts sur mon réseau perso, les services actifs, la liste & taille des paquets,etc..
Ou alors, implémenter le soft FON sur un autre modem que le leur (parceque j'en ai un mieux, et que j'en veux qu'un seul).
Ou encore, pour faire de la QoS pour laisser aux autres ( les autres, non fonero) la possibilité de se connecter quand même, genre avec un début très faible, et uniquement en port 80.
A ma connaissance, seuls 3 boites font des chipset ADSL:
Texas Instrument (AR7* pour les boitiers Dlink, Linksys, ...), Broadcom (box ADSL free, 9, alice) et Analog Digital, Inc (Livebox).
Sur les 3, pas un seul ne file les sources de l'outil de configuration du module ADSL, ni du module ADSL, ni du firmware de la puce ou unité qui gère l'ADSL.
Donc, pour arriver à faire des choses tordues comme écouter tous les VC en même temps et logger les trames, envoyer des données arbitraires, etc... c'est possible mais à mon avis il faut pas mal de boulot de reverse-engeeniering sur ces aspect-la des puces.
Mais bon, on peux imaginer que, avec n'importe quel modem adsl traffiqué (pas seulement une box), on peux envoyer ce que l'on veux sur tous les VC.
Ensuite, il faut voir si le DSLAM est bien protégé à ce niveau-là, et si des protections existent (genre, mise en connection restreinte et remonté d'alerte lors de la détection de trames louches, ex qui se balladent sur un VC non utilisé)
Notoirement, il y a quelques années les DSLAM étaient de vraie passoire (vxworks :-) ) mais maintenant j'imagine que ca à dû changer.
Il faut voir ensuite comment sont protégé les serveurs en amont, télé et téléphonie, en particulier face au fuzzing. C'est là ou, potentiellement, un DoS peux faire mal.
Mais c'est pas en mettant à jour les box qu'on pourra l'éviter...
Dans tous les cas, la QoS devrait faire que, à moins de tomber sur un bug d'un routeur ou du DSLAM qui le met en DoS, tripatouiller sa connection ne devrais léser que soit-même.
Ben je ne pourrais pas tester, vu que je n'ai pas le service TV.
Je vais essayer ce we, chez une amie qui l'a.
Pour les VC ATM, c'est pas tout a fait ca:
La liaison ADSL étant considéré comme une ATM, elle est divisée en plusieurs VC, numérotés par 2 chiffres: VCI et VPI. Ce sont les nombre 8/35,8/36 que l'on vois parfois dans les config de modems.
Chaque VC est *completement* indépandant, au niveau de la couche 2:
C'est comme si t'avais plusieurs cables ADSL qui arrivaient, d'ailleurs sous linux la couche ATM "standard" te crée une interface distincte par VC.
Dans ces VC, tu peux faire passer ce que tu veux, dont de l'IP, mais aussi un flux MPEG tel quel (comme si t'était sur une carte DVB).
Sur le VC 8/35 (je crois), le protocole est IP.
Sur la box, c'est un processeur a part (ou bien l'une des unité d'execution) qui décode l'ADSL *et* l'ATM, donc tu récupères un packet IP au niveau de l'interface réseau (souvent "atm0" ).
Sur le modem club-internet Hitachi (AH4021) c'est fait par un soft broadcom proprio: Tu lui file le n° de VCI/VPI que tu veux, il te rend les trame IP (je me souviens plus si un en-tete factice ARP est inséré ou pas).
*En plus* de ca, tu peux "mapper" un VCI/VPI vers un port ethernet directement:
Ce dernier deviens indisponible pour le système, mais toute les trames qui arrivent sur le VCI/VPI demandé sont envoyé tel quel sur le port ethernet, et donc "bypass" complètement le noyau linux, matériellement.
Je ne sais pas non plus si une en-tête éthernet factice est inséré au passage, si tu arrives a passer par un switch j'aurais tendance à dire que oui.
Voila, ensuite, dans ces trames-la, rien ne t'oblige à avoir de l'IP, ca peux donc être un flux MPEG tel quel, ou n'importe quoi d'autre. Je suppose que, chez Club, ce flux est encrypté. Et donc, si il n'y a pas de couche IP, effectivement ce n'est pas routable par le WRT56G (je suppose même qu'il dois dropper le paquet, pourvu qu'il doit fabriqué bizarrement)
j'ai installé citadel sur un petit serveur genre dedibox.
C'était le seul qui convenais, sur ce genre de machines il est pas question d'avoir 200Mo de ram de pris rien que pour java+tomcat...
Finallement j'en suis pas mal content, il gère tout très facilement.
Je ne dirais pas que c'est un Exchange-Killer pour autant... Mais il permet de bricoler.
3 inconvénients:
- Toute les bases (mail, news...) sont gérée via berkley-DB.
Or, avec ce système il m'est arrivé que citadel se fasse killer (-9) par le noyau (grsecurity) parcequ'il prenais trop de ressources. Et la , c'est le drame: la base DB étant corrompue, citadel non seulement ne redémarre pas, mais en plus le script par défaut de lancement dans /etc/init.d est stupide et essaye de le relancer => processeur à 100%, sur un serveur distant c'est TRES relou.
J'aimerais tout passer sur une vraie base, un jour... (qqun connais un projet de couche entre l'API berckley-DB et un vrai serveur de BDD.
Je m'était promi de faire un bug report, faudra que je le fasse un jour que j'aurais le temps.
- L'interface web est vilaine.
Mais c'est encore pas trop grave, le système est bien concu et ca serais très simple de la refaire.
- Citadel a la possibilité d'utiliser les comptes système pour se logger .
=> Un truc qu'il faudrais intégrer dans la FAQ, c'est que si dans le fichier /etc/passwd le champ "Nom d'utilisateur" (le 5ème) n'est pas rempli, alors Citadel refusera le login, quoiqu'il arrive, y compris au root.
J'ai mis du temps à comprendre ca, et j'ai trouvé par hasard, après des heures de bagarre.
Ca aussi je voulais faire une note pour la FAQ :-(
Au niveau des cables, peut-être.
J'imagine que il y a du MPLS ou équivalent pour séparer logiquement les réseaux, non ?
Bref, pour la télé, on est bien au-dessus de toute facon.
Chez neuf, je suppose que c'est comme chez Free ou Orange, la TV est diffusée via un ou plusieurs VC ATM dédies, qui sont forwardé en hardware par la box sur le port ethernet (=> du point de vue du processeur de la box, elle ne vois *jamais* passer les trames sur ethN)
C'est là ou je dis que ClubInternet est peut-être différent:
Vu la techno employé (MS-TV) ils peuvent très bien diffuser en multicast IP normal sur le même canal ATM, et un ptit coup de netfilter+prerouting pour diriger les paquets dans le port ethernet de la box. Ca ne reste qu'une possibilité, ca peut très bien marcher autrement.
Sinon, pour répondre à ca:
>>Ils pourront ainsi les installer sans contrainte, un espace mémoire ayant été prévu à cet effet.
>Je pense que l'espace mémoire dont parle Neuf dans le communiqué est isolé du réseau WAN, mais pas LAN
Je pense plutot que le communiqué parle de l'espace *en flash* et non pas en RAM.Les processeurs utilisés (du genre MIPS, broadcom ou T.I.) sont pas des gros processeurs non plus... Une JRE ou même un linux-virtualserver serais tendu.
(mais par contre ils ont plein d'"unitées dédiés" autour, pour faire du TCP-offloading, gérer l'ADSL, la voix, la crypto...)
Ou alors, ils ont mis 2 processeurs, mais ca m'étonnerais ca couterais trop cher.
> Il n'est pas possible actuellement chez neuf (et chez free je sais que c'est possible) de visionner sur PC des flux TV issue de la NeufBox, sauf en utilisant l'entrée TV (analogique). Si tu sais le faire, indique moi la marche à suivre ça m'intéresse.
Non je ne sais pas - je suis pas chez 9, je suis chez Club. mais j'ai pas pris la télé, ca ne m'interesse pas (en plus ils ont choisi un système microsoft-TV, avec la box-tv sous Windows mobile et des flux IP normaux il me semble - un autre défi :-) )
Mais ça devrais pouvoir se trouver, je vais me renseigner, tiens, ca m'a titillé.
>V2 sort de chez neuf et corrige une important faille de sécurité (pour leur réseau, pour la sécurité de leur flux vidéo,...)
Tu peux donner un exemple précis qui fait que le firmware peux provoquer cela ?
Si il existe une faille de sécurité dans le flux vidéo, effectivement: => firmwareV2 + maj de la crypto du flux. Certe les V1 trafiqué ne pourront plus les voir.
En fait, je ne vois toujours pas en quoi une box modifié peux mettre en danger la sécurité d'un réseau bien configuré, avec une bonne politique de sécurité.
> pas de tes données ni de ton réseau local, mais du réseau que tu loues et qui a un cout très important.
...et qu'on paye un prix très important aussi, il ne faudrais pas l'oublier. On est et on reste *clients*, pas locataires.
(Je dis ca car j'ai lu le log du chat IRC sur openFreeBox, avec le "père" de la FB et "son" réseau... :-) )
Ils nous *doivent* non seulement un tuyau, mais aussi le minimum de sécurité, conforme à l'état de l'art (on leur demande pas plus non plus, hein).
>Rien ne t'empêche de changer de provider d'acces si neuf te casse les c...
Mais c'est pareil pour tous les FAI...
Comme un commentaire le dis plus bas:
Les FAIs cherchent à vendre le service, non plus la connection.
Le coup de la "machine virtuelle", c'est pas mal, mais ca empeche pas mal de chose (netfilter/firewall, QoS, patchs noyau pour des périphériques ou des features genre politique TCP, ...)
J'ai du mal a comprendre en quoi une 9box modifiée serais plus dangeureuse qu'un autre modem ADSL (non 9).
C'est vrai que le scénario évoqué au-dessus (faille de sécurité) est possible, mais il me parait vraisemblable que 1) il y a déjà des failles existante non encore trouvées et/ou exploitées, 2) Le client qui choisi de modifier sa box est supposé s'y connaitre assez pour la remettre tout seul d'équerre en cas de problèmes (ou alors, il paye la prestation à 9), enfin, 3) il serais possible d'installer un mécanisme qui va télécharger & installer une version usine du firmware au boot lorsque l'on appuie sur le bouton reset au moment d'allumer la box.
Le client lambda ne *modifie pas* sa box, ou alors uniquement via les options "certifiées" par 9, et il ne perd pas sa garantie.
Par contre, personnellement je ne vois pas le réseau de 9 comme un grand LAN ou toute les autres box sont accessibles... J'imagine (j'espère !) que chaque box reliée au DSLAM est cantonée dans un "tunnel", et que pour passer d'une box à l'autre il faut remonter par les routeurs de chez 9. (comme via un VPN, en fait, et comme n'importe quel autre poste internet).
Donc, si un utilisateur inonde la bande passante ou envoie des paquets foireux, les autres utilisateurs ne devraient pas en etre affectés. Si c'est quand même le cas, mauvais blindage => changer de blindage et de QoS.
En tant que client, c'est *aussi* ce que j'attend de mon provider.
Pour la TV, la téléphonie, tout ca, pareil : La sécurité devrais être faite en amont, parceque rien n'empêche un abonné de brancher une box non 9tel, sur laquelle il a tripatouillé le firmware. Si l'abonné essaye via sa ligne d'accéder à des services auxquels il n'a pas droit, ca devrais se voir dès le DSLAM.
Ensuite, c'est à 9 de voir comment réagir: soit par blocage du service concerné, soit plus violemment (au pire, blocage ligne au niveau DSLAM)
Le controle des box des abonnés, je le vois surtout utile pour des raisons de maintenances : Les techniciens peuvent se logger sur la box, des stats sur la connection peuvent être remontées... Si tout ca n'est pas actif, le client en subit les conséquences, pas 9.
Quant à la télé, crypté ou pas le flux une fois qu'il arrive sur le PC et qu'il est décodé, c'est copiable & réencodable. Point. Un jour (que j'espère lointain) ca pourrais devenir problématique, avec les matériels certifiés et tout, mais aujourd'hui il n'y a aucun problème.
Et si le client arrive à recevoir une chaine pour laquelle il n'a pas payé, c'est de la faute à 9 qui a mal concu son système d'abonnement <-> ligne adsl.
PS: J'ai parlé ici que pour des clients dégroupés.
Pour les clients non dégroupés, 9 n'a pas la maitrise de bout en bout sur la liaison a l'abonné, et donc toute les mesures de sécurité ne sont pas garanties, évidamment.
> ben c'est pas très cher non plus. T obligé de les commander par plusieurs ou me trompe-je ?
Oui, 5 unitées minimum. J'ai pu m'inclure dans la vente groupée proposée sur LinuxFR en novembre.
Les délais de livraisons m'ont bcp déçu: Ils annoncaient 2jours par UPS, mais c'était sans compter la préparation... au final, ma carte a mis presque un mois à arriver. Je suppose qu'ils privilégient les grosses commandes.
Ca ne me gène pas trop, par contre: J'ai mon prototype, et puis si un jour je décide d'utiliser ces cartes en industriel, j'en aurais besoin de bcp plus que 5.
Tu as raison pour le coté "carte mère". Mais bon, je l'ai aussi prise pour le prototypage, ca me permettra de m'en servir pour plusieurs projets (elle a un bon chip video par ex.)
Cela dis, la carte Armadeus m'interesse de + en +, surtout avec sa FPGA, j'aimerais bien m'initier un peu au VHDL.
J'attend de voir ce qu'il y aura sur la carte dev-full, (et aussi de renflouer le portefeuille :-) ), je reste sur la brèche !
A bientot !
OB
Ok pour les prix - Effectivement, c'est a peu près aussi cher que la FOX, pour une puissance de calcul largement supérieure.
Ca m'interesse pas mal ! Pour le moment j'ai acheté ca pour mes tests sur ARM: http://www.embedian.com/index.php?main_page=product_info&(...)
mais il y a très peu de GPIO, ce qui m'ennuie bcp. Et puis c'est pas le meme prix !
Pour l'USB-Device, ben tout dépend de l'application....
Perso ca ne me gène pas trop pour le moment, mais ca peux devenir crucial pour des projets comme un lecteur audio/video, une carte mère de robot ou drone (maj de firmware a partir d'un PC),...
> Je te corrige, la carte Armadeus n'a besoin d'aucun composant externe (drivers genre MAX232) pour faire marcher l'Ethernet, l'USB et le port série... tu voulais surement parler de "connecteurs".
Oui, c'est ce que je voulais dire. Désolé !
>Une carte Armadeus seule n'est pas fonctionnelle, elle a besoin d'une carte de support qui lui fournisse l'alim et les connecteurs.
J'avais effectivement compris cela en regardant le site web.
Perso, je trouve ça pas pratique (puisque, certe on peut bouger le "coeur" de projets en projets, mais il faut à chaque fois une nouvelle carte devlight, ou bien développer sa propre carte, qui dans ce cas dois contenir les connecteurs et l'alim)
La fox peux fonctionner de base branché à l'arrache sur un connecteur d'alim floppy de PC, elle embarque son propre régu 5/3.3V
>Le seul avantage de la carte FOX est selon moi qu'elle possède un controleur USB Host. Mais bon apparement elle n'est plus produite, non ?
Et son inconvénient est qu'elle ne contiens PAS de USB device.... :-)
Si , elle est encore produite : Ils ont des problèmes pour fabriquer la puce Etrax 100MCM en RoHS en "tout intégré" (RAM/Flash/CPU).
Du coup, ils vendent au même prix et même format une carte Fox basé sur un Etrax 100 LX + la flash et la ram en composants externes, soudés.
(Les différences là: http://www.acmesystems.it/?id=30 . Ancienne carte = PCB rouge, nouvelle = PCB vert, ils ont aussi ajouté un connecteur coxial d'alim sur l'avant => plus besoin du connecteur d'alim floppy)
L'avantage de cette version, c'est que la flash+ram étant externe, il sera facile à terme d'avoir plus de combinaisons de flash & ram.
Je me permet d'insister sur le fait que la carte Fox et l'Armadeus n'ont ni les même performances ni les mêmes possibilité (même si , effectivement, il existe une carte optionelle FPGA pour la FOX, l'Armadeus est quand même plus fournie en interfaces et *largement* plus rapide)
D'ailleurs, je n'ai pas trouvé de liens pour acheter ni l'APF9328 ni la devlight ?
Du coup, je ne peux pas comparer selon les prix (la Fox coute 129¤, la carte FPGA en plus coute 99¤, hors frais de ports)
Déjà, les 2 cartes que tu cite ne sont pas du tout équivalentes:
La première est basé sur un microcontrolleur AVR (mega8), qui ne peux pas faire tourner Linux, mais qui conviendrais bien pour des petits projet. Il existe des micro OS pour ceux-la, tel que AVRX (http://barello.net/avrx/), utilisé en robotique.
Par contre, aucun traitements algorithmique lourd ne pourra être fait.
L'avantage, c'est que ca consome très peu de courant, important quand le robot est sur batterie.
La seconde est une vrai carte mère, (je la connais bien, je travaille avec), similaire en terme de performances a un petit pentium.
Elle supporte linux sans problèmes, elle a certe très peu de flash embarqué (4Mo) mais les 2 ports USB permettent d'y brancher des clé USB, et de s'affranchir de la limitation de taille. La Ram est suffisante.
Il faut bien voir que c'est 2 facons TRES différentes de programmer : Dans le 1er cas tu disposes de quelques Ko de RAM et Flash, il n'y a pas de notions de processus. A mon avis, c'est TRES bien pour apprendre, pour voir "comment ca marche". Par contre, tu va mettre plus longtemps pour obtenir des résultat, la programmation étant plus difficile.
Dans le 2eme cas (FOX), tu programmeras comme d'habitude, en C sous linux, et tu aura a disposition plus de puissance de calcul, suffisante par exemple pour utiliser une webcam USB et faire un petit algo d'extraction de contours pour la détection d'obstacles.
Dans les 2 cas, l'électronique à fabriquer autour sera sensiblement la même, étant donné que les 2 cartes disposent des ports séries, GPIO, SPI... nécéssaire (La carte FOX a plus de broches, c'est tout)
Pour relier les capteurs et actionneurs, le port série est déjà un peu complexe: En général, tu partirais plutot sur des éléments discret (capteurs ON/OFF, servomoteurs...) ou bien à la rigeur des bus genre SPI ou I2C, c'est le plus simple et le moins cher.
Perso, je me suis fait une carte qui possède les 2 types:
La carte fox s'occupe de la partie Logique, calculs, controle utilisateur, etc " et le controlleur AVR s'occupe plutot des détails de releve des capteurs et du controle moteur.
Les 2 sont reliés par un bus SPI bidirectionel.
La carte ARMADEUS du post ci-dessus ressemblerais plus à la carte FOX, mais sans les composants externes (RJ45, USB...) qu'il faudra donc rajouter. Elle est plus petite, plus rapide, plus chère, et dispose de connecteurs Hirose pas très pratiques pour de la robotique. Elle a une FPGA interne qui, bien que difficile a programmer, est vraiment génial pour executer des algorithmes complexe très rapidement.
Au final, tout dépend de la complexité requise du robot, des possibilités qu'il aura, et du temps que tu as pour dévelloper le soft.
(Pour un simple robot marcheur qui évite les obstacles, la 1ere carte est OK.
Si tu veux en plus mémoriser un trajet, y relier un GPS ou une webcam, il te faudra la 2eme carte)
Voila, hésite pas a me contacter si tu as besoin de précisions.
Ben déjà, vérifie que tu as la libusb sur ton ordi:
le fichier "/usr/include/usb.h" doit exister.
sinon, il te faut installer le package libusb-devel
(ou libusb-dev selon la distribution)
Ensuite, bah il faut commencer le programme...
Normallement tu dois connaitre le deviceID et le vendorID du periphérique, donc le détecter ca dois ressembler à ca:
int main(void)
{
struct usb_bus *busses;
usb_init();
usb_find_busses();
usb_find_devices();
busses = usb_get_busses();
struct usb_bus *bus;
int c, i, a;
/* boucle sur les bus USB */
for (bus = busses; bus; bus = bus->next) {
struct usb_device *dev;
/* Par bus, boucle sur les devices */
for (dev = bus->devices; dev; dev = dev->next) {
if ((dev->descriptor.idVendor == MYVENDOR) &&
(dev->descriptor.idProduct == MYPRODUCT) ) {
/* boucle sur les configurations, si plus de 1 seule */
{...}
}
}
}
}
Ensuite, ben il faut l'ouvrir, faire un claim, et chercher dans la doc du périphérique USB comment trouver les "paramètres constructeurs" dont tu parles.
Voila !
Regarde aussi si, a tout hasard, ton périphérique n'est pas compatible avec un protocole "standard" USB dont linux a les drivers, style série 'ACM', ou 'HID'.
(Rigole pas ca m'est arrivé....)
A+
Tu peux tout faire depuis le mode user, et ainsi éviter d'avoir a faire un module noyau, si tu n'a pas besoin de t'interfacer avec un sous-système du noyau (type souris/clavier, video4linux, ...)
La, a priori du controle de carte ca correspond bien, et ca te permet de debugger gentiment, sans planter ton noyau au 1er bug.
En plus, comme la lib est multiplateforme, le source serais facilement adaptable sur un autre unix, voire même windows si nécéssaire.
Normallement, tu dois déjà l'avoir sur la distribution, sinon le nom du package est sans doute libusb-dev ou approchant.
[^] # Re: Pas d'acord
Posté par C. OB (site web personnel) . En réponse à la dépêche Apple Plus : sans DRM, mais.... Évalué à 8.
En amérique, il y a un GROS problème en ce moment, c'est ce qu'ils appelent l' "identity thief" (vol d'identité) :
http://en.wikipedia.org/wiki/Identity_theft
En gros, la-bas, le système bancaire est un peu différent, et s'appuie en particulier sur le SSN (Social Security Number) comme numéro d'identifiant unique d'une personne. A la différence du notre, il s'utilise un peu à tord et a travers, et en particulier pour ouvrir des comptes bancaires, payer des factures, prendre des abonnements de gaz, ...
Bref, il est énormément manipulé par beaucoup de monde, et ne comporte que peu de chiffres (8 si je me souviens bien).
De plus, la bas il n'y a pas trop de "droit au découvert bancaire", mais plutôt un système de carte de crédit qui se comporte comme un prêt à la consomation, cad qu'il y a un taux d'intérêts (souvent entre 13 et 19%) sur l'utilisation, juqu'a hauteur de $1000 souvent. Ces cartes de crédits s'obtiennent quasi automatiquement à l'ouverture d'un compte bancaire.
La technique est donc simple: Quelqu'un récupère (très facilement, donc, sur un courrier, facture de gaz, téléphone, ou dans un fichier d'ordinateur) ton nom, prénom, SSN et addresse.
Muni de ces seules information, il va ouvrir un compte bancaire, il récupère une carte de crédit, et va immédiatement acheter tout ce qu'il veux, ou bien retirer du cash. Ensuite, il détruit la carte.
Quelques mois plus tard, en voyant le solde débiteur et le non approvisionnement du compte, la banque va frapper à ta porte, en te demandant de rembourser les somme + les intêrets accumulés (Et 15% par mois sur $1000 ca chiffre vite).
Le problème est que, en plus de cela, ton "credit history", cad une valeur globale qui représente ta capacité à rembourser tes crédits, va baisser. Et ca, c'est très gênant, un peu comme en france se faire classer "interdit bancaire", car c'est très difficile à faire annuler.
La seule solution est de porter plainte, et de prouver ta bonne foi aux banques et instituts de crédits, ce qui prend plusieurs mois.
Pendant ce temps la, plus de crédits, toutes les factures se payent en cash au guichet (les banques ne prennent plus ni chèques ni cartes), et tu recois tous les jourts des lettre de menace des sociétés de collection de fonds (qui elles ne sont pas au courant de la procédure)
Il n'est pas possible de changer de numéro SSN, ce qui fait que si le tiens se balade dans la nature, il se peux très bien que 2 mois après, rebelotte.
C'est très difficile de chopper les gens qui font ca, en général ca demande des flagrant délis, si par exemple ils utilisent la même carte plusieurs fois. Si il ne sont pas trop bêtes, ils ne le font pas, et là... C'est coup de bol.
Les banques pendant longtemps s'en foutaient royalement: Elles augmentais simplement leurs assurances en conséquence, et en répartissait le coût sur les clients.
Là les choses évoluent, parceque vu le nombre de cas, ca bouge au niveau fédéral pour obliger les banques à être plus sérieuses sur l'ouverture des comptes.
Voilà donc les "bienfaits" des numéros d'identification unique, voilà pourquoi la CNIL s'oppose fermement à ce genre de numéro. (pour ce qu'elle est écoutée...)
A mon avis, et comme le veux la légende, tous ce que fait l'amérique, 10ans plus tard ca arrive chez nous, alors...
Pourtant, là, on a la chance d'avoir en direct l'exemple de ce qu'il ne faut pas faire.
# Devoir d'information
Posté par C. OB (site web personnel) . En réponse à la dépêche GPL3, TiVo ou TiVo pas ?. Évalué à 0.
Avec, par exemple, un sticker sur la boite et une mention sur les sites web genre:
"Attention: Ce matériel contient des protection logicelles et matériel qui sont concue pour vous empêcher d'exercer vos droits"
En anglais, ca donnerais:
"Warning: This equippment contains software and hardware protections that prevent it usage under the Fair Use Act."
Déjà, ca éviterais à tous les bidouilleurs d'acheter ces appareils.
Ensuite, ca serais suffisament négatif, je pense, pour que les gens qui ne s'y connaissent pas choisissent un appareil sans le sticker.
A la fin, soit Tivo re-négocie avec les société de production, soient ils meurent.
On pourrais coller la même chose sur les Livebox signées, aussi.
Cela dis, je pense vraiment qu'un jour ou l'autre, ils finiront tous par libérer leurs sources:
Rien que Linksys par exemple, à mon avis ils ont été (avec le recul) très contents de libérer les sources du routeur WRT-54G : Les geeks se sont jeté dessus comme des petits pains (alors meme qu'il y a des parties non libre dedans), des business se sont montées autour de ca,...
Lorsque il y en a un qui entend l'appel feutré de la liasse de billets, le soir au fond des bois, très vite la meute arrive...
obc
[^] # Re: Lecteur
Posté par C. OB (site web personnel) . En réponse à la dépêche Adobe va libérer Flex. Évalué à 1.
Quelques réaction tout de même:
- Qualité technique de flash:
Comment savoir ? c'est proprio, donc on peux pas aller voir exactement comment ca marche. D'autre part, si chez toi c'est stable, c'est loin d'être le cas chez tout le monde. Et me dis pas que t'est jamais tombé sur une appli flash qui fait planter le navigateur avec 100% de CPU utilisé. (Je sais tu va me dire c'est pas de la faute du flash si les dévelopeurs codent mal les applet... C'est pas mon avis)
De plus, les critères ne sont pas pour tout le monde les mêmes:
Une machine virtuelle, une API complète et multi-plateforme unique en son genre, des routines d'affichage performantes, tout ça dans un téléchargement de 2 Mo fonctionnant sans accroc sur une foultitude de configurations. Aucun projet libre n'arrive à la hauteur de ces quelques caractéristiques.
Si pour toi cela c'est de la qualité technique, c'est bien.
Pour moi, la qualité viens surtout de l'absence de bugs ET de la portabilité.
La portabilité, justement, ca se prévois, dès le début d'un projet. Or, il est TRES clair que le flash n'a JAMAIS été concu pour la portabilité, tu l'a toi-même montré lorsque tu cite du code asm dans le source du flash player (bon, ya peut-etre des routines de fallback, je sais pas)
Ce que je n'accepte pas, c'est que ca fonctionne sur un Linux x86 et PAS sur un linux PPC, ARM ou pire, x86-64: Là, normallement, une simple recompilation suffi, à condition de ne pas truffer le code d'asm et d'utiliser les librairies de l'OS.
Je suis bien d'accord que pour le porter sur Windows/MacOS/solaris/*BSD/... il faut adapter les couches basse, et selon le cas c'est pas un boulot facile.
J'ai *exactement* la même critique pour la JVM Java: Heureuement qu'il y a des jvm libre qui on tant bien que mal réussies a régler le problème, et il faut espérer que maintenant que la jvm est GPL les portages et simplifications vont arriver.
Il y a des tas d'autres exemples: Picasa, GoogleEarth (qui eux ont pu utiliser wine, effectivement c'est pas donné à toute les architectures). Et là, surtout pour GE, il y a le problème de la 3D.
C'est regrettable, mais le défi technologique est autrement compliqué que celui du flash, qui reste une virtual machine.
Et le rapport entre Flash et Javascript, c'est quoi, à part tes aversions gratuites et incompétentes ?
C'est 2 techno qui s'execute sur le poste client, et qui posent des TAS de problèmes a tout le monde, entre les plantages navigateurs (100% CPU et j'en passe) et les derniers développements de virus en JS.
(Qui, pour veux qui ne sont pas au courant, lorsqu'ils s'executent sur la machien client via une page web, vienne attaquer par brute-force le
routeur ou la box avec des mot de passe courant genre admin/admin sur le port telnet ou meme HTTP, puis ensuite identifie la marque/modèle, vont télécharger un "profil", et prennent le controle du routeur en le faisant rediriger des ports, envoyer des pings, faire du scan de port, etc... Le tout sans que l'utilisateur n'y vois rien, et aucun antivirus n'y peux rien car rien n'est installé sur le PC utilisateur)
Ok, vendredi prochain tu nous codes un équivalent du lecteur Flash en mieux et plus portable, hein, dis ?
Justement pas, non, parceque ce genre de techno sur le poste client, ca se travaille à long terme, il faut essayer de penser à toute les utilisation possible, éviter les enfermements, penser à la sécurité...
(Autant de choses qui sont pas forcément en accord avec les objectifs privées des companies privées, surtout les très très grosses).
C'est censé tourner sur un poste *Client*, potentiellement mal protégé, voire critique (téléphone ou poste public) et dont l'utilisateur n'a pas les compétences pour gérer la sécurité.
Pour moi, le flash n'est vraiment qu'une "démo technologique", il reste à inventer un système mature qui fasse la même chose, peut-etre à l'initiative d'un organisme de normalisation style W3C ou ISO.
Ok ca sera pas fait en 3j, mais au moins :
- ca marchera,
- ca marchera tout le temps,
- ca marchera tout le temps pareil,
- ca marchera partout.
[^] # Re: Lecteur
Posté par C. OB (site web personnel) . En réponse à la dépêche Adobe va libérer Flex. Évalué à 4.
Conséquence: Impossible d'utiliser flash (en tous cas dans ses dernières versions) sur ARM (PDA, Nintendo DS, ...), MIPS ou PowerPC (Set top box), et même sur des x86 avec des architectures un peu spéciales (type AMD Geode, trouvé sur des network PC).
Même sur architecture x86-64, pourtant de plus en plus répandues, ca n'existe pas (ils y travaillent, parait-il... Ca dois pas être bien brillant, leur code, si une simple recompilation ne suffit pas).
Et je parle même pas des autres OS, Free- ou Net- BSD.
Bref, ca m'horripile cette habitude de mettre du flash ou du javascript partout ou on peux.
Tiens autre chose:
C'est quoi, aussi, cette habitudes qu'on tous les sites de proposer systématiquement le téléchargement des versions adapté a l'OS sur lequel on est (ex: Adobe, pour Télécharger le plugin flash justement) ?
OK, ca aide le plus grand nombre, mais c'est vraiment relou quand on veux télécharger pour une autre plateforme, c'est la croix et la bannière, ca m'est arrivé de devoir changer le user-id pour pouvoir avoir le lien.
(Mozilla, au moins, propose un lien en bas "get another version". Adobe, rien du tout)
Franchement, à vouloir tout simplifier on en viens a tout compliquer... :-(
Bon, coup de geule du vendredi, je sais ca sert à rien mais ca défoule.
ob
[^] # Re: Fox ? Armadeus ?
Posté par C. OB (site web personnel) . En réponse au message cherche equivalent gumstix. Évalué à 1.
Par contre la puissance requise pour cette "simple" tache augmente vachement dès que la résolution augmente: Nous, on avais dû streamer de la full-HD (1080*720, 30img/sec en MPEG2, en firewire), ca mettait à genou un mac mini.
Je vois pas trop comment tu veux faire en FTP, par contre... Mais bon.
# Fox ? Armadeus ?
Posté par C. OB (site web personnel) . En réponse au message cherche equivalent gumstix. Évalué à 1.
- Foxboard: http://www.acmesystems.it/?id=4
+ : Ethernet intégré, RoHS-compliant, déjà utilisé pour des trucs de caméra, une carte additionelle FPGA existe (a rajouter dessus)
- : Pas trop de RAM, encore moins de flash, vitesse de traitement limitée.
- Armadeus: http://www.armadeus.com/products_APF9328.html
+ A peu près la même taille & meme puissance que les gumstix, meme taille de carte, possibilité d'inclure une FPGA, RoHS (marché européen)
- C'est une assoc, alors je sais pas si tu peux commander 10K cartes pour après-demain. Utilise aussi les connecteurs Hirose super-chiants, comme la gumstix. Du dev hardware à prévoir autour, si tu ne peux pas utiliser la carte de support directement
-Embedian: http://www.embedian.com/index.php?main_page=index&cPath=(...)
+ Puissance de traitement conséquante, pas mal de périphériques dispo en option (donc une carte graphique complete, avec 8Mo de ram dédié).
Ils font aussi des "computer on Modules", que je connais pas.
Je sais pas no, plus si ils sont RoHS.
- Vachement plus grosse (form factor 3 1/2), consome plus, seulement 12 GPIO de disponible, pas de flash intégré.
Voila !
OB
# red
Posté par C. OB (site web personnel) . En réponse au message QOS : mise en place de RED dans CBQ ou HTB. Évalué à 1.
Il s'utilise donc en 'qdisc' ou en 'class' terminale, avec tc.
Dans le script que j'ai posté la dernière fois, (http://linuxfr.org/forums/12/20943.html ) il faudrait le mettre en lieu et place de sfq ou de pfifo, avec ses paramètres.
ex:
tc qdisc add dev eth0 parent 1:21 handle 21: red limit 1000000 \
min 5000 max 100000 avpkt 1000 burst 50
voila.
ob
ps: des infos ici:
http://www.lea-linux.org/cached/index/Leapro-pro_reseau-qos.(...)
[^] # Re: Marque MARK
Posté par C. OB (site web personnel) . En réponse au message QOS : marquage des paquets. Évalué à 1.
(bon c'est déjà pas mal)
[^] # Re: Marque MARK
Posté par C. OB (site web personnel) . En réponse au message QOS : marquage des paquets. Évalué à 1.
J'ai pas compris: dans quel contexte ? Via un tcpdump par exemple ?
La marque est interne au noyau: dès que le paquet sort du noyau, elle n'existe plus. Elle n'existe que dans le contexte de netfilter.
Par contre avec iptables -t mangle -L on peux voir les stats des paquets pour chaques règles.
et je cherche également un logiciel qui me permetterai de voir graphiquement le traffic de chaque file d'attente que j'ai créer, est ce que vous en connaisez un ?
alors j'ai jamais fait (perso je me contente des chiffres) mais je sais que les solutions mises en places par ipcop & compagnie tournent autour de MRTG/rrdb et des scripts lancés périodiquement.
ob
[^] # Re: Marque MARK
Posté par C. OB (site web personnel) . En réponse au message QOS : marquage des paquets. Évalué à 1.
Le script rc.firewall est:
Voila !
# Marque MARK
Posté par C. OB (site web personnel) . En réponse au message QOS : marquage des paquets. Évalué à 1.
En fait, le champ MARK ne se situe pas dans le paquet:
C'est un champ virtuel, attaché au paquet par linux lorsque le paquet est accepté par le noyau. (A l'occasion de la lecture sur une carte réseau, ou bien de la génération d'un paquet par une application locale).
C'est simplement un champ numérique, en lecture/écriture.
Par défault il n'est pas initialisé.
IPTable permet de mettre la MARK à une valeur arbitraire,
Par exemple, pour marquer tous les paquets sortant vers le port 80:
iptables -t mangle -A POSTROUTING -p tcp --dport 80 -j MARK --set-mark 6
Bon jusque là, on est d'accord ca ne sert pas à grand chose.
Par contre, ce qu'il faut savoir, c'est que la QoS, dans la chaine de sortie du paquet, interviens *APRES* netfilter, y compris POST- routing. Et "tc filter" sait utiliser les MARK placés avant par Netfilter (iptables)...
L'idée est donc de définir ses qdisc et classes avec tc, comme d'habitude, puis ensuite, par une ou plusieurs commandes, intégrer les paquets dans les Class QoS comme ceci:
tc filter add dev eth1 parent 1:0 prio 1 handle 6 fw flowid 1:1
Cette ligne spécifie:
- l'interface de sortie où la QoS doit être appliqué (dev eth1),
- la QDisc parente, qui doit avoir été crée avec tc qdisc [...] handle 1: [..]
(parent 1:0)
- la priorité au cas ou plusieurs filtres sur le même qdisc existent (prio 1). Ceci défini l'ordre de parcourd des filtres si il y en a plusieurs.
- la MARK de iptables à utiliser (handle 6 fw) -> correspond, numériquement, au set-mark du iptables
- la classe à utilser en dessous de la QDisc, au cas ou le filter matche le paquet
(flowid 1:1). La classe doit avoir été crée auparavant avec tc class.
Voilà!
J'avais fabriqué (avec un ami) un script basé sur ces notions pour une colloc, ca marchais nickel: Les personnes pouvaint surfer sans problèmes, sur une ligne ADSL, alros que il y avait en permanence plus de 4 ordis avec emule/torrent en permanence. La même machine, un pautre Pentium 300, gérait aussi un webmail, et un site LAMP sans aucun soucis.
C'était basé autour de HTB, que j'avais trouvé très efficace.
Si tu veux, ce soir j'essaye de retrouver ce script et de le poster !
Un site avec un bon exemple:
http://www.knowplace.org/pages/howtos/traffic_shaping_with_l(...)
A+
OB
PS: Si tu pense que TC est incompréhensible à utiliser, sache que tout le monde est d'accord avec toi :-)
[^] # Re: Il est pas un peu gros le truc ?
Posté par C. OB (site web personnel) . En réponse au journal recevoir une Fonera gratuitement. Évalué à 1.
Ok.
C'est cool pour la QoS: C'est vraiment un point essentiel, c'est LA raison pour placer les routeur ADSL en mode modem et tout gérer sur un pc.
> je ne pensait de toute façon pas utilisé la fonera comme point d'accé wifi perso , la freebox v5 le fait déjà . pour moi c'est sutout pour accéder au réseau fon en déplacement en échange du partage de ma connexion à la maison .
Pareil .
Merci pour les infos !
[^] # Re: Il est pas un peu gros le truc ?
Posté par C. OB (site web personnel) . En réponse au journal recevoir une Fonera gratuitement. Évalué à 1.
C'est juste un point d'accès Wifi suplémentaire.
OB
D'ailleurs, quelqu'un sait si la Fonera est open-source alors, ou pas ?
Est-ce qu'il y aurais quoique ce soit a l'intérieur qui s'y opposerais ?
Parceque que, en particulier, je ne veux pas brancher sur mon réseau un boitier "opaque" qui envoie des trucs depuis mon réseau sans que je puisse savoir a qui.
Bien sur je sais que les gens qui viendront s'y connecter pourront aller ou ils veulent, ca fait parti du deal.
Mais, ce que je ne veux pas ca serais , par exemple, que à la suite d'une maj de firmwarela Fonera envoie à FON (ou autre boite) la liste de mes machines & ports ouverts sur mon réseau perso, les services actifs, la liste & taille des paquets,etc..
Ou alors, implémenter le soft FON sur un autre modem que le leur (parceque j'en ai un mieux, et que j'en veux qu'un seul).
Ou encore, pour faire de la QoS pour laisser aux autres ( les autres, non fonero) la possibilité de se connecter quand même, genre avec un début très faible, et uniquement en port 80.
Bref, j'ai plein de bonnes raisons... :-)
[^] # Re: c'est marqué dedans...
Posté par C. OB (site web personnel) . En réponse au journal Neuf confirme son ouverture vers le logiciel libre. Évalué à 1.
A ma connaissance, seuls 3 boites font des chipset ADSL:
Texas Instrument (AR7* pour les boitiers Dlink, Linksys, ...), Broadcom (box ADSL free, 9, alice) et Analog Digital, Inc (Livebox).
Sur les 3, pas un seul ne file les sources de l'outil de configuration du module ADSL, ni du module ADSL, ni du firmware de la puce ou unité qui gère l'ADSL.
Donc, pour arriver à faire des choses tordues comme écouter tous les VC en même temps et logger les trames, envoyer des données arbitraires, etc... c'est possible mais à mon avis il faut pas mal de boulot de reverse-engeeniering sur ces aspect-la des puces.
Mais bon, on peux imaginer que, avec n'importe quel modem adsl traffiqué (pas seulement une box), on peux envoyer ce que l'on veux sur tous les VC.
Ensuite, il faut voir si le DSLAM est bien protégé à ce niveau-là, et si des protections existent (genre, mise en connection restreinte et remonté d'alerte lors de la détection de trames louches, ex qui se balladent sur un VC non utilisé)
Notoirement, il y a quelques années les DSLAM étaient de vraie passoire (vxworks :-) ) mais maintenant j'imagine que ca à dû changer.
Il faut voir ensuite comment sont protégé les serveurs en amont, télé et téléphonie, en particulier face au fuzzing. C'est là ou, potentiellement, un DoS peux faire mal.
Mais c'est pas en mettant à jour les box qu'on pourra l'éviter...
Dans tous les cas, la QoS devrait faire que, à moins de tomber sur un bug d'un routeur ou du DSLAM qui le met en DoS, tripatouiller sa connection ne devrais léser que soit-même.
OB
[^] # Re: c'est marqué dedans...
Posté par C. OB (site web personnel) . En réponse au journal Neuf confirme son ouverture vers le logiciel libre. Évalué à 1.
Je vais essayer ce we, chez une amie qui l'a.
Pour les VC ATM, c'est pas tout a fait ca:
La liaison ADSL étant considéré comme une ATM, elle est divisée en plusieurs VC, numérotés par 2 chiffres: VCI et VPI. Ce sont les nombre 8/35,8/36 que l'on vois parfois dans les config de modems.
Chaque VC est *completement* indépandant, au niveau de la couche 2:
C'est comme si t'avais plusieurs cables ADSL qui arrivaient, d'ailleurs sous linux la couche ATM "standard" te crée une interface distincte par VC.
Dans ces VC, tu peux faire passer ce que tu veux, dont de l'IP, mais aussi un flux MPEG tel quel (comme si t'était sur une carte DVB).
Sur le VC 8/35 (je crois), le protocole est IP.
Sur la box, c'est un processeur a part (ou bien l'une des unité d'execution) qui décode l'ADSL *et* l'ATM, donc tu récupères un packet IP au niveau de l'interface réseau (souvent "atm0" ).
Sur le modem club-internet Hitachi (AH4021) c'est fait par un soft broadcom proprio: Tu lui file le n° de VCI/VPI que tu veux, il te rend les trame IP (je me souviens plus si un en-tete factice ARP est inséré ou pas).
*En plus* de ca, tu peux "mapper" un VCI/VPI vers un port ethernet directement:
Ce dernier deviens indisponible pour le système, mais toute les trames qui arrivent sur le VCI/VPI demandé sont envoyé tel quel sur le port ethernet, et donc "bypass" complètement le noyau linux, matériellement.
Je ne sais pas non plus si une en-tête éthernet factice est inséré au passage, si tu arrives a passer par un switch j'aurais tendance à dire que oui.
Voila, ensuite, dans ces trames-la, rien ne t'oblige à avoir de l'IP, ca peux donc être un flux MPEG tel quel, ou n'importe quoi d'autre. Je suppose que, chez Club, ce flux est encrypté. Et donc, si il n'y a pas de couche IP, effectivement ce n'est pas routable par le WRT56G (je suppose même qu'il dois dropper le paquet, pourvu qu'il doit fabriqué bizarrement)
[^] # Re: comparaison avec citadel ?
Posté par C. OB (site web personnel) . En réponse au journal Sortie de Zimbra 4.5. Évalué à 2.
C'était le seul qui convenais, sur ce genre de machines il est pas question d'avoir 200Mo de ram de pris rien que pour java+tomcat...
Finallement j'en suis pas mal content, il gère tout très facilement.
Je ne dirais pas que c'est un Exchange-Killer pour autant... Mais il permet de bricoler.
3 inconvénients:
- Toute les bases (mail, news...) sont gérée via berkley-DB.
Or, avec ce système il m'est arrivé que citadel se fasse killer (-9) par le noyau (grsecurity) parcequ'il prenais trop de ressources. Et la , c'est le drame: la base DB étant corrompue, citadel non seulement ne redémarre pas, mais en plus le script par défaut de lancement dans /etc/init.d est stupide et essaye de le relancer => processeur à 100%, sur un serveur distant c'est TRES relou.
J'aimerais tout passer sur une vraie base, un jour... (qqun connais un projet de couche entre l'API berckley-DB et un vrai serveur de BDD.
Je m'était promi de faire un bug report, faudra que je le fasse un jour que j'aurais le temps.
- L'interface web est vilaine.
Mais c'est encore pas trop grave, le système est bien concu et ca serais très simple de la refaire.
- Citadel a la possibilité d'utiliser les comptes système pour se logger .
=> Un truc qu'il faudrais intégrer dans la FAQ, c'est que si dans le fichier /etc/passwd le champ "Nom d'utilisateur" (le 5ème) n'est pas rempli, alors Citadel refusera le login, quoiqu'il arrive, y compris au root.
J'ai mis du temps à comprendre ca, et j'ai trouvé par hasard, après des heures de bagarre.
Ca aussi je voulais faire une note pour la FAQ :-(
OB
[^] # Re: c'est marqué dedans...
Posté par C. OB (site web personnel) . En réponse au journal Neuf confirme son ouverture vers le logiciel libre. Évalué à 2.
J'imagine que il y a du MPLS ou équivalent pour séparer logiquement les réseaux, non ?
Bref, pour la télé, on est bien au-dessus de toute facon.
Chez neuf, je suppose que c'est comme chez Free ou Orange, la TV est diffusée via un ou plusieurs VC ATM dédies, qui sont forwardé en hardware par la box sur le port ethernet (=> du point de vue du processeur de la box, elle ne vois *jamais* passer les trames sur ethN)
C'est là ou je dis que ClubInternet est peut-être différent:
Vu la techno employé (MS-TV) ils peuvent très bien diffuser en multicast IP normal sur le même canal ATM, et un ptit coup de netfilter+prerouting pour diriger les paquets dans le port ethernet de la box. Ca ne reste qu'une possibilité, ca peut très bien marcher autrement.
Sinon, pour répondre à ca:
>>Ils pourront ainsi les installer sans contrainte, un espace mémoire ayant été prévu à cet effet.
>Je pense que l'espace mémoire dont parle Neuf dans le communiqué est isolé du réseau WAN, mais pas LAN
Je pense plutot que le communiqué parle de l'espace *en flash* et non pas en RAM.Les processeurs utilisés (du genre MIPS, broadcom ou T.I.) sont pas des gros processeurs non plus... Une JRE ou même un linux-virtualserver serais tendu.
(mais par contre ils ont plein d'"unitées dédiés" autour, pour faire du TCP-offloading, gérer l'ADSL, la voix, la crypto...)
Ou alors, ils ont mis 2 processeurs, mais ca m'étonnerais ca couterais trop cher.
[^] # Re: c'est marqué dedans...
Posté par C. OB (site web personnel) . En réponse au journal Neuf confirme son ouverture vers le logiciel libre. Évalué à 1.
Non je ne sais pas - je suis pas chez 9, je suis chez Club. mais j'ai pas pris la télé, ca ne m'interesse pas (en plus ils ont choisi un système microsoft-TV, avec la box-tv sous Windows mobile et des flux IP normaux il me semble - un autre défi :-) )
Mais ça devrais pouvoir se trouver, je vais me renseigner, tiens, ca m'a titillé.
>V2 sort de chez neuf et corrige une important faille de sécurité (pour leur réseau, pour la sécurité de leur flux vidéo,...)
Tu peux donner un exemple précis qui fait que le firmware peux provoquer cela ?
Si il existe une faille de sécurité dans le flux vidéo, effectivement: => firmwareV2 + maj de la crypto du flux. Certe les V1 trafiqué ne pourront plus les voir.
En fait, je ne vois toujours pas en quoi une box modifié peux mettre en danger la sécurité d'un réseau bien configuré, avec une bonne politique de sécurité.
> pas de tes données ni de ton réseau local, mais du réseau que tu loues et qui a un cout très important.
...et qu'on paye un prix très important aussi, il ne faudrais pas l'oublier. On est et on reste *clients*, pas locataires.
(Je dis ca car j'ai lu le log du chat IRC sur openFreeBox, avec le "père" de la FB et "son" réseau... :-) )
Ils nous *doivent* non seulement un tuyau, mais aussi le minimum de sécurité, conforme à l'état de l'art (on leur demande pas plus non plus, hein).
>Rien ne t'empêche de changer de provider d'acces si neuf te casse les c...
Mais c'est pareil pour tous les FAI...
Comme un commentaire le dis plus bas:
Les FAIs cherchent à vendre le service, non plus la connection.
Le coup de la "machine virtuelle", c'est pas mal, mais ca empeche pas mal de chose (netfilter/firewall, QoS, patchs noyau pour des périphériques ou des features genre politique TCP, ...)
[^] # Re: c'est marqué dedans...
Posté par C. OB (site web personnel) . En réponse au journal Neuf confirme son ouverture vers le logiciel libre. Évalué à 4.
C'est vrai que le scénario évoqué au-dessus (faille de sécurité) est possible, mais il me parait vraisemblable que 1) il y a déjà des failles existante non encore trouvées et/ou exploitées, 2) Le client qui choisi de modifier sa box est supposé s'y connaitre assez pour la remettre tout seul d'équerre en cas de problèmes (ou alors, il paye la prestation à 9), enfin, 3) il serais possible d'installer un mécanisme qui va télécharger & installer une version usine du firmware au boot lorsque l'on appuie sur le bouton reset au moment d'allumer la box.
Le client lambda ne *modifie pas* sa box, ou alors uniquement via les options "certifiées" par 9, et il ne perd pas sa garantie.
Par contre, personnellement je ne vois pas le réseau de 9 comme un grand LAN ou toute les autres box sont accessibles... J'imagine (j'espère !) que chaque box reliée au DSLAM est cantonée dans un "tunnel", et que pour passer d'une box à l'autre il faut remonter par les routeurs de chez 9. (comme via un VPN, en fait, et comme n'importe quel autre poste internet).
Donc, si un utilisateur inonde la bande passante ou envoie des paquets foireux, les autres utilisateurs ne devraient pas en etre affectés. Si c'est quand même le cas, mauvais blindage => changer de blindage et de QoS.
En tant que client, c'est *aussi* ce que j'attend de mon provider.
Pour la TV, la téléphonie, tout ca, pareil : La sécurité devrais être faite en amont, parceque rien n'empêche un abonné de brancher une box non 9tel, sur laquelle il a tripatouillé le firmware. Si l'abonné essaye via sa ligne d'accéder à des services auxquels il n'a pas droit, ca devrais se voir dès le DSLAM.
Ensuite, c'est à 9 de voir comment réagir: soit par blocage du service concerné, soit plus violemment (au pire, blocage ligne au niveau DSLAM)
Le controle des box des abonnés, je le vois surtout utile pour des raisons de maintenances : Les techniciens peuvent se logger sur la box, des stats sur la connection peuvent être remontées... Si tout ca n'est pas actif, le client en subit les conséquences, pas 9.
Quant à la télé, crypté ou pas le flux une fois qu'il arrive sur le PC et qu'il est décodé, c'est copiable & réencodable. Point. Un jour (que j'espère lointain) ca pourrais devenir problématique, avec les matériels certifiés et tout, mais aujourd'hui il n'y a aucun problème.
Et si le client arrive à recevoir une chaine pour laquelle il n'a pas payé, c'est de la faute à 9 qui a mal concu son système d'abonnement <-> ligne adsl.
PS: J'ai parlé ici que pour des clients dégroupés.
Pour les clients non dégroupés, 9 n'a pas la maitrise de bout en bout sur la liaison a l'abonné, et donc toute les mesures de sécurité ne sont pas garanties, évidamment.
[^] # Re: Carte embarqué
Posté par C. OB (site web personnel) . En réponse au message Débuts en Robotique. Évalué à 1.
Oui, 5 unitées minimum. J'ai pu m'inclure dans la vente groupée proposée sur LinuxFR en novembre.
Les délais de livraisons m'ont bcp déçu: Ils annoncaient 2jours par UPS, mais c'était sans compter la préparation... au final, ma carte a mis presque un mois à arriver. Je suppose qu'ils privilégient les grosses commandes.
Ca ne me gène pas trop, par contre: J'ai mon prototype, et puis si un jour je décide d'utiliser ces cartes en industriel, j'en aurais besoin de bcp plus que 5.
Tu as raison pour le coté "carte mère". Mais bon, je l'ai aussi prise pour le prototypage, ca me permettra de m'en servir pour plusieurs projets (elle a un bon chip video par ex.)
Cela dis, la carte Armadeus m'interesse de + en +, surtout avec sa FPGA, j'aimerais bien m'initier un peu au VHDL.
J'attend de voir ce qu'il y aura sur la carte dev-full, (et aussi de renflouer le portefeuille :-) ), je reste sur la brèche !
A bientot !
OB
[^] # Re: Carte embarqué
Posté par C. OB (site web personnel) . En réponse au message Débuts en Robotique. Évalué à 1.
Ok pour les prix - Effectivement, c'est a peu près aussi cher que la FOX, pour une puissance de calcul largement supérieure.
Ca m'interesse pas mal ! Pour le moment j'ai acheté ca pour mes tests sur ARM:
http://www.embedian.com/index.php?main_page=product_info&(...)
mais il y a très peu de GPIO, ce qui m'ennuie bcp. Et puis c'est pas le meme prix !
Pour l'USB-Device, ben tout dépend de l'application....
Perso ca ne me gène pas trop pour le moment, mais ca peux devenir crucial pour des projets comme un lecteur audio/video, une carte mère de robot ou drone (maj de firmware a partir d'un PC),...
A bientot !
OB
[^] # Re: Carte embarqué
Posté par C. OB (site web personnel) . En réponse au message Débuts en Robotique. Évalué à 1.
Oui, c'est ce que je voulais dire. Désolé !
>Une carte Armadeus seule n'est pas fonctionnelle, elle a besoin d'une carte de support qui lui fournisse l'alim et les connecteurs.
J'avais effectivement compris cela en regardant le site web.
Perso, je trouve ça pas pratique (puisque, certe on peut bouger le "coeur" de projets en projets, mais il faut à chaque fois une nouvelle carte devlight, ou bien développer sa propre carte, qui dans ce cas dois contenir les connecteurs et l'alim)
La fox peux fonctionner de base branché à l'arrache sur un connecteur d'alim floppy de PC, elle embarque son propre régu 5/3.3V
>Le seul avantage de la carte FOX est selon moi qu'elle possède un controleur USB Host. Mais bon apparement elle n'est plus produite, non ?
Et son inconvénient est qu'elle ne contiens PAS de USB device.... :-)
Si , elle est encore produite : Ils ont des problèmes pour fabriquer la puce Etrax 100MCM en RoHS en "tout intégré" (RAM/Flash/CPU).
Du coup, ils vendent au même prix et même format une carte Fox basé sur un Etrax 100 LX + la flash et la ram en composants externes, soudés.
(Les différences là: http://www.acmesystems.it/?id=30 . Ancienne carte = PCB rouge, nouvelle = PCB vert, ils ont aussi ajouté un connecteur coxial d'alim sur l'avant => plus besoin du connecteur d'alim floppy)
L'avantage de cette version, c'est que la flash+ram étant externe, il sera facile à terme d'avoir plus de combinaisons de flash & ram.
Je me permet d'insister sur le fait que la carte Fox et l'Armadeus n'ont ni les même performances ni les mêmes possibilité (même si , effectivement, il existe une carte optionelle FPGA pour la FOX, l'Armadeus est quand même plus fournie en interfaces et *largement* plus rapide)
D'ailleurs, je n'ai pas trouvé de liens pour acheter ni l'APF9328 ni la devlight ?
Du coup, je ne peux pas comparer selon les prix (la Fox coute 129¤, la carte FPGA en plus coute 99¤, hors frais de ports)
OB
# Carte embarqué
Posté par C. OB (site web personnel) . En réponse au message Débuts en Robotique. Évalué à 2.
Déjà, les 2 cartes que tu cite ne sont pas du tout équivalentes:
La première est basé sur un microcontrolleur AVR (mega8), qui ne peux pas faire tourner Linux, mais qui conviendrais bien pour des petits projet. Il existe des micro OS pour ceux-la, tel que AVRX (http://barello.net/avrx/), utilisé en robotique.
Par contre, aucun traitements algorithmique lourd ne pourra être fait.
L'avantage, c'est que ca consome très peu de courant, important quand le robot est sur batterie.
La seconde est une vrai carte mère, (je la connais bien, je travaille avec), similaire en terme de performances a un petit pentium.
Elle supporte linux sans problèmes, elle a certe très peu de flash embarqué (4Mo) mais les 2 ports USB permettent d'y brancher des clé USB, et de s'affranchir de la limitation de taille. La Ram est suffisante.
Il faut bien voir que c'est 2 facons TRES différentes de programmer : Dans le 1er cas tu disposes de quelques Ko de RAM et Flash, il n'y a pas de notions de processus. A mon avis, c'est TRES bien pour apprendre, pour voir "comment ca marche". Par contre, tu va mettre plus longtemps pour obtenir des résultat, la programmation étant plus difficile.
Dans le 2eme cas (FOX), tu programmeras comme d'habitude, en C sous linux, et tu aura a disposition plus de puissance de calcul, suffisante par exemple pour utiliser une webcam USB et faire un petit algo d'extraction de contours pour la détection d'obstacles.
Dans les 2 cas, l'électronique à fabriquer autour sera sensiblement la même, étant donné que les 2 cartes disposent des ports séries, GPIO, SPI... nécéssaire (La carte FOX a plus de broches, c'est tout)
Pour relier les capteurs et actionneurs, le port série est déjà un peu complexe: En général, tu partirais plutot sur des éléments discret (capteurs ON/OFF, servomoteurs...) ou bien à la rigeur des bus genre SPI ou I2C, c'est le plus simple et le moins cher.
Perso, je me suis fait une carte qui possède les 2 types:
La carte fox s'occupe de la partie Logique, calculs, controle utilisateur, etc " et le controlleur AVR s'occupe plutot des détails de releve des capteurs et du controle moteur.
Les 2 sont reliés par un bus SPI bidirectionel.
La carte ARMADEUS du post ci-dessus ressemblerais plus à la carte FOX, mais sans les composants externes (RJ45, USB...) qu'il faudra donc rajouter. Elle est plus petite, plus rapide, plus chère, et dispose de connecteurs Hirose pas très pratiques pour de la robotique. Elle a une FPGA interne qui, bien que difficile a programmer, est vraiment génial pour executer des algorithmes complexe très rapidement.
Dans le même genre, tu as les Gumstix (http://www.gumstix.com/platforms.html)
Au final, tout dépend de la complexité requise du robot, des possibilités qu'il aura, et du temps que tu as pour dévelloper le soft.
(Pour un simple robot marcheur qui évite les obstacles, la 1ere carte est OK.
Si tu veux en plus mémoriser un trajet, y relier un GPS ou une webcam, il te faudra la 2eme carte)
Voila, hésite pas a me contacter si tu as besoin de précisions.
OB
# Programme libusb
Posté par C. OB (site web personnel) . En réponse au message Utilisation de LibUsb. Évalué à 4.
le fichier "/usr/include/usb.h" doit exister.
sinon, il te faut installer le package libusb-devel
(ou libusb-dev selon la distribution)
Une fois cela fait, regarde la documentation ici:
http://libusb.sourceforge.net/doc/
En particulier, en bas il y a le chapitre "exemple".
Le fichier usb.h est aussi une bonne référence.
Un autre article: http://www.linuxjournal.com/node/7466/print
Encore un: http://www.cs.indiana.edu/~bpisupat/work/usb.html
Ensuite, bah il faut commencer le programme...
Normallement tu dois connaitre le deviceID et le vendorID du periphérique, donc le détecter ca dois ressembler à ca:
int main(void)
{
struct usb_bus *busses;
usb_init();
usb_find_busses();
usb_find_devices();
busses = usb_get_busses();
struct usb_bus *bus;
int c, i, a;
/* boucle sur les bus USB */
for (bus = busses; bus; bus = bus->next) {
struct usb_device *dev;
/* Par bus, boucle sur les devices */
for (dev = bus->devices; dev; dev = dev->next) {
if ((dev->descriptor.idVendor == MYVENDOR) &&
(dev->descriptor.idProduct == MYPRODUCT) ) {
/* boucle sur les configurations, si plus de 1 seule */
{...}
}
}
}
}
Ensuite, ben il faut l'ouvrir, faire un claim, et chercher dans la doc du périphérique USB comment trouver les "paramètres constructeurs" dont tu parles.
Voila !
Regarde aussi si, a tout hasard, ton périphérique n'est pas compatible avec un protocole "standard" USB dont linux a les drivers, style série 'ACM', ou 'HID'.
(Rigole pas ca m'est arrivé....)
A+
# libusb
Posté par C. OB (site web personnel) . En réponse au message Compiler un module avec un noyau 2.6.x. Évalué à 5.
http://libusb.sourceforge.net/
Tu peux tout faire depuis le mode user, et ainsi éviter d'avoir a faire un module noyau, si tu n'a pas besoin de t'interfacer avec un sous-système du noyau (type souris/clavier, video4linux, ...)
La, a priori du controle de carte ca correspond bien, et ca te permet de debugger gentiment, sans planter ton noyau au 1er bug.
En plus, comme la lib est multiplateforme, le source serais facilement adaptable sur un autre unix, voire même windows si nécéssaire.
Normallement, tu dois déjà l'avoir sur la distribution, sinon le nom du package est sans doute libusb-dev ou approchant.
Ca devrais bien aider l'avancement du projet ;-)
OB