Autor Tema: HG556a + USB WiFi (TP-Link TL-WN722N) (Leído 56967 veces)

edudi · « **en:** 28-01-2014, 00:58 (Martes) »

Buenas noches a todos, he estado mirando el foro en busca de información referente al asunto y he terminado en las FAQ en concreto "¿ Puedo conectar una tarjeta wifi USB para hacer que mi router actúe como Repetidor ?"

He realizado los pasos por SSH que indicais pero me sale esto:

root@OpenWrt:~# opkg update
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm63xx/packages/Packages.gz.
Updated list of available packages in /var/opkg-lists/barrier_breaker.
root@OpenWrt:~# opkg install usb-utils
Unknown package 'usb-utils'.
Collected errors:
* opkg_install_cmd: Cannot install package usb-utils.
root@OpenWrt:

Estoy actualmente con la versión: OpenWrt Barrier Breaker r36114 , aunque si la última versión me es mejor para esto se la instalo, pero creo que no tiene que ver con lo que quiero hacer.

He probado meterme en el Router por Luci y en el apartado System --> Software --> Actions donde pone "Download and install package:" he puesto "usb-utils" y me sale este reporte de error:

Unknown package 'usb-utils'.

Collected errors:
* opkg_install_cmd: Cannot install package usb-utils.

He intentado hacer lo que podía y he visto que en System --> Software --> Configuration he añadido la ruta de los paquetes actualizados anteriormente vía SSH, dejándolo de esta forma:

src/gz barrier_breaker http://downloads.openwrt.org/snapshots/trunk/brcm63xx/packages
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists/barrier_breaker <-- Esta línea es modificada, la original es "lists_dir ext /var/opkg-lists"
option overlay_root /overlay

Y le he dado a Sumbit, pero naa, sigue igual, le he dejado las dos rutas por si acaso, pero tampoco. Como podréis ver no tengo apenas idea de como es este asunto, pero intento llegar a algún puerto. Debido a la hora que es, he de retirarme, pero agradeceré cualquier aporte y no tengo problema en probar lo que me digais.

Me AUTO-Respondo: Vía Luci se hace fácilmente, una vez que se realice esto:

root@OpenWrt:~# opkg update
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm63xx/packages/Packages.gz.
Updated list of available packages in /var/opkg-lists/barrier_breaker.

Hay que hacer un Reboot al Router, luego tuve que volver a descargar el listado vía Luci y ya me aparecieron todos los paquetes. He instalado el "usbutils" ....les seguiré informando, igual esto le sirve a alguien.

Un saludo y muchas gracias a todos

edudi · « **Respuesta #1 en:** 28-01-2014, 01:10 (Martes) »

Buenas de nuevo, ...el momento friki me superó, encontré el paquete para mi USB WiFi si no estoy equivocado:

root@OpenWrt:~# lsusb
Bus 001 Device 002: ID 0424:2502 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n

Así que busqué este vía Luci:

kmod-ath9k-htc 3.10.28+2013-11-05-5 This module adds support for wireless adapters based on Atheros USB AR9271 and AR7010 family of chipsets.

Lo he ido a instalar y me salido este error:

Upgrading kmod-ath9k-htc on root from 3.7.10+2013-02-22-1 to 3.10.28+2013-11-05-5...
Downloading http://downloads.openwrt.org/snapshots/trunk/brcm63xx/packages/kmod-ath9k-htc_3.10.28+2013-11-05-5_brcm63xx.ipk.
Multiple packages (kmod-usb-core and kmod-usb-core) providing same name marked HOLD or PREFER. Using latest.

Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-ath9k-htc:
* kernel (= 3.10.28-1-5fa07197fdcf2fdb258b3f202ccc0951) *
* opkg_install_cmd: Cannot install package kmod-ath9k-htc.

Voy mejorando..... alguna solución?

Buenas noches y gracias.

jar229 · « **Respuesta #2 en:** 28-01-2014, 08:33 (Martes) »

Mea culpa, en las FAQ estaba puesto el paquete como usb-utils cuando en realidad es usbutils (sin guión).
El problema de las dependencias, también está explicado:

Citar

Dependencias de paquetes con el kernel
Citar
Al intentar instalar el paquete xxx me da error de dependencias con el kernel.
Código: [Seleccionar]
* satisfy_dependencies_for: Cannot satisfy the following dependencies for xxx: * kernel (= 3.6.11-1-9dae866b8f6d8a6cc46cd26eb5d3a5e6) * kernel (= 3.6.11-1-9dae866b8f6d8a6cc46cd26eb5d3a5e6) * * opkg_install_cmd: Cannot install package xxx.

Es un error muy común en OpenWrt. Algunos de los paquetes disponibles en el repositorio de OpenWrt dependen directamente del hash del kernel. Si éste no coincide sólo se pueden instalar con "--force-depends" y no siempre funciona. Cuando los bots recompilan OpenWrt, si ha habido cambios en el kernel el hash cambia, y los firmwares antiguos ya no pueden instalar paquetes dependientes del kernel.
En este foro se da soporte a bastantes router no incluidos en el repositorio oficial de OpenWrt y para ello es necesario modificar el kernel, por lo que en todos los firmwares disponibles en el foro para routers que no están soportados oficialmente por OpenWrt va existir siempre este problema (también sucede lo mismo si se modifica el kernel para añadir nuevas funcionalidades relacionadas con el router, aunque éste ya esté integrado en el repositorio oficial de OpenWrt).

La única solución posible consiste en compilar un firmware propio con los paquetes extra que quieras añadir al kernel (desde un repositorio que disponga de los parches añadidos, o desde el repositorio oficial, añadiendo los parches manualmente).

En el hilo del hg556a tienes varios firmwares con este paquete incluído. Baja e instala uno de ellos.

De todas formas, este router (da igual que tengas el que tiene chipset wifi o ralink) puede actuar como repetidor sin ningún usb externo. Léete el hilo a partir de aquí: https://foro.seguridadwireless.net/openwrt/openwrt-en-huaweig-hg556a/msg300750/#msg300750

edudi · « **Respuesta #3 en:** 12-02-2014, 22:41 (Miércoles) »

Muchas gracias por responder como siempre jar229.

Ya he conseguido por fin usando el último firmware (r39304usb) y algo de comandeo por SSH hace funcionar lo que pretendo:

Tengo varios routers HG556a tanto Ver. A como Ver. C, pero lo que quiero en concreto es usar un único HG556a (la versión que sea) y que reciba por el USB WiFi (cliente) y luego reparta WiFi por el Router (AP).

Lo he conseguido, pero los resultados son pésimos y no logro entenderlo: El router por Luci va a menos dos por hora e internet camina algo pero al poco se queda sin conexión o con un mega lag. Los configuré en canales diferentes para que no se solaparan las WiFi´s, no sé si esto tiene que ver (aunque yo creo que no).

No sé si esto es habitual, creía que al tener dos "radios" diferentes mejoraría la fluidez, ya que no cargo a la única tarjeta WiFi del Router para que esté de cliente y a la vez de repetidor.

Otra cosa que me he dado cuenta y que me ha dejado en 33 más todavía es que ahora la tarjeta del Router llega a los 27dB... esto es bueno aplicarlo? lo puedo quemar? ....... sin embargo el adaptador USB sólo me permite a 20 dB.....ya fuera al revés la verdad, aunque cuando subí todo al máximo ya no conectaba el router de ninguna forma.

¿?¿?¿? alguna observación o aporte¿?

Gracias a todos

jar229 · « **Respuesta #4 en:** 13-02-2014, 08:31 (Jueves) »

Pues con dos wifis distintos el rendimiento debería ser muchísimo mayor.

Muestra la salida del comando dmesg cuando el router lleve ya un rato conectado ... a ver si vemos por dónde pueden ir los problemas

manuelferza · « **Respuesta #5 en:** 24-02-2014, 14:58 (Lunes) »

Hola,

curiosamente yo tengo la misma combinación, y en efecto la transferencia conseguida es pésima.
Estoy utilizando OpenWrt Barrier Breaker r39304 / LuCI Trunk (svn-r9948).

Creo que el problema reside en que al poner la TP-Link, la carga del router se dispara...

Esto son los datos en reposo del router sin la usb:
Mem: 35476K used, 26156K free, 0K shrd, 3836K buff, 11900K cached
CPU: 0% usr 1% sys 0% nic 98% idle 0% io 0% irq 0% sirq
Load average: 0.07 0.73 0.94 2/43 1975

Con la usb:
Mem: 36656K used, 24976K free, 0K shrd, 3836K buff, 11900K cached
CPU: 1% usr 10% sys 0% nic 71% idle 0% io 0% irq 15% sirq
Load average: 1.45 0.84 0.94 1/44 1998
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8 2 root DW 0 0% 7% [kworker/u2:1]
953 1 root S 1652 3% 4% /usr/sbin/wpa_supplicant -B -P /var/r

Solo por el echo de ponerla... Si generas tránsito, la carga aumenta hasta 3 o 4!!

Alguna idea?

bmwjavier · « **Respuesta #6 en:** 07-04-2014, 04:54 (Lunes) »

Hola: ¿Habéis solucionado ya esto? Yo es que tengo un HG556a Ralink con la r39304usb y si repito la señal con la misma tarjeta interna del router la velocidad me baja a la mitad. Pense que solucionaría esto usando un TP-Link Tl-WN722N para repetir la señal pero el resultado fue aun peor. Menos velocidad aún. ¿Por favor que puedo hacer? ¿Es problema del Tl-WN722N? ¿Qué adaptador va bien para repetir la señal sin perder mucha velocidad?

Gracias y saludos,

espeltron · « **Respuesta #7 en:** 07-04-2014, 05:39 (Lunes) »

¿Que canales de radio estais usando?

¿Es posible que la baja velocidad se deba a multiples colisiones de las señales de radio?

¿Podeis hacer la prueba poniendo los canales de radio separados?

Os dejo dos imagenes ilustrativas de los canales de radio:

Hay que tener en cuenta, ademas del canal, si el modo de transmision es b, g o n, y en el modo n el ancho de banda (20Mhz/40Mhz).

Para alcanzar 300Mbps se necesitan:
- 40Mhz de ancho de banda para conseguir 150Mbps
- 2 streams (2 antenas), obteniendo de cada una 150Mbps

Programilla de windows para visualizar los canales de nuestro entorno:
http://www.netstumbler.com/
http://downloads.netstumbler.com/downloads/netstumblerinstaller_0_4_0.exe

Saludos
espeltron

Pteridium · « **Respuesta #8 en:** 07-04-2014, 11:01 (Lunes) »

Cita de: manuelferza en 24-02-2014, 14:58 (Lunes)

Hola,

curiosamente yo tengo la misma combinación, y en efecto la transferencia conseguida es pésima.
Estoy utilizando OpenWrt Barrier Breaker r39304 / LuCI Trunk (svn-r9948).

Creo que el problema reside en que al poner la TP-Link, la carga del router se dispara...

Esto son los datos en reposo del router sin la usb:
Mem: 35476K used, 26156K free, 0K shrd, 3836K buff, 11900K cached
CPU: 0% usr 1% sys 0% nic 98% idle 0% io 0% irq 0% sirq
Load average: 0.07 0.73 0.94 2/43 1975

Con la usb:
Mem: 36656K used, 24976K free, 0K shrd, 3836K buff, 11900K cached
CPU: 1% usr 10% sys 0% nic 71% idle 0% io 0% irq 15% sirq
Load average: 1.45 0.84 0.94 1/44 1998
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
8 2 root DW 0 0% 7% [kworker/u2:1]
953 1 root S 1652 3% 4% /usr/sbin/wpa_supplicant -B -P /var/r

Solo por el echo de ponerla... Si generas tránsito, la carga aumenta hasta 3 o 4!!

Alguna idea?

La verdad es que esto es curioso:

Citar

Esto son los datos en reposo del router sin la usb:
Mem: 35476K used, 26156K free, 0K shrd, 3836K buff, 11900K cached
CPU: 0% usr 1% sys 0% nic 98% idle 0% io 0% irq 0% sirq
Load average: 0.07 0.73 0.94 2/43 1975

Con la usb:
Mem: 36656K used, 24976K free, 0K shrd, 3836K buff, 11900K cached
CPU: 1% usr 10% sys 0% nic 71% idle 0% io 0% irq 15% sirq
Load average: 1.45 0.84 0.94 1/44 1998

Está generando demasiadas sirq (softirqs o interrupciones de software).
Echadle un ojo al fichero softirqs antes y después de conectar el usb a ver cuáles suben escandalosamente.

Código: [Seleccionar]

cat /proc/softirqsY de paso a las interrupciones de hardware:

Código: [Seleccionar]

cat /proc/interruptsY también lo que menciona espeltron: separar los canales de la wifi interna y la externa lo más posible, por ejemplo, interna en el 1 y externa en el 11.
Tampoco se puede descartar un defecto en los drivers ath9k y ath9k-htc.
Muy raro...

jar229 · « **Respuesta #9 en:** 07-04-2014, 12:33 (Lunes) »

Acabo de probar con una nueva compilación (la he colgado en este hilo por si alguien quiere testearla) con un pincho wifi usb de la marca comfast (usa el driver ath9k-htc). El sistema la detecta, pero el rendimiento (la he probado en modo AP) es pésimo

Voy a mirar el tema de las interrupciones software a ver si hay algo raro

bmwjavier · « **Respuesta #10 en:** 07-04-2014, 16:39 (Lunes) »

espeltron gracias por contestar. Lo de los canales lo tengo controlado. No está ahí el problema. jar229, ojala descubras el origen del problema porque a mi me está haciendo polvo. De momento repito la señal por la misma radio interna del router pero si por cable alcanzo 20 Mbps al repetirla a penas llego a 10...

Ojala descubras el problema y pueda usar mi pincho para repetir la señal y que al menos me lleguen 15-17 Mbps

saludos

Pteridium · « **Respuesta #11 en:** 07-04-2014, 18:05 (Lunes) »

Cita de: bmwjavier en 07-04-2014, 16:39 (Lunes)

espeltron gracias por contestar. Lo de los canales lo tengo controlado. No está ahí el problema. jar229, ojala descubras el origen del problema porque a mi me está haciendo polvo. De momento repito la señal por la misma radio interna del router pero si por cable alcanzo 20 Mbps al repetirla a penas llego a 10...

Ojalá descubras el problema y pueda usar mi pincho para repetir la señal y que al menos me lleguen 15-17 Mbps

saludos

Para ir viendo por dónde pueden ir los tiros cuelga en pastebin la salida de estos dos comandos:

Código: [Seleccionar]

dmesg
logread

Luego cuelgo un firm con debug a saco a ver si se ve algo más en caso de hacer falta.

espeltron · « **Respuesta #12 en:** 07-04-2014, 21:21 (Lunes) »

Cita de: bmwjavier en 07-04-2014, 16:39 (Lunes)

espeltron gracias por contestar. Lo de los canales lo tengo controlado. No está ahí el problema. jar229, ojala descubras el origen del problema porque a mi me está haciendo polvo. De momento repito la señal por la misma radio interna del router pero si por cable alcanzo 20 Mbps al repetirla a penas llego a 10...

Ojala descubras el problema y pueda usar mi pincho para repetir la señal y que al menos me lleguen 15-17 Mbps

saludos

No se exactamente en que capa se procesan los paquetes, si en la IP, TCP, UDP, etc. pero tiene toda la pinta de que el cuello de botella lo provoca el servicio que recibe cada paquete y lo reenvia.
Da la sensacion de no tener ningun bufer de paquetes y por eso la velocidad baja a mas de la mitad.
Las latencias del wifi o del puerto USB deben de ser mayores que la de la tarjeta ethernet, por eso la bajada brusca de velocidad.

Es posible que el bufer o cache de cada uno de los canales (transmision y recepcion) sea inadecuado o no se gestione correctamente.
Las aplicaciones como relayd y otras estaran "optimizadas" para tarjetas de red o switchs ethernet, que tienen una latencia muy baja y varios buferes. En dispositivos USB y tarjetas de red wifi la cosa cambia.

Es una idea, igual me equivoco.

Saludos
espeltron

Pteridium · « **Respuesta #13 en:** 07-04-2014, 21:50 (Lunes) »

Cita de: espeltron en 07-04-2014, 21:21 (Lunes)

Cita de: bmwjavier en 07-04-2014, 16:39 (Lunes)
espeltron gracias por contestar. Lo de los canales lo tengo controlado. No está ahí el problema. jar229, ojala descubras el origen del problema porque a mi me está haciendo polvo. De momento repito la señal por la misma radio interna del router pero si por cable alcanzo 20 Mbps al repetirla a penas llego a 10...

Ojala descubras el problema y pueda usar mi pincho para repetir la señal y que al menos me lleguen 15-17 Mbps

saludos
No se exactamente en que capa se procesan los paquetes, si en la IP, TCP, UDP, etc. pero tiene toda la pinta de que el cuello de botella lo provoca el servicio que recibe cada paquete y lo reenvia.
Da la sensacion de no tener ningun bufer de paquetes y por eso la velocidad baja a mas de la mitad.
Las latencias del wifi o del puerto USB deben de ser mayores que la de la tarjeta ethernet, por eso la bajada brusca de velocidad.

Es posible que el bufer o cache de cada uno de los canales (transmision y recepcion) sea inadecuado o no se gestione correctamente.
Las aplicaciones como relayd y otras estaran "optimizadas" para tarjetas de red o switchs ethernet, que tienen una latencia muy baja y varios buferes. En dispositivos USB y tarjetas de red wifi la cosa cambia.

Es una idea, igual me equivoco.

Saludos
espeltron

Tienes razón y fijo que por ahí van los tiros: Florian explicó que los puertos USB de los BCM63XX no soportan unaligned DMA access, y como los paquetes ethernet no son necesariamente de 32bits y a los procesadores MIPS y ARM les cuesta horrores manejar instrucciones y datos desalineados y tienen que tirar de excepciones para poder manejarlos (unaligned intructions and data exceptions) puede provocar una degradación del rendimiento por sobrecarga. De todas formas la gente que le puso un pincho Realtek RTL8187 al HG556 nunca se han quejado de problemas. ¿Culpa del driver por no alinear los datos?

espeltron · « **Respuesta #14 en:** 07-04-2014, 22:52 (Lunes) »

¿Habeis probado a cambiar las configuraciones por defecto de relayd en relayd.conf?

Bueno, no se exactamente como estara implementado relayd en Openwrt, pero en las plataformas BSD es bastante flexible:
http://www.openbsd.org/cgi-bin/man.cgi?query=relayd.conf&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current

Citar

tcp option
   Enable or disable the specified TCP/IP options; see tcp(4) and
   ip(4) for more information about the options. Valid options are:

   backlog number
   Set the maximum length the queue of pending connections
   may grow to. The backlog option is 10 by default and is
   limited by the kern.somaxconn sysctl( variable.

   ip minttl number
   This option for the underlying IP connection may be used
   to discard packets with a TTL lower than the specified
   value. This can be used to implement the Generalized TTL
   Security Mechanism (GTSM) according to RFC 5082.

   ip ttl number
   Change the default time-to-live value in the IP headers.

   [no] nodelay
   Enable the TCP NODELAY option for this connection. This
   is recommended to avoid delays in the relayed data
   stream, e.g. for SSH connections.

   [no] sack
   Use selective acknowledgements for this connection.

socket buffer number
   Set the socket-level buffer size for input and output for
   this connection. This will affect the TCP window size.

   [no] splice
   Use socket splicing for zero-copy data transfer. This
   option is enabled by default.

Ejemplos de configuraciones:
https://calomel.org/relayd.html

Citar

Example 3: TCP Port relay
..
## TCP port relay and forwarder
#
protocol "tcp_service" {
   tcp { nodelay, socket buffer 65536 }
   }

   relay "tcp_forwarder" {
   listen on $box1_addr port $box1_port
   protocol "tcp_service"
   forward to $box2_addr port box2_port
   }
...

La prueba consistiria en aumentar los bufferes y ver como afecta al rendimiento y a la velocidad, hasta alcanzar un valor optimo.

Saludos
espeltron

jar229 · « **Respuesta #15 en:** 08-04-2014, 10:16 (Martes) »

No veo nada raro con dmesg ni con logread

Lo que si puedo decir, es que con el pincho wifi usb con chipset atheros en modo cliente, ni siquiera consigo pasar el test de velocidad de testdevelocidad.es $:-\$

Las prueba, las estoy haciendo con relayd deshabilitado

edudi · « **Respuesta #16 en:** 12-04-2014, 23:19 (Sábado) »

Se ve que en mi último post no puse "Notificarme al haber nuevas respuestas".... si no es xq tengo 30 pestañas del mozilla abiertas desde hace semanas y que andaba cerrandolas ni me entero de que seguían con esta causa. No hay mal que x bien.....

A ver, estuve entretenido la semana pasada con el pincho USB WiFi Blueway de 3W (Ralink 3070) y el HG556a pero el Reaver no cooperó, x desgracia me centré en el Reaver y no intenté el Blueway de Cliente y el Hg556a atheros de AP WiFi (una pena, hubiera estado muy bien saber como se comportaba)

Así que si necesitan que pruebe algo con el TL-WN722N y/o el HG556a, avísenme.

jar229, tenía pendiente pasarles el dmesg del router con este pincho TL-WN722N, aquí lo tienen:

[ 0.296000] number of CFI chips: 1
[ 0.300000] bcm63xxpart: CFE boot tag found with version 8 and board type HW5 56
[ 0.308000] bcm63xxpart: Partition 0 is CFE offset 0 and length 20000
[ 0.316000] bcm63xxpart: Partition 1 is kernel offset 20100 and length 11ff00
[ 0.324000] bcm63xxpart: Partition 2 is rootfs offset 140000 and length e3000 0
[ 0.332000] bcm63xxpart: Partition 3 is cal_data offset f70000 and length 100 00
[ 0.336000] bcm63xxpart: Partition 4 is nvram offset ff0000 and length 10000
[ 0.344000] bcm63xxpart: Partition 5 is linux offset 20000 and length f50000
[ 0.352000] bcm63xxpart: Spare partition is offset 680004 and length 8efffc
[ 0.360000] 6 bcm63xxpart partitions found on MTD device physmap-flash.0
[ 0.368000] Creating 6 MTD partitions on "physmap-flash.0":
[ 0.372000] 0x000000000000-0x000000020000 : "CFE"
[ 0.380000] 0x000000020100-0x000000140000 : "kernel"
[ 0.388000] mtd: partition "kernel" must either start or end on erase block b oundary or be smaller than an erase block -- forcing read-only
[ 0.404000] 0x000000140000-0x000000f70000 : "rootfs"
[ 0.412000] mtd: device 2 (rootfs) set to be root filesystem
[ 0.420000] mtd: partition "rootfs_data" created automatically, ofs=0x670000, len=0x900000
[ 0.428000] 0x000000670000-0x000000f70000 : "rootfs_data"
[ 0.436000] 0x000000f70000-0x000000f80000 : "cal_data"
[ 0.444000] 0x000000ff0000-0x000001000000 : "nvram"
[ 0.456000] 0x000000020000-0x000000f70000 : "linux"
[ 0.468000] bcm63xx-spi bcm63xx-spi: at 0xfffe0800 (irq 9, FIFOs size 542)
[ 0.484000] libphy: bcm63xx_enet MII bus: probed
[ 0.492000] b53_common: found switch: BCM5325, rev 0
[ 0.500000] bcm63xx_enet bcm63xx_enet.1: attached PHY at address 0 [Broadcom B53 (1)]
[ 0.512000] bcm63xx-wdt bcm63xx-wdt: started, timer margin: 30 sec
[ 0.532000] TCP: cubic registered
[ 0.536000] NET: Registered protocol family 17
[ 0.540000] 8021q: 802.1Q VLAN Support v1.8
[ 0.556000] VFS: Mounted root (squashfs filesystem) readonly on device 31:2.
[ 0.564000] Freeing unused kernel memory: 264K (802fe000 - 80340000)
[ 6.748000] eth0: link UP - 100/full - flow control off
[ 8.080000] usbcore: registered new interface driver usbfs
[ 8.088000] usbcore: registered new interface driver hub
[ 8.096000] usbcore: registered new device driver usb
[ 8.112000] Button Hotplug driver version 0.4.1
[ 8.200000] SCSI subsystem initialized
[ 8.220000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 8.232000] ehci-platform: EHCI generic platform driver
[ 8.236000] ehci-platform ehci-platform: EHCI Host Controller
[ 8.244000] ehci-platform ehci-platform: new USB bus registered, assigned bus number 1
[ 8.252000] ehci-platform ehci-platform: irq 18, io mem 0xfffe1300
[ 8.268000] ehci-platform ehci-platform: USB 2.0 started, EHCI 1.00, overcurr ent ignored
[ 8.276000] hub 1-0:1.0: USB hub found
[ 8.280000] hub 1-0:1.0: 2 ports detected
[ 8.292000] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 8.300000] ohci-platform ohci-platform: Generic Platform OHCI Controller
[ 8.308000] ohci-platform ohci-platform: new USB bus registered, assigned bus number 2
[ 8.316000] ohci-platform ohci-platform: irq 13, io mem 0xfffe1400
[ 8.380000] hub 2-0:1.0: USB hub found
[ 8.384000] hub 2-0:1.0: 1 port detected
[ 8.396000] uhci_hcd: USB Universal Host Controller Interface driver
[ 8.420000] usbcore: registered new interface driver usb-storage
[ 8.428000] input: gpio-keys-polled as /devices/platform/gpio-keys-polled.0/i nput/input0
[ 8.600000] usb 1-1: new high-speed USB device number 2 using ehci-platform
[ 8.752000] hub 1-1:1.0: USB hub found
[ 8.756000] hub 1-1:1.0: 2 ports detected
[ 8.964000] jffs2: notice: (255) jffs2_build_xattr_subsystem: complete buildi ng xattr subsystem, 1 of xdatum (1 unchecked, 0 orphan) and 37 of xref (0 dead, 26 orphan) found.
[ 9.276000] usb 1-1.2: new high-speed USB device number 3 using ehci-platform
[ 9.904000] eth0: link DOWN
[ 12.168000] NET: Registered protocol family 10
[ 12.268000] nf_conntrack version 0.5.0 (963 buckets, 3852 max)
[ 12.288000] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 12.336000] fuse init (API version 7.22)
[ 12.356000] Loading modules backported from Linux version master-2013-11-05-0 -gafa3093
[ 12.364000] Backport generated by backports.git backports-20130802-0-gdb67a3f
[ 12.380000] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 12.452000] usbcore: registered new interface driver ums-alauda
[ 12.460000] usbcore: registered new interface driver ums-cypress
[ 12.472000] usbcore: registered new interface driver ums-datafab
[ 12.484000] usbcore: registered new interface driver ums-freecom
[ 12.496000] usbcore: registered new interface driver ums-isd200
[ 12.508000] usbcore: registered new interface driver ums-jumpshot
[ 12.520000] usbcore: registered new interface driver ums-karma
[ 12.532000] usbcore: registered new interface driver ums-sddr09
[ 12.544000] usbcore: registered new interface driver ums-sddr55
[ 12.556000] usbcore: registered new interface driver ums-usbat
[ 12.568000] usbcore: registered new interface driver usblp
[ 12.616000] xt_time: kernel timezone is -0000
[ 12.768000] cfg80211: Calling CRDA to update world regulatory domain
[ 12.780000] cfg80211: World regulatory domain updated:
[ 12.784000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gai n, max_eirp)
[ 12.792000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 20 00 mBm)
[ 12.800000] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 20 00 mBm)
[ 12.808000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 20 00 mBm)
[ 12.816000] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (300 mBi, 20 00 mBm)
[ 12.824000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (300 mBi, 20 00 mBm)
[ 12.832000] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm)
[ 12.860000] PPP generic driver version 2.4.2
[ 12.876000] NET: Registered protocol family 24
[ 12.944000] usbcore: registered new interface driver rt73usb
[ 12.968000] usbcore: registered new interface driver rtl8187
[ 13.020000] usbcore: registered new interface driver zd1211rw
[ 13.156000] usbcore: registered new interface driver rt2800usb
[ 13.200000] usb 1-1.2: ath9k_htc: Firmware htc_9271.fw requested
[ 13.232000] usbcore: registered new interface driver ath9k_htc
[ 13.380000] usbcore: registered new interface driver rtl8192cu
[ 13.432000] PCI: Enabling device 0000:00:01.0 (0000 -> 0002)
[ 13.448000] ath: phy0: eeprom contains invalid mac address: ff:ff:ff:ff:ff:ff
[ 13.456000] ath: phy0: random mac address will be used: 8a:c8:c6:c1:ff:ef
[ 13.464000] ath: EEPROM regdomain: 0x0
[ 13.464000] ath: EEPROM indicates default country code should be used
[ 13.464000] ath: doing EEPROM country->regdmn map search
[ 13.464000] ath: country maps to regdmn code: 0x3a
[ 13.464000] ath: Country alpha2 being used: US
[ 13.464000] ath: Regpair used: 0x3a
[ 13.488000] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[ 13.520000] cfg80211: Calling CRDA for country: US
[ 13.532000] cfg80211: Regulatory domain changed to country: US
[ 13.540000] cfg80211: DFS Master region FCC
[ 13.544000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gai n, max_eirp)
[ 13.552000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 27 00 mBm)
[ 13.560000] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (300 mBi, 17 00 mBm)
[ 13.568000] cfg80211: (5250000 KHz - 5330000 KHz @ 80000 KHz), (300 mBi, 24 00 mBm)
[ 13.576000] cfg80211: (5490000 KHz - 5600000 KHz @ 80000 KHz), (300 mBi, 24 00 mBm)
[ 13.584000] cfg80211: (5650000 KHz - 5710000 KHz @ 40000 KHz), (300 mBi, 24 00 mBm)
[ 13.592000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (300 mBi, 30 00 mBm)
[ 13.600000] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 40 00 mBm)
[ 13.612000] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xc0700000, irq=39
[ 13.884000] usb 1-1.2: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272
[ 14.208000] ath9k_htc 1-1.2:1.0: ath9k_htc: HTC initialized with 33 credits
[ 17.364000] ath9k_htc 1-1.2:1.0: ath9k_htc: FW Version: 1.3
[ 17.372000] ath: EEPROM regdomain: 0x809c
[ 17.372000] ath: EEPROM indicates we should expect a country code
[ 17.372000] ath: doing EEPROM country->regdmn map search
[ 17.372000] ath: country maps to regdmn code: 0x52
[ 17.372000] ath: Country alpha2 being used: CN
[ 17.372000] ath: Regpair used: 0x52
[ 17.472000] ieee80211 phy1: Atheros AR9271 Rev:1
[ 17.484000] cfg80211: Calling CRDA for country: CN
[ 17.532000] cfg80211: Current regulatory domain intersected:
[ 17.544000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gai n, max_eirp)
[ 17.552000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 m Bm)
[ 17.560000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (N/A, 3000 m Bm)
[ 17.568000] cfg80211: (57240000 KHz - 59400000 KHz @ 2160000 KHz), (N/A, 28 00 mBm)
[ 17.576000] cfg80211: (59400000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 40 00 mBm)
[ 20.584000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 22.140000] eth0: link UP - 100/full - flow control off
[ 22.144000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 29.716000] device eth0.1 entered promiscuous mode
[ 29.720000] device eth0 entered promiscuous mode
[ 29.732000] br-lan: port 1(eth0.1) entered forwarding state
[ 29.736000] br-lan: port 1(eth0.1) entered forwarding state
[ 30.708000] eth0: link UP - 100/full - flow control off
[ 31.740000] br-lan: port 1(eth0.1) entered forwarding state
[ 41.084000] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 41.100000] cfg80211: Calling CRDA to update world regulatory domain
[ 41.188000] cfg80211: World regulatory domain updated:
[ 41.192000] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gai n, max_eirp)
[ 41.200000] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 20 00 mBm)
[ 41.208000] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 20 00 mBm)
[ 41.216000] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 20 00 mBm)
[ 41.224000] cfg80211: (5170000 KHz - 5250000 KHz @ 80000 KHz), (300 mBi, 20 00 mBm)
[ 41.232000] cfg80211: (5735000 KHz - 5835000 KHz @ 80000 KHz), (300 mBi, 20 00 mBm)
[ 41.240000] cfg80211: (57240000 KHz - 63720000 KHz @ 2160000 KHz), (N/A, 0 mBm)
[ 42.716000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 42.740000] device wlan0 entered promiscuous mode
[ 45.836000] br-lan: port 2(wlan0) entered forwarding state
[ 45.840000] br-lan: port 2(wlan0) entered forwarding state
[ 45.848000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 47.844000] br-lan: port 2(wlan0) entered forwarding state
[ 85.712000] br-lan: port 2(wlan0) entered disabled state
[ 85.880000] device wlan0 left promiscuous mode
[ 85.892000] br-lan: port 2(wlan0) entered disabled state
[ 93.500000] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 93.508000] device wlan0 entered promiscuous mode
[ 96.768000] br-lan: port 2(wlan0) entered forwarding state
[ 96.772000] br-lan: port 2(wlan0) entered forwarding state
[ 96.780000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 98.776000] br-lan: port 2(wlan0) entered forwarding state
[ 138.512000] wlan1: authenticate with e0:91:53:5e:1a:ae
[ 147.036000] wlan1: send auth to e0:91:53:5e:1a:ae (try 1/3)
[ 147.068000] wlan1: authenticated
[ 147.080000] ath9k_htc 1-1.2:1.0 wlan1: disabling HT/VHT due to WEP/TKIP use
[ 147.088000] ath9k_htc 1-1.2:1.0 wlan1: disabling HT as WMM/QoS is not support ed by the AP
[ 147.096000] ath9k_htc 1-1.2:1.0 wlan1: disabling VHT as WMM/QoS is not suppor ted by the AP
[ 147.140000] wlan1: associate with e0:91:53:5e:1a:ae (try 1/3)
[ 147.152000] wlan1: RX AssocResp from e0:91:53:5e:1a:ae (capab=0x431 status=0 aid=7)
[ 147.368000] wlan1: associated
[ 147.368000] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready

Avisen cualquier cosa, este pincho lo tengo casi "muerto risa" en mi casa.

Por cierto, crearé dentro de poco un post que no va muy desencaminado con algunas cosas aquí comentadas. La bajada de velocidad a la mitad ya me ocurrió en su día al hacer esta configuración:

Router ADSL (x WiFi) + HG556a Ver.C (como repetidor WiFi) + HG556a Ver.C (como repetidor WiFi)
10 Mb ---------> 10 Mb ---------> 5 Mb

Pero para no mezclar lo dejo aquí, ya lo creo en otro momento, ...me pareció un poco raro que nadie hubiera notado nada al hacerla, si es que alguien lo ha hecho o está en algún post que yo no haya leido.

Saludos a todos señores...están en todo

danitool · « **Respuesta #17 en:** 02-05-2014, 21:15 (Viernes) »

Sobre el tema del funcionamiento del USB en general tanto en el HG553 como el HG556a, y posiblemente en otros routers broadcom pongo algunos antecedentes:

- En el HG553 sobre todo lo que ocurría bastante, aunque no siempre es que a veces los dispositivos usb2.0 (aka high speed) eran reconocidos como usb1.0, aunque con el firm original nunca ocurrió.

- En otros routers como Neufbox creo recordar también bcm6358 hay un bug report también en el cual se quejaban de eso mismo

- En el HG556a leí, o eso creo recordar leerlo en este mismo foro, que también a alguna gente le pasó, este reconocimiento defectuoso de la velocidad, aunque otra vez con el firm original eso nunca pasaba

- En las últimas revisiones ya nadie parece quejarse del problema, aunque no sé si es porque se han cansado de reportar el error, o simplemente el reconocimiento dispositivos high speed funciona, aunque eso no querría decir que nos hayamos librado del problema que subyacía detrás.

- Este es el tipo de bugs totalmente aleatorios, a veces pasan o a veces no, en algunos routers se reproducen siempre, en otros siendo exactamente el mismo modelo es irreproducible el problema, y esto hace que nunca se resuelvan del todo.

El caso es que le eché un ojo al gpl publicado recientemente del HG556a, y todo indica a que el firm original tenía un fix que evitaría el mencionado bug.

En su día estuve haciendo pruebas con gente del foro de Openwrt, y cuando tocaban ciertos registros, la cosa se "arreglaba", aunque no estaba claro que es lo que había que tocar ni que hacer concretamente en la dirección 0xfffe150c. Ahora sí lo tengo claro ya que aparece claramente en el gpl de Huawei, y con seguridad esto sería conveniente incorporarlo a los firmwares. Lo pongo a modo de parche:

Código: [Seleccionar]

--- a/target/linux/brcm63xx/files/arch/mips/bcm63xx/boards/board_bcm963xx.c
+++ b/target/linux/brcm63xx/files/arch/mips/bcm63xx/boards/board_bcm963xx.c
@@ -20,6 +20,7 @@
 #include <linux/spi/spi_gpio.h>
 #include <linux/spi/74x164.h>
 #include <linux/rtl8367.h>
+#include <linux/delay.h>
 #include <asm/addrspace.h>
 #include <bcm63xx_board.h>
 #include <bcm63xx_cpu.h>
@@ -4784,6 +4785,16 @@ void __init board_prom_init(void)
 	char *board_name = NULL;
 	u32 val;
 	struct bcm_hcs *hcs;
+	unsigned int * reg = (unsigned int *) 0xfffe150c;
+
+	/* power cycle the USB PLL */
+	if (BCMCPU_IS_6358()){
+		printk(KERN_INFO PFX "Resetting USB PLL...");
+		*reg &= ~0x02000000;
+		mdelay(1);
+		*reg |= 0x02000000;
+		printk("  done\n");
+	}
 
 	/* read base address of boot chip select (0)
 	 * 6328/6362 do not have MPI but boot from a fixed address

No voy a decir que esto arreglará el problema de escaso rendimiento del USB que se comenta en este hilo. Pero desde luego sería lo primero que hay que descartar, dejando el USB en un estado correcto para empezar a funcionar bien.

El que quiera probarlo, lo tiene fácil, hacer los cambios que hay en el parche y compilar.

Personalmente incluí este cambio en el backport a AA 12.09 que tengo colgado en la wiki
http://wiki.openwrt.org/toh/huawei/hg556a#backports

Hasta que alguien confirme que esto arregla algo, obviamente no enviaré ningún parche al mailing list, ni sé si Noltari tampoco querría añadirlo a sus repositorios.

Resumiendo, hacen falta más tests

edudi · « **Respuesta #18 en:** 02-05-2014, 21:40 (Viernes) »

Cita de: danitool en 02-05-2014, 21:15 (Viernes)

El que quiera probarlo, lo tiene fácil, hacer los cambios que hay en el parche y compilar.

Personalmente incluí este cambio en el backport a AA 12.09 que tengo colgado en la wiki
http://wiki.openwrt.org/toh/huawei/hg556a#backports

Hasta que alguien confirme que esto arregla algo, obviamente no enviaré ningún parche al mailing list, ni sé si Noltari tampoco querría añadirlo a sus repositorios.

Resumiendo, hacen falta más tests

Yo me apunto a probarlo ya que tengo ambos dispositivos: HG556a (Ver. A y C) y el USB WiFi (TP-Link TL-WN722N).

Pero necesitaría ayuda, ya que nunca he compilado nada y en linux estoy muy muy verde. Si alguien me pasa los archivos necesarios y los comandos para insertarlo me comprometo a testearlo durante 1 semana mínimo y realizar mis conexiones a internet con el fix añadido. Este hilo lo creé yo y estoy sumamente interesado en que funcione, también he visto que el TP-Link TL-WN722N lo tiene muchísima gente, ya que es atheros, con antena de rosca, muy económico y responde muy muy bien para auditorías (como contra tiene una potencia máx de 100mW, pero es suficiente para una casa de dos plantas).

Si se supone que el link que pusiste es el firm ya compilado con el fix realizado, ya mismo lo flasheo y me pongo manos a la obra. Confírmamelo y con la misma.

Saludos y gracias por los aportes

jar229 · « **Respuesta #19 en:** 02-05-2014, 21:46 (Viernes) »

Quizás lo más sencillo es que empezarás por probar con el backport al que se refiere danitool.

Enviado desde mi CUBE U30GT-H

Noticias:

Autor Tema: HG556a + USB WiFi (TP-Link TL-WN722N) (Leído 56967 veces)

edudi

edudi

edudi

manuelferza

bmwjavier

espeltron

Pteridium

bmwjavier

Pteridium

espeltron

Pteridium

espeltron

edudi

danitool

edudi