What is the problem?
unable to connect to UI from just one PC
iv been uing octopi for ages and all of a sudden today i am unable to connect to it from my pc, i can ping it, login via ssh just not get the webpage to load, i have tried all the browsers on my pc, i can load the page fine on mobile and another laptop just not my pc.
always used static ip to connect
Was thinking could be problem with pc its self but its been off since this morning (connected fine) tried disabling everything still no joy
Static ip of server 1192.168.1.8
Static ip of PC 192.168.1.3
What did you already try to solve it?
reboots, change static ip, safe mode
Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, octoprint.log, serial.log or output on terminal tab, ...)
Octoprint 1.3.8 on octopi 0.14.0
octoprint_(1)[1].log (62.4 KB)
Searching for your PC's IP address in that log I see several of these:
2018-07-01 20:02:01,906 - octoprint.plugins.discovery - WARNING - Can't determine address to user for client ('192.168.1.3', 8428), not sending a M-SEARCH reply
This message appears in the Discovery plugin. I'm not sure if it's involved here but it's saying that it can't find your PC (by name, I'd guess).
try:
while (self._ssdp_monitor_active):
try:
data, address = sock.recvfrom(4096)
request = Request(data)
if not request.error_code and request.command == "M-SEARCH" and request.path == "*" and (request.headers["ST"] == "upnp:rootdevice" or request.headers["ST"] == "ssdp:all") and request.headers["MAN"] == '"ssdp:discover"':
interface_address = octoprint.util.address_for_client(*address)
if not interface_address:
self._logger.warn("Can't determine address to user for client {}, not sending a M-SEARCH reply".format(address))
continue
message = location_message.format(uuid=self.get_uuid(), location="http://{host}:{port}/plugin/discovery/discovery.xml".format(host=interface_address, port=self.port))
sock.sendto(message, address)
self._logger.debug("Sent M-SEARCH reply for {path} and {st} to {address!r}".format(path=request.path, st=request.headers["ST"], address=address))
except socket.timeout:
pass
finally:
self._ssdp_notify(alive=True)
finally:
try:
sock.close()
except:
pass
What kind of PC is it? (Windows 10?)
Try disabling the Discovery plugin, restart OctoPrint and see if things run better, reporting back here.
If tried rebooting in safe mode, that disables all plug ins right?
Windows pc yeah, windows laptop works fine tho
just not get the webpage to load
what exactly happens? Does the browser give you any errors like 400, 404, 500, etc? Does it say the page took too long? Server can't be found? Time out? Anything? Nothing (blank white page)?
If you happen to be using avast antivirus, try turning it off for a minute or 5 (I think those are the options it gives, 1 minute, 5 minutes, until reboot, etc). It's browser / internet protection used to block me from accessing octoprint for some ungodly reason.
What happens if you telnet to the octoprint host from your pc, on port 80 ? i.e.
in a command\powershell window on the pc type:
telnet 192.168.1.3 80 (if that is the IPaddress of the octoprint server)
Windows these days comes with Microsoft Security Essentials (rebranded as Windows Defender).
Nothing, just spins and says "waiting for 192.168.1.8"
Not using avast, but tried disabling AV
just a update, iv tried a brand new image and still cant access UI on my pc, but can on mobile. so guessing problem lies in PC/network
Not sure what to look for now tho
So switching from LAN to Wireless on the PC and UI loads ok.
Check an ifconfig or ipconfig on your workstation with the wi-fi turned on and see if the IP range is again 192.168.1.x.
It's starting to sound like there's a problem with your Ethernet adapter's configuration on the workstation. Perhaps it's an incorrect netmask.
Another explanation would be your physical router doesn't want to move traffic back and forth between wi-fi and Ethernet, explaining the loss of broadcast (Discovery) traffic. Another explanation would be your software firewall on Windows needs to be adjusted to allow that discovery step to happen in reverse.
Also check that there is no entry in hosts file for that ip address pointing to null