Stuck at "Sending data to Octoprint..."

[jamesleemarsh]

I can still connect to my octoprint and control via the monitor tab. but when i goto send a project to the print its gets stuck at "Sending data to Octoprint..."

I have reinstalled octoprint fresh with 0 plugins. I am also running the latest 5.1.1 Cura. im not sure what else to do to trouble shoot as there isn't anything installed to conflict.

Im attaching my logs. any help would be appreciated. and thank you for the hard work to make this all happen. It was really great when it was all working!

octoprint.log serial.log cura.log

[fieldOfView]

From the looks of your octoprint log, it seems something (my plugin?) is sending one or more invalid HTTP headers. Specifically it is complaining that there is no colon in the header. A HTTP header is normally something like Content-length: 100. Unfortunately, OctoPrint does not log the header in question, so it is somewhat hard to diagnose this.

Would you be willing to install a HTTP network sniffer and analyze the traffic between Cura and OctoPrint?

[jamesleemarsh]

sure but id need some help walking through it? do you have discord or anything?

[jamesleemarsh]

I think i did something. i used the sniffer i have in OSX started it tried sending the job and then created a .pcap file but im not allowed to attach it here

[jamesleemarsh]

Im not sure whats breaking it. but i does seem to be intermittent. i went ahead and reflashed another octoprint and kept everything basic no plugins. then it worked for a few prints but then stopped working. but nothing changed other than starting a new print.

[jamesleemarsh]

i used wireshark to try and capture. here is a link to my file. i think youll need to apply this filter "ip.dst == 192.168.1.157 && http" https://drive.google.com/file/d/14RaosW1YhxM7n9FpIGchCxJ0RLFNn4X1/view?usp=sharing

[fieldOfView]

Hey, thanks for going above and beyond to get some packet sniffing data! I was expecting you to just answer "yes" or "no" to the "would you be willing..." question ;-)

I checked out your wireshark log. It does contain traffic to your octoprint instance, but unfortunately there does not seem to be an attempted file upload. I need a capture of what is going wrong,

[jamesleemarsh]

hmm not sure what i did wrong since i took started the recording, then i did a upload, then stopped the record like 30 second after waiting a little bit.

[jamesleemarsh]

im wondering if the problem is on the cura side. is there something that would inhibit CURA from attempting to send the print?

[jamesleemarsh]

looking at a past thread you recommended to restart octopi in safe mode. and i did. so im feeling its a issue with cura for some reason. this is also intermittent. sometimes it will start working but then stop working at some point. i cant narrow down when or what is causing it.

[fieldOfView]

i started the recording, then i did a upload, then stopped the record like 30 second after waiting a little bit.

My bad. By filtering on "http" it seems Wireshark filtered out the POST request. I am seeing it now. When you did the upload, I assume it was not successful?

[jamesleemarsh]

No it wasn’t.

[fieldOfView]

Here's the POST request, which looks legal to me:

POST /api/files/local HTTP/1.1
Host: octomax.local:80
X-Api-Key: CAC9E9CA408847A1BC395B188718A3C9
User-Agent: cura/5.1.1 OctoPrintPlugin/3.7.2
Content-Type: multipart/form-data; boundary="boundary_.oOo._hSOrfNjrgnW1PqhY3V4jE6B7w/31jqwC"
MIME-Version: 1.0
Content-Length: 7795090
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: en-US,*

--boundary_.oOo._hSOrfNjrgnW1PqhY3V4jE6B7w/31jqwC
Content-Disposition: form-data; name="path"
Content-Type: text/plain

--boundary_.oOo._hSOrfNjrgnW1PqhY3V4jE6B7w/31jqwC
Content-Disposition: form-data; name="file"; filename="CE3PRO_Eight Flow Studio
4 slot.gcode"
Content-Type: application/octet-stream

;FLAVOR:Marlin
;TIME:28389
;Filament used: 24.1921m
;Layer height: 0.2
(... etc ...)

What is interesting is that directly after the POST operation is done (over multiple TCP packages), 192.168.1.157 responds with multiple RST ("reset") packages. The POST operation is then repeated, followed by more RST packages:

These RST packages happen in the networking layer that neither Cura nor OctoPrint deal with directly (at the TCP level, not the HTTP level). I am somewhat at a loss why this would happen.

Do you have any sort of non-standard firewall or network setup?

[jamesleemarsh]

nothing different in the last couple years. i use my ISP router.