yeah that’s my suggestion. How about a unique status and blink pattern on the Glowforge itself to tell you it’s updating firmware
2 Likes
Sometimes I wonder if they just really like getting a lot of tickets about the same thing all the time. It’s kinda of the only answer as to why they keep doing it.
7 Likes
Just been trying to get mine going again after yesterdays first print.
But it states Offline, then goes to Calibrating, makes a few noises, then goes back to Offline and just keeps repeating this process with variable time periods! My Asus router is reporting 144Mbps connection so it isn’t weak signal!
You’ll want to open your own case about this so it gets the attention it deserves and won’t sidetrack @christineharris’s ticket.
I just did a reboot of my wifi router, didn’t touch the GF, and it finally allowed me to print!
So if anyone else is having this problem, just try rebooting your wifi, but leave the GF on. Not a long term solution but it may stop some of the wasted time.
What type or router is it? Is it known to need rebooting?
The way routers work, the connecting device gets an IP address on the LAN that is “leased” for some amount of time before it times out and the device must renew the lease. This is intended to keep your router from using up the limited range of IP addresses with reservations for devices that are no longer on the network. But this feature adds complexity that some devices might not handle as gracefully as possible. And router behavior (what it does when a device goes off line and then on line again quickly) is different from router to router. So you could potentially end up with a bad network configuration if the GF is doing something wrong and the router’s response isn’t handling it right. (for example, I’ve got a device someplace on my network that doesn’t always give up it’s IP address when it’s supposed to, and I get warnings about duplicate IP addresses on my LAN).
You probably don’t need to reboot the entire Router if the problem is a messed up LAN configuration. Most Routers have an administration page you can access from your LAN, typically 192.168.1.1, and you ought to be able to disable/enable the wireless from there without having to go through the more lengthy process of a power cycle and cold restart…
2 Likes
I don’t need to be taught to suck eggs!
The router is an Asus dual band and has performed flawlessly for over a year with all manor of devices that I have, lease time is 24 hours. I have TP Link plugs, Alexa, Netatmo Thermostat, Hue Lightbulbs, Harmony remote, Synology NAS that all are quite happy with the router.
There is to my knowledge, and I have searched, no known router issues, so with the GF being ‘new’, I am fairly certain the problem lies with it!
Just because the router has worked flawlessly up until now does not mean it doesn’t have a problem with whatever the GF is doing. But since you can’t fix your GF, if the problem is the router’s handling of the GF “misbehavior” a restart of the wireless on the router will probably do the trick without having to go through an entire router restart.
As for sucking eggs, I see in another thread your statement that you have some technical expertise. I didn’t see that one until after this one. My thinking was that anyone who’s done significant network management has almost certainly had to deal with devices that did not behave well on an otherwise well-running network. Since you didn’t make any representations to this end in your original post, my offering a vague guess about what might be happening and how to deal with it seemed like it might be helpful. Didn’t mean to piss you off.
If I could make a suggestion for next time, be sure to include a disclaimer to the effect that you know what you’re doing and aren’t looking for basic advice maybe…
4 Likes
Sorry. Am just getting frustrated with the interface being so limited.
I have been a programmer since the early 80’s, started out with 6502 assembler. I have developed commercial applications from initial concepts through design, to finished products. This has included custom tcp/ip & udp stacks with a distributed sub sea control system.
Anyway, I have looked through the logs downloaded from my GF and there seems to be a lot of messages referring to incorrect msg/command sequences, of course these could just be debug messages. I have passed this onto support as hopefully with more information they can resolve these issues permanently.
2 Likes
Haven’t seen those before. Can you share an example?
Lots of these in a row:
2018-04-04_15:57:06.96963 (glowforge:618): GStreamer-WARNING **: /bamboo/xml-data/build-dir/FIR-MAS11-JOB1/poky/build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0/1.4.5-r0/gstreamer-1.4.5/gst/gstpad.c:4655:store_sticky_event:outputselector0:src_0 Sticky event misordering, got ‘segment’ before ‘stream-start’
And the point I think it keeps disconnecting:
2018-04-04_15:58:13.38004 123896 DEBUG: net: websocket interface has address 192.168.0.126
2018-04-04_15:58:13.38009 123898 INFO: settings [13445977]: state=cancelled
2018-04-04_15:58:13.38010 123898 INFO: settings [13445977]: ignoring state “cancelled” on non-existent action
2018-04-04_15:58:13.38011 123902 INFO: settings [13446022]: state=ready
2018-04-04_15:58:26.03280 136560 INFO: WebSocketClient: connection closed
2018-04-04_15:58:26.05046 136563 INFO: net: disconnected
2018-04-04_15:58:26.05050 136563 WARNING: canceling transfer https://app.glowforge.com/api/machines/status
2018-04-04_15:58:26.05050 136564 ERROR: update machine status: url=https://app.glowforge.com/api/machines/status http_code=0, result=42 (Operation was aborted by an application callback)
2018-04-04_15:58:29.03686 139560 INFO: net: requesting socket token
2018-04-04_15:58:40.09949 150626 INFO: socket token request: http_code=200, result=0 (OK)
2018-04-04_15:58:40.12190 150630 INFO: WebSocketClient: connecting to wss://status.glowforge.com:443…
2018-04-04_15:59:29.36783 199892 INFO: WebSocketClient: connection error
2018-04-04_15:59:29.36788 199892 INFO: net: connection error, attempts left: 4
2018-04-04_15:59:32.36896 202893 INFO: WebSocketClient: connecting to wss://status.glowforge.com:443…
2018-04-04_15:59:36.30699 206834 INFO: WebSocketClient: connection established
This one can be ignored. It’s related to a longstanding issue with the camera code. While not pretty, it doesn’t seem to affect operation.
Are there many of the WebSocket connection errors in a row, or just a few scattered over a period of days?
If they are frequent, it may indicate a communication problem between the device and the service.
If they are periodic, like once a day or so, it could just be a random connection drop or indicate the normal expiration of the authentication token. In either case, it will just reestablish the connection and those messages can be considered benign.
1 Like
So far I have only done two prints and I only managed to get the GF online by rebooting my router with the GF still on. The GF still gets the same local IP address as lease is set to 1 day. The router is an Asus RT-AC66U running the latest firmware. The logs show that it usually connects with 3 or 4 attempts left but then they show that it seems to disconnect:
2018-04-04_15:49:25.42415 899730 INFO: WebSocketClient: connection established
2018-04-04_15:49:25.43797 899733 INFO: net: connected
2018-04-04_15:49:25.43803 899734 DEBUG: net: websocket interface has address 192.168.0.126
2018-04-04_15:49:25.86648 900172 INFO: WebSocketClient: connection closed
2018-04-04_15:49:25.88255 900176 INFO: net: disconnected
2018-04-04_15:49:25.88260 900176 WARNING: canceling transfer https://app.glowforge.com/api/machines/status
2018-04-04_15:49:25.88262 900176 ERROR: update machine status: url=https://app.glowforge.com/api/machines/status http_code=0, result=42 (Operation was aborted by an application callback)
2018-04-04_15:49:28.87095 903174 INFO: net: requesting socket token
2018-04-04_15:49:31.56186 905868 INFO: socket token request: http_code=200, result=0 (OK)
This might be a wireless module firmware issue.
They are currently using version 8.9.0.0.76 of the wl18xx firmware. It apparently has a bug that is causing the firmware to randomly core dump. I’m seeing the same problem on my development board (I use a different TI module, but the same firmware. It’s been a thorn in my side, as it is very intermittent.).
TI has apparently resolved the problem in the latest release, though I haven’t had a chance to test it myself:
http://e2e.ti.com/support/wireless_connectivity/wilink_wifi_bluetooth/f/307/p/675405/2494361
If this same issue is affecting the Glowforge factory board (and I assume it to be likely), a simple firmware update from GF should be able to fix it.
EDIT: Looks like the wireless module firmware was updated from 8.9.0.0.69 to 8.9.0.0.76 in Glowforge firmware v1.3.2-16 released on Feb 26, 2018. This was probably done to address the WPA2 vulnerability.
6 Likes
Well I haven’t changed anything, but was able to start up the GF today with no issues at all. Hopefully it will continue.
Have you ever looked in to whether the Glowforge is pingable, and if that changes with how cranky it is being?
I haven’t yet had a problem with a mysterious offline condition, but when I inevitably do I will find the standard voodoo techniques to be dissatisfying. 
I assumed it is because it is a Linux device. I think I can ping every device on my home network. Even the ones I programmed the IP stack myself. I actually coded the ping handler.
It could be disabled but why would you? It’s a standard network diagnostic.
I don’t think it would affect it being cranky but it does show whether it is connected to your router and is still responding.
Since this appears resolved, please open a new post if you have a new question. thanks!