Tengo un SM (v7.0.7) registrado a un AP (v4.2.3) una distancia menos a los 100 metros
Previamente se realizo un barrido de frecuencia y no vemos nada que pudiera estar impactandonos
El detalle es que despues de que esta operando sin problemas los servicios detras del SM dejan de funcionar
Cuando esto sucede si puedo dar ping tanto al AP como al SM; inclusive puede establecer una sesion TELNET mas no así una sesion por HTTP
Cómo resuelvo esta situación?
Por telnet aplico reset al AP y posteriormente al SM
Tan pronto levanta nuevamente el SM el servicio del usuario final se restablece
En un principio esto me sucedia una vez por quincena; ahora me pasa todos los días al menos en una ocasion
Y repito, nunca pierdo conectividad tanto al AP como al SM
Cualquier idea es bienvenida
Saludos cordiales
:idea:
Ha que diferencia de altura esta el sm del ap.
Como recomendacion tendrias que tener todo con el mismo firmware.
Si el sm esta muy cerca del ap y el ap esta muy alto, se presenta un cono de sombra cerca del ap, esto es lo que puede estar pasando.
Esto lo podes solucionar, levantando altura en el sm o dandole una inclinacion bastante elevada al sm. Tambien al ap le podes dar una pequeña inclinacion hacia abajo.
Espero tus comentarios.
La distancia es cercana (menos a los 100mts)
El AP esta a 30 mts de altura
El SM esta a 15 mts de altura
Hace sentido lo que dices y seguire tu recomendacion; definitivamente si nos puede o nos esta afectando
Adicionalmente, anexo la respuesta que me envio la gente de tech-support. EN MAYUSCULAS EL FEEDBACK QUE A SU VEZ LES DI
Thank you for your inquiry.
This sound like two seperate issues. The first issue with losing connectivity past the SM sounds like it maybe caused by the ARP cache timout in your router being set to a longer interval than the Bridge Entry Timeout in the AP. INDEED, AP AND SM DEFAULT BRIDGE ENTRY TIMEOUT IS SET TO 25 MINUTES; CISCO FASTHERNET ROUTER IS SET TO 240 MINUTES IT MAKES SENSE YOUR COMENT THEREFORE I MODIFIED AP AND SM BRIDGE ENTRY. TIMEOUT TO 240 … WE’LL SEE HOW IT WORKS
EN BASE A LA TEORIA DE COMO OPERA UN BRIDGE ESTO TAMBIEN NOS PUEDE AFECTAR Y LO COMPROBE HACIENDO UN FLUSH A LA TABLA DE ARP DEL ROUTER. ESPERARE UN PAR DE DIAS PARA VER COMO SE COMPORTA YA QUE ESTA SITUACION ES MUY EVIDENTE
The loss of HTTP access sound like this issue:
Unfortunately, the activity you have described is a known issue with units placed on a public IP addressing scheme. Although the HTTP interface of the radio ceases to function, the unit continues to pass data and all other aspects of the module still respond properly including ftp, telnet and snmp. The suggested workaround for this problem is to place the units on a private IP addressing scheme and utilizing a firewall at the gateway for the network.
IS THIS BEHAVIOR BECAUSE OF A DoS TO PORT 80??? IF THAT’S THE CASE USING A SIMPLE ACL ON THE ROUTER SHOULD WORK INSTEAD OF USING PRIVATE IP ADDRESSING AND A FIREWALL, RIGHT?
WAIT 4 YOUR FEEDBACK
AQUI SIGO PENSANDO QUE LE ESTAN PEGANDO AL AP Y SM POR EL PUERTO 80
If access is required from outside of the wireless network, a remote administration station may be setup. The only alternative workaround available is to login to the unit via telnet once the HTTP interface has locked and issue a ‘reset’ command to reboot the module. This will regain access for a period of time depending on network traffic/accessibility.
BUENO AQUI SOLAMENTE CONFIRMAN QUE LO QUE HEMOS ESTADO REALIZANDO HASTA EL DIA DE HOY ES LO "CORRECTO"
GRACIAS POR TU FEEDBACK LA PROXIMA SEMANA SIN FALTA ACTUALIZARE LA INFO ACERCA DE COMO NOS FUE
SALUDOS CORDIALES
8)