My WLAN is a different subnet from my wired lan, my PC is on the wired LAN and the X1c is on the WLAN. It looks to be impossible to send print jobs to the X1C, I get a warning that the X1C must be on the same LAN. What kind of BS is this?
The slicer can see the printer as a device, view the camera, everything. But the Slicer cannot sent a print job to the printer unless they are on the same subnet?
It’s been an age since I had to deal with a combo LAN and WLAN.
Should be able to get it working, it will be in your router settings - other than the printer MUST have internet access to send files from computer. Fun little feature the BL programmers put in there.
I tried a workaround with an isolated WLAN in my house, and no love. The printer must have communication with the mothership.
They seem to define LAN as a single layer-3 segment. I have my Bambus isolated in an IoT segment away from anything else, and where I can apply some microseg, and it doesn’t want to play nice. The only thing that seems to work cross-L3 is MQTT.
FTP, which is what the slicer uses to push files to the SD card, does not allow me to open a data socket when routed. The control channel is fine, but not data.
In LAN only mode, the printer and the slicer shall be on the same LAN.
If the cloud service is used, slicer can send printer job to the printer when they have internet access.
I think the definition of LAN is what’s in question here - It’s not 2002 anymore, so LAN doesn’t always mean subnet, even at home. Why is there a limitation on subnet and routing?
Yes, the definition of LAN shall be updated, there could be VLAN. We need not discuss the definition here. The printer shall be accessable by Studio, such Studio can ping the printer by IP. And the ports for printer communication are listed here: Printer Network Ports | Bambu Lab Wiki
And once that is fully supported, I will be very happy 
Thank you for the article. I hadn’t seen this one yet, but it’s incredibly helpful. I hadn’t seen SSDP used yet, and was operating under the assumption mDNS would be in play.
What is the port 2021 for discovery/multicast being used for? I’m not aware of a standard discovery service that would use that port.
Port 1900 is for multicase, and port 2021 is for broadcast.
Hmm, that’s interesting I see that port 6000 is video streaming in LAN mode ?
So:
Thanks
Just tried, port 6000 is not open, as far as I can see these are the only open ports ??
PORT STATE SERVICE
0/tcp filtered unknown
21/tcp open ftp
1883/tcp open mqtt
3000/tcp open ppp
Port 6000 is for video liveview in LAN only which is used in P1P.
Thanks, but why is the camera stream not enabled on X1 when in Lan Only mode ?
This is not technically difficult and I don’t understand why it is disabled ?
Is this in use? I don’t have any discovery traffic logged by my firewall as of yet. My HomeAssistant is querying SDS on 1900, but the printer doesn’t respond.
I always expected this was part of the reason that Studio couldn’t “send” when not on the local subnet.
X1 has a P2P solution for live video streaming which supports APP on mobile networks. We are investigating to make the solution work in LAN only mode. We also want to make the P2P solution work on P1P, but the biggest challange is the limited processing power and memory size.
The media feature in both X1 and P1P will be optimized.
Thanks so much for updating me Rocky;
I see that the P1P is using a espressif device, would that be an ESP32 ?? - that as you know supports streaming up to 1600x1200.
I have a X1C at home here, and a P1P 10,000km away, I can print to the remote P1P but I cannot see what is happening
I’m familiar with multicast - The source IP would still be the printer and I do not see any multicast traffic originating from either or my printers. I’m observing this from my firewall and my logging is comprehensive.
Pings cross network are never responded - My ping is being routed and sent, but the printer never responds. Both firewall logs and pcaps show the traffic getting to the printer but being unacknowledged (no echo response, no response to a tcp syn).
ICMP left unresponded:
FTP left unresponded:
Longer packet captures and log analysis reveal no multicast traffic originating from the system.
For whatever reason, the only traffic that works to the printer is MQTT:
Let’s try to make the ping command reachable to the printer firstly. Does the printer pass “Test Network” which is at Setting->Network on the screen of the printer? The printer checks the connectivity to the router and Bambu cloud service in this testing. If this test is passed, and the printer still can not been available by ping command from PC. Please have a try to make PC and the printer in the same subnet.
Yes, the test is successful. It can cloud print just fine. And yes, from the same subnet it works perfectly fine.
Ping from the firewall on the same segment:
# /sbin/ping -4 -S '172.30.13.1' -c '3' '172.30.13.26'
PING 172.30.13.26 (172.30.13.26) from 172.30.13.1: 56 data bytes
64 bytes from 172.30.13.26: icmp_seq=0 ttl=64 time=1.824 ms
64 bytes from 172.30.13.26: icmp_seq=1 ttl=64 time=4.029 ms
64 bytes from 172.30.13.26: icmp_seq=2 ttl=64 time=4.384 ms
--- 172.30.13.26 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.824/3.412/4.384/1.132 ms
The device just seems to have some kind of issue with routing some services.
Let’s try to make the ping command reachable to the printer firstly. Does the printer pass “Test Network” which is at Setting->Network on the screen of the printer? The printer checks the connectivity to the router and Bambu cloud service in this testing. If this test is passed, and the printer still can not been available by ping command from PC. Please have a try to make PC and the printer in the same subnet.
As previously reported, yes it works.
I know that will work, but it’s not the condition I want to test.
Otherwise - At some point FTP started playing nice cross-subnet. The issues have been varied, where in some cases the control channel would work and data would fail, but it’s been stable for several days. It’s incredibly strange that the behavior changes without any changes to the network or machine. With the addition of the IP-defined printer feature in the slicer, I can now send with it. Autodiscovery still doesn’t function - There is still no evidence of SSDP traffic.