Bambu Lab FTP bug: solución con FileZilla en Linux

El bug silencioso que bloquea tu flujo de trabajo con Bambu Lab

Si intentas listar archivos en tu impresora Bambu Lab A1 Mini (o X1C / P1P) desde Linux usando FileZilla, probablemente encuentras un error como «425 Failed to establish connection» que no tiene ningún mensaje de error útil. No es tu configuración. Es un bug confirmado del firmware de Bambu que afecta a modelos desde la versión 01.00.00.00 hasta la 01.04.02.00 en A1 Mini y rangos equivalentes en X1C y P1P.

El problema es técnico pero tiene consecuencias muy concretas: si usas scripts automatizados para enviar archivos G-code a tu impresora, estos fallan sin aviso. Para startups con farms de impresión 3D o makers que automatizan producción en batch, este bug puede traducirse en un 20-30% de tiempo perdido, según hilos en Reddit y los foros oficiales de Bambu Lab.

¿Por qué la impresora Bambu rompe el protocolo FTP?

El protocolo FTP tiene dos modos de transferencia de datos: activo (PORT) y pasivo (PASV). FileZilla, como la mayoría de clientes modernos, usa el modo pasivo por defecto porque es más compatible con firewalls y NAT.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

En modo pasivo, el cliente le pide al servidor (la impresora) que abra un puerto y le diga la IP y el puerto donde conectarse. El firmware de Bambu responde con:

227 Entering Passive Mode (0,0,0,0,XXX,XXX)

El problema está en los primeros cuatro ceros: en lugar de devolver su IP real de red local (por ejemplo 192.168.1.50), el firmware devuelve 0.0.0.0, que es una dirección inválida. FileZilla no sabe a dónde conectarse para transferir datos, y la sesión muere antes de mostrar un solo archivo.

Capturas de tráfico con Wireshark analizadas en el blog de Lantian.pub confirman este comportamiento a nivel de paquetes. La causa raíz es un fallo en el stack de red del firmware embebido (basado en RTOS) que no resuelve correctamente la interfaz de red local al construir la respuesta PASV.

¿Qué versiones están afectadas y cuáles tienen parche parcial?

El bug no afecta a todos los modelos por igual. Este es el estado documentado hasta 2025-2026:

A1 Mini: versiones 01.00.00.00 hasta 01.04.02.00 — afectadas. La versión 01.04.03+ podría tener correcciones parciales, pero no está confirmada universalmente.
X1C: versiones 01.08.03.00 hasta 01.09.03.00 — afectadas. Fix parcial en 01.09.04.00+ (beta 2025).
P1P: versiones 01.08.00.00 hasta 01.09.02.00 — afectadas. Menos reportes activos desde 01.09.03.00+.

Para verificar tu versión: abre Bambu Studio → Device → Firmware Update. Bambu Lab ha reconocido el bug en tickets de soporte, pero sin fecha pública de resolución definitiva para todos los modelos.

Cómo modificar FileZilla para solucionar el problema en Linux

La solución propuesta por Lantian en su artículo técnico consiste en modificar el código fuente de FileZilla para que, cuando detecte una respuesta PASV con la IP 0.0.0.0, la reemplace automáticamente por la IP real del servidor con el que ya estableció la conexión de control.

La lógica es sencilla: FileZilla ya conoce la IP de la impresora (la usó para abrir el canal de control en el puerto 21). Si la respuesta PASV devuelve 0.0.0.0, el cliente puede inferir que debe usar la misma IP del canal de control para abrir la conexión de datos. Este tipo de corrección se denomina fallback de IP y es una práctica estándar en clientes FTP robustos.

Los pasos generales son:

Descargar el código fuente de FileZilla 3 desde su repositorio oficial.
Localizar el módulo que procesa la respuesta del comando PASV.
Añadir una condición: si la IP retornada es 0.0.0.0, sustituirla por la IP del servidor activo en la sesión.
Recompilar FileZilla con las dependencias estándar en Linux (wxWidgets, libfilezilla).
Instalar el binario modificado y conectar con modo pasivo como siempre.

Si no tienes experiencia compilando desde fuente, la alternativa más rápida es usar lftp directamente desde la terminal (ver sección siguiente).

Soluciones alternativas sin tocar el código

Si modificar FileZilla no es una opción en tu flujo de trabajo, estas alternativas funcionan sin parches:

lftp (modo activo): El cliente FTP de línea de comandos más potente en Linux. Ejecuta: lftp -e "set ftp:passive-mode off; ls; bye" usuario@ip_impresora. Funciona porque el modo activo (PORT) no depende de la IP devuelta por PASV.
curlftpfs: Monta el sistema de archivos de la impresora como si fuera una carpeta local: curlftpfs ftp://usuario:pass@ip /mnt/bambu. Ideal para integrar con scripts de automatización.
Forzar modo activo en FileZilla: Ve a Site Manager → selecciona la entrada de Bambu → pestaña Transfer Settings → cambia a "Active mode". No siempre funciona si hay NAT de por medio, pero vale la pena probar.
Cyberduck o WinSCP via Wine: Ambos manejan mejor el fallback de IP, aunque añaden overhead.

¿Qué significa esto para tu startup o proyecto maker?

Si tienes una farm de impresoras 3D o automatizas la producción de prototipos, este bug tiene implicaciones directas en tu operación:

1. Audita tu stack de automatización ahora. Si usas scripts bash, Python o pipelines CI/CD para enviar G-code a impresoras Bambu, verifica si alguno depende de FTP con modo pasivo. Un fallo silencioso en un paso de ls puede romper toda la cadena sin un mensaje de error claro.

2. Migra a la API HTTP de Bambu para automatización crítica. El protocolo FTP fue diseñado en los años 70 y su integración en firmware embebido siempre es frágil. Bambu Lab ofrece un endpoint REST en modo LAN que permite subir archivos G-code directamente:

curl -X POST -H "Authorization: Bearer $TOKEN" --data-binary @modelo.gcode http://ip_impresora/rpc/sdcard/upload

Esta API es más estable, scriptable y compatible con herramientas modernas como GitHub Actions, n8n o cualquier flujo no-code.

3. Documenta la versión de firmware de cada impresora en tu inventario. En una farm, es fácil que algunos equipos queden en versiones antiguas. Mantener un registro evita depurar horas antes de identificar que el problema es de firmware, no de tu código.

4. Evalúa OctoPrint como capa de abstracción. Si tienes impresoras de distintas marcas (Bambu, Creality, Prusa), un proxy OctoPrint en una Raspberry Pi centraliza el acceso y elimina las inconsistencias de FTP de cada fabricante.

Alternativas completas al FTP para transferir archivos a Bambu

Más allá del workaround puntual, vale la pena conocer el ecosistema completo de opciones:

Bambu Studio (Send to Printer): La opción más simple para uso individual. Integrado en el slicer oficial, envía por WiFi con soporte de thumbnails. No tiene CLI puro, por lo que no sirve para automatización.
API REST en modo LAN: La opción recomendada para automatización. Requiere un token de desarrollador que se obtiene enlazando la impresora en la app oficial. Compatible con Python, curl y cualquier herramienta que haga peticiones HTTP.
Tarjeta microSD: Copia física de G-code. 100% confiable, cero dependencia de red. Solo válida para flujos manuales o como backup.
Bambu Network Plugin (LAN-only mode): Descubrimiento y envío dentro de la red local a través del propio ecosistema de Bambu Studio. Más fácil que la API pero menos flexible.

Conclusión

El bug de la IP 0.0.0.0 en el servidor FTP de Bambu Lab es uno de esos problemas técnicos que no se documentan en los manuales pero que pueden paralizar workflows reales durante horas de depuración frustrante. La modificación de FileZilla propuesta por Lantian es elegante y didáctica; pero si tu objetivo es automatizar a escala, el camino más sostenible es migrar a la API REST de Bambu y abandonar FTP como protocolo principal de transferencia.

Lo más valioso de este tipo de análisis no es el workaround en sí, sino entender por qué falla: firmware embebido de calidad variable, protocolos antiguos con comportamientos implícitos y clientes que no manejan edge cases. Conocer esas capas te hace mejor ingeniero y mejor emprendedor tecnológico.