Gracias Theliel por la explicación. Lo he entendido perfecto. Te explico lo que vi en el Wireshark y me dices si tiene o no sentido.
Estuve monitorizando el trafico que había navegando por páginas web (todo normal) conectandome a otros PC de mi red (normal también) y por último estuve fijandome en el tráfico que genera el jugar a la consola una partida p2p.
Cuando desde mi consola me conecto a otro usuario, en todos los casos el puerto 3074 es el usado en mi caso. Siempre. No hay ni una sola vez de las que haya monitorizado este tráfico en el que el "source port" sea otro que no sea el 3074 UDP. Sin embargo, el "destination port" si que cambia. Algunas veces también es el 3074 (quizás la mitad de las veces en las que conecto con alguien el destination port es el 3074), pero otras veces no es ese puerto, dándome cuenta que los problemas de conexión entre los dos (lag, delay etc) se dan cuando el puerto de destino es diferente al 3074.
No sé que sentido tiene, pero se me ocurrió que podía filtrar mediante una regla las ip´s de los rivales con los que no conecte a través del puerto de destino 3074, y comprobar así que resultado da. Bueno, si que se me ocurre que pueda darse algún tipo de problemas ya que para las consolas se suele desbloquar el puerto 3074, pero no ningún otro de los que he visto en destino, y al no estar abiertos puede que esté causando estos problemas.
Ya digo que con las pruebas que he hecho monitorizando el tráfico, conectando la consola al PC mediante cable, y el PC por wifi, cuando el puerto de destino es 3074 la respuesta es excelente en todos los casos, pero cuando no es ese puerto, la respuesta no es la misma, a veces sigue siendo buena, y otras directamenet mala.
También decir que durante estas conexiones, la consola no realiza ninguna otra conexión a ninguna otra IP que no sea la de mi adversario. Parece que bloquea todo el resto de tráfico para que no haya lag o retardo durante las partidas...
Bueno. A ver que puedo sacar en claro.
Gracias por seguir permitiendome aprender de estos temas que tanto me gustan.
Buenas Jordycf.
Como digo, una aplicación puede configurarse para usar el puerto que quiera como origen como destino, pero en general nadie preestablece el puerto de origen, porque da un poco igual. La mayoría de juegos usan puertos concretos para poder "hablar" entre ellos, generalmente UDP que tienen menos sobrecarta, y a veces más de uno. La inmensa mayoría de las veces, sobre todo a día de hoy, no es bueno ponerse a abrir puertos, es mucho más efectivo habilitar en el router upnp (que por defecto en el Mitrastar no viene habilitado) para que haga él el trabajo de forma automática.
Quitando esto, que te dé problemas cuando te conectas a otros por un puerto diferente que no sea el tuyo de origen... no tiene en principio mucho sentido. El juego debe de permitir un rango de puertos en los cuales funciona, a lo mejor lo que te sucede es que el juego requiere un rango y tu tienese establecido un puerto abierto tan solo (por poner una posible causa). Pero como digo en principio da igual, si el juego está preparado para usar un rango, pues un rango, informáticamente hablando no hay un problema con que el puerto de origen sea diferente al de destino, no es un "cable" que conecte sólo uno a otro de igual numeración ni mucho menos.
Buenas madralphw
Las únicas reglas que he llegado a ver por defecto en el bridge son el bloqueo DHCP que hace, que se establecen por lo genral cuando se levanta la interfaz WAN por PPPoE, pero es posible que en algunas configuraciones concretas no aparezca.
Por lo que se ve también te afecta el problema de RAM de cfg_manager, demasiada RAM consumida e irá en aumento, un día cascará y necesitarás reiniciar indistintamente. Sobre el uso de CPU si veo bien está precisamente siendo consumida por cfg_manager, y sabe dios en que.
Por defecto no hay problema en el dialplan que vienen preconfigurado con Movistar, pero dices que has cambiado el proveedor, igual te has dejado algo. Ahora mismo no tengo delante el Mitra, pero lo miro luego si quieres, en esta vida todo es posible. Prueba sino en modificarlo
Jordycf lapsus calami, lo siento, falta la s en port: (no es dport, es dports
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 -m multiport --dports 5000:5999 -j DROP
Edito:
Jordycf te puedo confirmar que funciona perfectamente, aun así como te digo dudo mucho que cambie algo, como tu mismo dijiste antes te pareció que funcionaba perfectamente pero no se estaba aplicando:
# iptables -nvL FORWARD Chain FORWARD (policy ACCEPT 851 packets, 208K bytes) pkts bytes target prot opt in out source destination 44 2252 TCPMSS tcp -- * eth0.3285 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 TCPMSS clamp to PMTU 10 280 DROP udp -- * * 192.168.1.200 0.0.0.0/0 udp spt:3074 multiport dports 5000:5999 nping --udp -g 3074 -p 5999 -e eth1 8.8.8.8 Starting Nping at 2015-11-20 16:35 Hora estßndar romance SENT (0.1780s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28 SENT (1.2620s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28 SENT (2.2640s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28 SENT (3.2660s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28 SENT (4.2680s) UDP 192.168.1.200:3074 > 8.8.8.8:5999 ttl=64 id=3230 iplen=28
Jordycf prueba con una de estas:
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000:5999 -j DROP ptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --match multiport --dport 5000:5999 -j DROP
Yo siempre he usado la segunda, aunque en algunas ocasiones la 1º también puede funcionar. Luego en u rato lo compruebo y te digo
djbill excelente noticia, a ver si es posible que alguien nos confirme el estado de ella y le podemos echar el guante pronto.
Según me consta han entregado una versión B22 que soluciona problemas, lo que no tengo claro es si está en proceso de certificación o ya en FOA; a ver si nos hacemos con ella...
Un saludo.
Pues las pruebas de ayer no han tenido mucho éxito. Al parecer por la regla que puse no pasan paquetes.
Os pongo aquí la tabla que me aparece en Wireshark (entendiendo que en Destination me aparece la IP de mi rival).
Esta línea es la que quiero dejar pasar a traves del fix iptables:
| Source | Destination | Protocol | Length | Info |
| 192.168.1.150 | xx.xx.xxx.xx | UDP | 214 | Source port: 3074 Destination port: 3074 |
Y esta sería una de las que quiero bloquear (realmente quiero bloquear el rango de puertos 5000:5999)
| Source | Destination | Protocol | Length | Info |
| 192.168.1.150 | yy.yy.yyy.yy | UDP | 214 | Source port: 3074 Destination port: 5023 |
el fix "iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000-5999 -j DROP" me muestra que no pasan paquetes por él. Por lo tanto entiendo que no está bloqueando nada puesto que la regla está mal puesta...
madralphw, a ver si miro los dial, en realidad no es algo que me sea costoso ir probándolo en el propio mitrastar porque aunq no lo tengo conectado a la línea si le tengo puenteada la conexión y puedo usarlo como ATA, a ver si "robo" uno de los fijos y pruebo.
Soluciones drástricas a las congelaciones sí... siempre sepuede programar por cron un reinicio cada 4-5 días, pero es demasiado drástrico. Estoy intentado lograr lo mismo pero solo reiniciando cfg_manager. Detenerlo y voler a levantarlo es sencillo, pero me está dando problemas a la hora de anidar en el mismo cron más de una instrucción que por alguna razón no lo hace bien... También tengo que comprar el cfg_manager de la B14 con el actual, desensamblarlo y ver si hicieron muchos cambios o puede mas o menos tracearse el problema.
La solución del reinicio completo es que durante unos 30-40 segundos te quedas muerto, la ventaja de hacerlo sólo con cfg_manager es que exceptuando el acceso a la interfaz web del router y alguan cosilla más, no se interrumpe nada, y además es mucho más rápido. A ver si es posible...
Los fichos no son problemas, el tamaño máximo establecido es de 128KB y tienen una rotación de 3, en cuanto estén los 3, el próximo sustituye al más viejo, con lo que ese aspecto si sé que está controlado
Hola Theliel,
Sí, lo modifiqué sólo para que las extensiones 20x fueran para el otro provider y lo el efecto secundario que obtuve fue que las llamadas a fjios/móviles salieran con número oculto (A saber porqué.. )
Probaré este fin de semana con tranquilidad, que el fijo tiene cierto uso para recibir llamadas y tiene que estar disponible. Pero casi prefiero sustituirlo por otro equipo si hay que andar reinciando cada poco.
bb
Pues ha subido unos megas el consumo de ram:
Ayer:
total used free shared buffers
Mem: 125672 47840 77832 0 3192
Hoy:
# uptime
15:48:12 up 1 day, 1 min, load average: 3.55, 3.58, 3.61
# free
total used free shared buffers
Mem: 125672 51624 74048 0 4092b
Ya van tres ficheros de messages:
# ls -last
0 drwxrwxrwx 10 1234 root 0 Nov 19 15:50 ..
104 -rw------- 1 1234 root 106169 Nov 19 15:50 messages
0 drwxrwxrwx 3 1234 root 0 Nov 19 09:01 .
128 -rw------- 1 1234 root 129052 Nov 19 09:00 messages.0
128 -rw------- 1 1234 root 129079 Nov 18 23:39 messages.1
Saludos ;)
Jordycf piensa que la configuración por defecto de todos los juegos es esa, es el juego quien cuando realiza la conexión debería de probar a realizarla hacia todos los puertos del juego si usa mas de uno. Es decir, si el juego requiere para la conexión los puertos 5 y 6, cuando tu te conectas a otro cliente el juego debería de probarlo a hacer tanto por el 5 como por el 6, el propio diseño de juego lo tendría que hacer así. Otra cosa es que el juego esté bugeado, pero el problema lo tendrían TODOS!! no sólo algunos usuarios.
La forma más rápida de ver por donde pasan los paquetes por las reglas es como te ha comentando madralphw, ni siquiera usar la segunda para registrarlo, usa directamente v para listar:
ipables -nvL
La primera/segunda columna te mostrará el número de paquetes/bytes que han pasado por dicha regla, con lo que es fácil ver si se está aplicando o no
madralphw, pero has probado añadir y modificar tu el dialplan?? has probado hacerlo desde el archivo de configuración?? No recuerdo a ver visto ningún bloqueo o limitación en ese sentido
Gracias madralphw en cuanto llegue a casa hoy insertaré un LOG a ver si está bien realizado. Lo he hecho tal cual sale en Wireshark:
Source ip: 192.168.1.150; Destination ip: (la del oponente); Source port: 3074 (siempre es la misma); Destination port: (varia, la mitad de las veces 3074 la otra mitad un puerto entre 5000:5999 que es la que he bloqueado.)
Aunque parece ser que algo hace puesto que como digo se ha incrementado bastante el tiempo durante el que la consola busca oponentes.Digamos que antes, al no filtrar oponentes el "casting" era más rápido, y ahora al bloquear esto pues tarda algo más.
Hola Jordycf,
Puedes poner una regla previa con -j LOG y así puedes en el log (messages) o ejecutando dmesg, puedes ver si hay paquetes que lleguen que coinciden a esa regla. Lo que pasa que si la insertas con -I, sería así:
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000-5999 -j DROP
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000-5999 -j LOG
Saludos ;-)
Pues seguimos avanzando.
Explico un poco el tema de los puertos y que es lo que he hecho y que resultado me ha dado.
Digamos que mi teoría sobre el puerto de destino no la he explicado bien, y creo que si que puede tener influencia en el tema lag, o el retraso que es tan temido por los jugadores. Estos problemas los leo constantemente por todos lados (yo mismo lo sufro a veces) y puede que aquí pueda estar la cuestión.
Cuando tú quieres jugar con una consola o con un PC a un juego en línea, normalmente los fabricantes de consolas o los propios juegos te piden que abras una serie de puertos en el router hacia la IP de la máquina que vayas a utilizar para jugar. Supongamos que tengo una consola en la que me recomiendan abrir el puerto 3074. Esto, hay varias maneras de hacerlo. Puedes abrir el puerto para esa IP (Port Fowarding) puedes desmitalizar la IP de la máquina donde juegas (DMZ), puedes usar UPnP (como recomendó Thelielen su post anterior) y alguna forma más.
Pero el hacerlo de una manera u otra creo que puede tener influencia en la conexión entre jugadores en partidas p2p. Por qué? Pongámonos en el caso de que yo uso UPnP y mi rival (en una partida p2p) tiene abiertos los puertos recomendados por el fabricante de la consola mediante Port Fowarding (puerto 3074 UDP y TCP; 80 UDP y 53 TCP). Si a través de Wireshark yo analizo mi conexión a este rival, y me conecto desde mi puerto 3074 hasta el puerto de destino 5023, mi rival al no tener abierto este puerto 5023 puede estar causando el problema de conexión. No sé si me explico bien, pero esto es lo que llevo observando dos días. Cada vez que me conecto a alguien con puerto de origen y destino 3074, el juego funciona sin problemas (entiendo que este puerto con cualquiera de los metodos de apertura de puertos está siempre abierto sea cual sea mi rival), pero cuando conecto a un puerto de destino diferente (normalmente aparecen rangos 5000-5999), el juego hay bastantes veces que tiene lag o retardo en la conexión, entendiendo así que mi rival usa Port Fowarding y que ese puerto de destino no lo tiene abierto.
Ayer incluí una regla medienate Shell que funcionó bien. Le pedí bloquear al router el trafico a la IP de la consola, cuando el puerto origen era el 3074 UDP y el puerto de destino estaba en el rango 5000-5999.
iptables -I FORWARD -s 192.168.1.150 -p udp --sport 3074 --dport 5000-5999 -j DROP
No sé si es correcta porque no pude monitorizar la conexión el rato que estuve en casa, pero en las 5 partidas que pude hacer, no tuve en ninguna de ellas problemas. Si noté que tardaba más en conectar con alguien pero supongo que será normal por el nuevo requisito que le impuse.
Buenas Theliel,
Para los cuelgues, en mi caso con poner un script que haga un reboot nocturno, voy arreglado... pero para eso prefiero comprar un adaptador de ATA más estable... a este paso no se libra ni la ONT por sustituir... que por cierto se calienta lo suyo. Pero ya que tenga 3-4 procesos consumiendo cpu, me parece excesivo, a pesar de que parezca que tiene 4 cores.
Sobre el dialplan, me gustaría modificarlo, pero no he visto que en la cadena de la configuración falta las llamadas habituales, que si se carga por otro lado que está camuflado. Yo creo que si añado otra proveedor seré capaz de reenviar llamadas utilizando algún prefijo para encaminar las llamadas. De momento está según viene configurado, ya que el primer día que añadí otro proveedor, con un dial plan sencillo de (200|@) que no hice funcionar en ese momento, pues al hacer llamadas externas por movistar salía número oculto y tuve que restaurar a valores de fábrica el router para arreglarlo.
Saludos ;)
muchas gracias theliel.al fin lo he conseguido y nada a ver como se comporta ahora..muchas gracias tio!!
ya teneis un nuevo cachorro entere vosotros!!!!
