OctoPrint displays fine on my android tablet and windows laptop (chrome). It's the pi/touchscreen device with the issue of halting with the message "browser's error console".
churns through the starting this and startied that
displays the cursor (arrow) in the middle of the screen which follows my finger when I drag
displays the TouchUI background with
a) "connecting to TouchUI"
b) then "Loading OctoPrint"
c) then "Loading TouchUI"
(Displays "Connecting to http://[::1]/" at the bottom of the screen during the above)
then goes away for 30 seconds or so and comes back with "browser's error console" "octoprint.log"
Looking through the log (that is attached) it looks like tornado.access has some sort of issue.
"2020-11-30 21:06:22,474 - tornado.access - WARNING - 403 GET /api/settings (::1) 310.97ms"
Anyone know what's going wrong, and even more important, how to fix it?
I rebuilt my Octopi server to upgrade to 0.18 python3 and to take care of TouchUI failing to load, and ran into this same issue with the rebuild.
Noticed the "connecting to: at the bottom was :1, or a IPv6 Address, and having issues with other PI's and IPv6 I disabled it.
TouchUI started working, but connecting from a web browser on my PC no longer worked...
Reversed the IPv6 disabling, and edited /home/pi/TouchUI-autostart/chromium.xinit
(probably a better way than this, but it worked and I was tired of dealing with this)
a few rows in found:
if [ -n "$(echo $ns | grep 'tcp6 ')" ]; then
OCTOPI=" IPv6"
PORT="80"
echo "TouchUI: haproxy has a listening IPv6 socket."
fi
and changed that to:
if [ -n "$(echo $ns | grep 'tcp6 ')" ]; then
# OCTOPI=" IPv6"
OCTOPI=" IPv4"
PORT="80"
echo "TouchUI: haproxy has a listening IPv6 socket."
fi
stopped and restarted touchui service, watched TouchUI change to "connecting to: localhost" and a few seconds later up it came.
Adding ipv6.disable=1 in /boot/cmdline.txt: made it so the pi does boot up with the TouchUI interface. Thank you for the tip. I then added the lines to sysctl.conf, rebooted, with the same behavior.
My new problem is I can't connect to Octoprint via its IP address in Chrome but I can ping that same IP address and get 0% loss. Apparently I'm using ipv6 somewhere in my home network.
Another tidbit of info is I have a pi camera attached. When I am able to boot to the TouchUI screen (on the pi), the camera fails with an error something along the lines of cannot find the stream. The camera did work fine previously.
You must have caught my first attempt where I found the same thing, edited the post after that when octopi was working but from another machine it was unreachable.
I changed my attempt after posting that, removed the ipv6.disable=1 from cmdline.txt which restored remote access but touchui stopped working again, but I still have the lines in Sysctrl.conf at the moment.
I then made a change to chromium.xinit instead which let both the tft display work as well as remote access work.
Also have a PI camera on mine, leaving the likes in sysctrl.conf let it work as well, when I rolled that change back it stopped working so I put them back.
So to summarize, roll back everything I did when you read the post initially:
No changes to cmdline.txt, if you added ipv6.disable=1 on my recommendation remove it.
added to the end of sysctrl.conf:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
edited /home/pi/TouchUI-autostart/chromium.xinit a few lines in from:
if [ -n "$(echo $ns | grep 'tcp6 ')" ]; then
OCTOPI=" IPv6"
PORT="80"
echo "TouchUI: haproxy has a listening IPv6 socket."
fi
and changed that to:
if [ -n "$(echo $ns | grep 'tcp6 ')" ]; then
# OCTOPI=" IPv6"
OCTOPI=" IPv4"
PORT="80"
echo "TouchUI: haproxy has a listening IPv6 socket."
fi
for me, remote access is working, tft access as well, and my webcam is also working again.
Sorry I created more issues than I solved for myself, tried to edit my post as soon as I found I lost remote access and fixed it.
Glad that worked for you,
Should have held off posting my "success" at getting access initially until I found it broke remote access.
I'm really not sure myself how this all goes together under the covers.
My Linux skills aren't that polished, but I code automation day to day and most languages are quite similar. That and I've dabbled enough to be dangerous (usually to myself) and my google-fu is strong...
No clue why disabling IPv6 breaks remote IPv4 access, but that causes it to attempt to use IPv4 internally which worked, so I figured "something" is making a decision there. Undid what broke remote access and instead since Chromium was loading but failing to connect to a IPv6 address followed that from the end backwards and into the Chromium.xinit.
Saw its checking to see if IPv4 is active and it sets a parameter, then checks IPv6 secondly and sets the same, so I just "cludged" it to always set IPv4 and was glad to see it work.
Likley would have been "cleaner" to reverse the checks maybe so IPv4 was set after IPv6, but it worked, I'm likely to never use IPv6 at home (unless my network gets massive) sohopefully it will work until the next time I need to rebuild it and try to get the touchscreen working again lol.
An update from my side. I did a clean install of the latest and greatest OctoPrint 1.5.3 and OctoPi 0.18.0 and it again wanted to find ::1 and it wouldn't let me past the login dialog.
The fix was to add OCTOPI=" IPv4" in chromium.xinit as before but that's it. Nothing was added to sysctrl.conf or cmdline.txt.
The new setup "feels" smoother. The touch part of the touchscreen seems like it performs a little better. Probably just me.....