Problema programa FTP

Espera espera,

Si conecto con wifi, no hay ningun problema: al pda se le asigna una IP
privada del rango
192.168.1.X, y salgo con la IP de publica de mi router y va bien.

Si conecto el pda a la base, puedo configurar la base para que se
conecte a traves del PC,
(se crea una nueva conexion de red y asigna una IP del rango 169.254.2.X,
distinta a la de
mi red privada 192.168.1.X) y salgo a exterior con mi IP publica del router,
pero no creo
que mi router sea capaz de manejar 2 rangos de IP, y el servidor dice algo
asi como que no
es capaz de levantar la conexion con la IP 169 Esta Ip es la que no
puedo moficiar porque
si no el PDA no conecta con el PC.

Del GPRS... de momento lo tengo aparcado.

Gracias de todas las formas.

"Alberto Poblacion"
escribió en el mensaje news:

"[Juanjo]" wrote in message
news:%

Creo que el problema esta en lo siguiente. Dentro de mi red uso el
rango de IP 192.168.1.X
pero al PDA le asigna otra IP fuera del rango. El problema es que si
intento asignarle una IP fija
dentro del rango, no sincroniza por lo que no conecta y no navega.

Pero eso, ¿es cuando conectas por wifi o por gprs? 192.168.x.x es una
dirección privada, por lo que no es visible en Internet. Eso significa que
sales al exterior mediante NAT (o un proxy). Conectando por WiFi, si la
configuración es más o menos normal, lo lógico es que tu servidor DHCP te
asigne una dirección dentro del mismo rango. Pero conectando por GPRS, la
dirección te la asigna tu operador de telefonía móvil, y normalmente será
una dirección pública (no una de tu red privada). No debes cambiar esta
dirección, si quieres que tu operador pueda enrutar los paquetes IP de tu
PDA. Lo cual nos lleva de nuevo a la cuestión inicial: puesto que tu pda
se conecta desde una dirección pública, hay que cerciorarse de que el
servidor o servidores FTP a los que te conectas están abiertos a la red
pública (no basta con que estén abiertos a la red privada 192.168.1.x, que
es la que sí te funciona cuando conectas por WiFi). Y cuando decimos
"abiertos" hay que entender "suficientemente abiertos". No basta solo con
el puerto 21 que se usa para hacer login, sino que se necesitan los
puertos >1024 usados para la transferencia de datos. Y esos puertos tienen
que estar abiertos hacia la red pública, no basta con que estén abiertos
hacia la 192.168.1.x.

"[Juanjo]" wrote in message
news:edvDK%

Si conecto el pda a la base, puedo configurar la base para que se
conecte a traves del PC,
(se crea una nueva conexion de red y asigna una IP del rango 169.254.2.X,
distinta a la de
mi red privada 192.168.1.X) y salgo a exterior con mi IP publica del
router, pero no creo
que mi router sea capaz de manejar 2 rangos de IP, y el servidor dice algo
asi como que no
es capaz de levantar la conexion con la IP 169 Esta Ip es la que no
puedo moficiar porque
si no el PDA no conecta con el PC.

Vale, la 169.254... es también una dirección privada (APIPA), usada
entre la base y el PC. El PC hace NAT y sale hacia la red interna con su
dirección 192.168... . Con esa dirección llega al router y el router vuelve
a hacer NAT para salir hacia el exterior con su dirección pública. El router
es inteligente, y su su software NAT es capaz de examinar la instrucción
PORT del protocolo FTP para sustituir (en ASCII) la dirección IP original
(192.168...) por su dirección pública, para que al servidor FTP "vea" la IP
púbica. Por eso te funciona la transferencia FTP cuando tu dirección es
192.168 Pero, por lo visto, el NAT del software del PC que conecta con
la base no entiende el protocolo FTP, por lo que no examina el contenido
interno de los paquetes de datos para cambiar la dirección 169... de la
instrucción PORT. Asi pues, dicha instruccion le llega al servidor intacta,
y el servidor intenta hacer una transferencia de datos hacia la dirección IP
169.254... que viene escrita en el texto del paquete IP, cosa que
lógicamente falla porque se trata de una dirección privada a la que no puede
alcanzar el servidor FTP.
El remedio es usar FTP pasivo, si el servidor lo soporta (enviando desde
tu programa la instrucción PASV en lugar de PORT), con lo que la
transferencia de los datos se inicia desde el cliente en lugar del servidor,
y el NAT previsiblemente será capaz de tragársela correctamente.

Estas cosas solo pasan con FTP y no con otros protocolos, porque FTP
indica la dirección de la transferencia en ASCII en medio del paquete de
datos. El resto de los portocolos, como por ejemplo HTTP, únicamente indican
la dirección remitente en la cabecera de los paquetes IP, que todos los NAT
manipulan debidamente, por lo que el servidor no tiene problema al
contestar.

Muchas gracias por la informacion.

Si uso webservices en vez de ftp sabes si tendre este problema?



"Alberto Poblacion"
escribió en el mensaje news:

"[Juanjo]" wrote in message
news:edvDK%

Si conecto el pda a la base, puedo configurar la base para que se
conecte a traves del PC,
(se crea una nueva conexion de red y asigna una IP del rango 169.254.2.X,
distinta a la de
mi red privada 192.168.1.X) y salgo a exterior con mi IP publica del
router, pero no creo
que mi router sea capaz de manejar 2 rangos de IP, y el servidor dice
algo asi como que no
es capaz de levantar la conexion con la IP 169 Esta Ip es la que no
puedo moficiar porque
si no el PDA no conecta con el PC.

Vale, la 169.254... es también una dirección privada (APIPA), usada
entre la base y el PC. El PC hace NAT y sale hacia la red interna con su
dirección 192.168... . Con esa dirección llega al router y el router
vuelve a hacer NAT para salir hacia el exterior con su dirección pública.
El router es inteligente, y su su software NAT es capaz de examinar la
instrucción PORT del protocolo FTP para sustituir (en ASCII) la dirección
IP original (192.168...) por su dirección pública, para que al servidor
FTP "vea" la IP púbica. Por eso te funciona la transferencia FTP cuando tu
dirección es 192.168 Pero, por lo visto, el NAT del software del PC
que conecta con la base no entiende el protocolo FTP, por lo que no
examina el contenido interno de los paquetes de datos para cambiar la
dirección 169... de la instrucción PORT. Asi pues, dicha instruccion le
llega al servidor intacta, y el servidor intenta hacer una transferencia
de datos hacia la dirección IP 169.254... que viene escrita en el texto
del paquete IP, cosa que lógicamente falla porque se trata de una
dirección privada a la que no puede alcanzar el servidor FTP.
El remedio es usar FTP pasivo, si el servidor lo soporta (enviando
desde tu programa la instrucción PASV en lugar de PORT), con lo que la
transferencia de los datos se inicia desde el cliente en lugar del
servidor, y el NAT previsiblemente será capaz de tragársela correctamente.

Estas cosas solo pasan con FTP y no con otros protocolos, porque FTP
indica la dirección de la transferencia en ASCII en medio del paquete de
datos. El resto de los portocolos, como por ejemplo HTTP, únicamente
indican la dirección remitente en la cabecera de los paquetes IP, que
todos los NAT manipulan debidamente, por lo que el servidor no tiene
problema al contestar.

"[Juanjo]" wrote in message
news:erMYDP%

Si uso webservices en vez de ftp sabes si tendre este problema?

No creo que lo tengas. El webservice usa el protocolo HTTP, que en
teoría debería estar soportado por el NAT que te está fallando.