![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() |
Desarrollando para Cisco Wireless IP PhoneTuesday, 3 November 2009, 5:35:45 pm Se paraliza el proyecto sobre Cisco IP Phone Debido a que Metro alberga dudas sobre la idoneidad de los terminales (algún problema han tenido cone ellos...) Estado del proyecto ciscotranslator.tcl El traductor entre mundo CISCO y nuestro protocolo está parcialmente implementado. Para producción se ha de ejecutar en la misma máquina que el tctiserver y conectarse a éste por el interfaz lo (es decir, usando la IP 127.0.0.1). Es estos momentos funciona:
ciscpipphoneemu.tcl El emulador de teléfono Cisco IP Phone está parcialmente implementado. Soporta los ficheros XML de texto plano y menús tipo lista (los no soportados los muestra tal cual, igual que se supone que hacen los teléfonos de Cisco). También es capaz de obtener páginas por http. Con esto es suficiente para probar la funcionalidad actual de ciscotranslator.tcl. tctiserver Falta (1) que coja el parámetro cisco:IP de la autentificación y si la petición viene de localhost, localizar dicha IP en vez de localhost. (2) Generar una MAC sintética para que la use ciscotranslator y mandarla en la respuesta a la autentificación en vez de la MAC recibida de ciscotranslator (3) Mandar a los planos que está autorizada la IP propia junto con esa MAC sintética (tctiserver ha de mirar la IP de su extremo de la conexión con el plano y mandar esa al plano). Cómo probar En dario@symbiandevel:~/tctiserver : $ ./sim_tctiserver.sh & $ ./sim_plano.sh En dario@salchicha:~/Programacion/proyectos/sico-ciscotranslator : $ ./ciscotranslator.tcl En dario@salchicha:~/Programacion/proyectos/sico-ciscpipphoneemu : $ ./ciscpipphoneemu.tcl http://localhost:9005/menu Una vez que esté instalado en campo Hay que habilitar en el CallManager un nuevo servicio para los terminales con la dirección http://150.100.122.31:9005/menu . Thursday, 8 October 2009, 6:44:03 pm Sobre hacer un bridge en Linux (brctl and friends) Está documentado aquí. Hay que estudiarlo porque de alguna manera no está funcionando la configuración que he puesto aquí para eso :-?, y eso que si configura las interfaces "normalmente" (es decir, si hago un "/etc/init.d/vmware-common stop" y luego hago que el eth1 de symbiandevel tenga como IP 192.168.2, veo la 192.168.1.100 que es el callmanager). AVISO: He desactivado en symbiandevel el /etc/init.d/vmware-common Update Hay un tutorial específico para bridging con madwifi aquí. Update2: ¡¡FUNCIONA!! Resulta que si hay un dhcp activo sobre el interfaz, el bridging no se puede crear correctamente aunque no da errores. Si se para el dhcp server antes de hacer el bridge, funciona. Para ejecutar el bridge, se hace con: root@symbiandevel:/home/dario# ./br0_setup.sh stop root@symbiandevel:/home/dario# ./madwifi_bridge.sh root@symbiandevel:/home/dario# ifconfig br0:1 192.168.1.1 netmask 255.255.255.0 Update3: Lo he desconfigurado, ya que el teléfono seguía sin encontrar a CallManager a pesar de todo. Además, después he tenido que hacer un: root@symbiandevel# /home/dario/br0_setup.sh stop root@symbiandevel# /etc/init.d/dhcp startPorque el dhcpd no estaba corriendo (y si el bridge está funcionando el dhcp no funciona correctamente :-? ). Wednesday, 7 October 2009, 6:21:50 pm Poniendo la red wifi en marcha Para poner la IP y el bridge en symbiandevel: root@symbiandevel:/home/dario:./br0_Setup.shPara poner la t. de red wifi atheros con driver madwifi en modo "802.11a" (1=802.11a,2=802.11b,3=802.11g): root@symbiandevel# iwpriv ath0 mode 1 Tuesday, 6 October 2009, 5:32:01 pm Usando el CallManager de IG Lo he desvirtualizado, siguiendo estos pasos en symbiandevel: 1. Para desvirtualizarlo ("fisicalizarlo", como dicen ahora) he usado qemu-img (pinchando un disco usando un adaptador USB, comprobando en el dmesg que quedaba en sdb): # qemu-img convert "Red Hat Enterprise Linux 4.vmdk" -O raw /dev/sdbDespués de copiar, hay que quitar y poner el adaptador USB para que reconozla las particiones. Se supone que también se puede forzar que reconozca las nuevas particiones con un: # /sbin/sfdisk -R /dev/sdb 2. Después, como realmente no cabía en un 80GB (¡¡usa 82GB!!), he tenido que usar el fdisk para ver los tamaños actuales (fisk, u, p) y borrar todas las particiones a partir de la 4 (d,6,d,5,d,4) y volverlas a crear (n...) y poner con los tipos que tenían (t...). # fdisk /dev/sdbVolvemos a quitar y poner el adpatador USB para que coja las nuevas particiones 3. Se monta /dev/sdb6 y se hace un tar de su contenido, se formatea y se deshace el tar # mount -t auto /dev/sdb6 /media/floppy # cd /media/floppy # tar -cf - . | gzip -1 > /home/sdb6.tgz # cd / # umount /media/floppy # mkfs.ext3 /dev/sdb6 # e2label /dev/sdb6 /partB # mount -t auto /dev/sdb6 /media/floppy # cd /media/floppy # tar -xpzf /home/sdb6.tgz # umount /media/floppy # rm /home/sdb6.tgz 4. Se pone una password a root para poder entrar como root en el equipo y poner hacer troubleshooting (NOTA: redhat pone shadow como inmutable): # mount -t auto /dev/sdb1 /media/floppy # cd /media/floppy/etc # chattr -i shadow # vi shadow # cambir el campo de password de root # chattr +i shadow # chattr -i passwd # vi passwd # cambir el /sbin/nologin por /bin/bash para root # chattr +i passwd # vi securetty # descomentar todo # vi inittab # reactivar el ctrlaltdel # cd / # umount /media/floppy 5. Y finalmente se regenera un initrd para poder arrancar en un sata: # mount -t auto /dev/sdb1 /media/floppy # chroot /media/floppy bin/bash # mount -t proc - /proc # mv /boot/initrd-2.4.21-47.ELsmp.img /boot/initrd-2.4.21-47.ELsmp.img.orig # mkinitrd --with=libata --with=ata_piix \ NOTA: RHEL4 no soporta SATA en modo AHCI, por lo que en la BIOS hay que ponerlo en modo IDE para que sea capaz de arrancar. NOTA2: También se podía haber modificado el initrd usando este howto para hacer un USB arrancable de RHEL4. NOTA3: Resulta que "tocar" los discos usando una etch no ha sido buena idea, ya que RHEL4 dice que no puede hacer fsck a los discos por tener ext3 unsupported features. # debugfs -w /dev/sdb1 debugfs: feature -large_file debugfs: quit # debugfs -w /dev/sdb6 debugfs: feature -resize_inode -dir_index -large_file debugfs: quit # for i in 1 2 3 6 ; do fsck.ext3 /dev/sdb$i ; doneo bien: # for i in 1 6 ; do echo "features -ext_attr -resize_inode -dir_index" | debugfs -wf - /dev/sdb$i ; e2fsck -yf /dev/sdb$i ; done NOTA4: Resulta que el Call Manager 6.1.3 sólo "intenta funcionar" en ciertas máquinas (The hardware is not supported)... :-/. SIn embargo, resulta que aunque vmware no está soportado, sí funciona (PERO se recomienda usar discos IDE, ya que con SCSI hace "cosas raras"). Para arreglar esto, se ha puesto un "exit 0" en el script "/usr/local/bin/base_scripts/hardware_check.sh". Update 20091007: Al final sí funciona cuando la máquina virtual se usa en chibiko Update 20091009: Por limitaciones de cómo se pueden crear los bridges, se usa el desvirtualizado finalmente. Se ha vuelto a recrear el disco, en chibiko, haciendo: 1. Conversión a un archivo raw del disco vmdk: # qemu-img convert "Red Hat Enterprise Linux 4.vmdk" -O raw disk.raw 2. Reformateado de las particiones del antiguo disco (sdb) sobre el mkfs.ext3: si no se pone el "-I 128", se usa un inode size de 256 que no está soportado por el grub 0.92, ni por el kernel de RHEL4 (!!!). Para ver el "inode size" de un filesystem "tune2fs -l /dev/sdb1" # for i in 1 2 3 6 ; do mkfs.ext3 -I 128 /dev/sdb$i -O none,has_journal,filetype,sparse_super,large_file ; done # e2label /dev/sdb1 / ; e2label /dev/sdb2 /partB ; e2label /dev/sdb3 /grub ; e2label /dev/sdb6 /common 3. Copiado de los datos de la imagen raw al disco recién reformateado: mkdir /tmp/orig /tmp/dest ; for i in 1 2 3 6 ; do echo "Copiando particion $i..." ; mountpartition.sh /home/metro/CallManager/disk.raw $i /tmp/orig ; mount -t auto /dev/sdb$i /tmp/dest ; ( cd /tmp/orig && tar -cpf - . ) | (cd /tmp/dest && tar -xpf - ) ; sync ; umount /tmp/dest ; umount /tmp/orig ; done 4. Instalar el grub en el disco chibiko# mount -t auto /dev/sdb1 /media/floppy chibiko# mount --bind /dev /media/floppy/dev chibiko# mount -t auto /dev/sdb3 /media/floppy/grub chibiko# chroot /media/floppy bin/bash chroot# mount -t proc - /proc chroot# grub --no-floppy grub> device (hd0) /dev/sdb grub> root (hd0,2) grub> setup (hd0) grub> quit chroot# umount /proc ; exit chibiko# umount /media/floppy/grub chibiko# umount /media/floppy/dev chibiko# umount /media/floppy (Poniendo la versión del grub de chibiko en vez de la de RHEL4 para evitar un problema del GRUB de "file or directory not found" al acceder a "(hd0,0)") chibiko:~# mount /dev/sdb3 /media/floppy/ chibiko:~# cd /media/floppy/ chibiko:/media/floppy# mv boot oldboot chibiko:/media/floppy# mkdir boot chibiko:/media/floppy# cd boot/ chibiko:/media/floppy/boot# ( cd /boot/ & tar -cpf - grub ) | tar -xvpf - chibiko:/media/floppy/boot# cp ../oldboot/grub/menu.lst grub/menu.lst chibiko:/media/floppy/boot# rm grub/menu.lst~ chibiko:/media/floppy/boot# grub grub> device (hd0) /dev/sdb grub> root (hd0,3) grub> setup (hd0) grub> quit chibiko:/media/floppy/boot# cd / chibiko:/# umount /media/floppy/ 5. Modificado el contenido de los discos con las instrucciones de arriba ;-). Friday, 25 September 2009, 7:20:48 pm Emulador/Visualizador de Cisco IP Phone XML en tcl/tk He empezado un pequeño simulador del visualizador de XML, para que en cuanto lo tenga hecho, poder empezar a ahcer el servidor. Está en: dario@salchicha:~/Programacion/proyectos/sico-ciscpipphoneemu/ Thursday, 24 September 2009, 7:26:17 pm Librería PERL para hacer Cisco IP Phone Services Cisco::IPPhone Thursday, 24 September 2009, 7:08:38 pm Simulador Según este thread vienen simuladores con algunos libros (Cisco Press book "Developing Cisco IP Phone Services"), o también usando el IP-BLUE's vtgo-pc (vtgo-adv) en versión de evaluación (demo mode: all features enabled, phone calls limited to 2 min, session time limited to 20 min). Es para windows. En último caso, siempre se puede hacer un mini-simulador en tcl/tk, pero no sé si será suficientemente "conformant" a lo que haría el teléfono... Descripción del proyectoSe trata de "portar" la aplicación realizada para telecontrol móvil en Symbian al Cisco Unified Wireless IP Phone 7925G (o al antiguo 7921G, comprar). Se programan en XSI (manual). Básicamente es: eXtensible Markup Language (XML) and X/Open System Interface (XSI). |