I’m seeing this on our desktops… I think it’s related, and stopping us from accessing our client radios. This “seemed” to start after we upgraded to .13, and now .18 from 4.6.1
ERR_CONTENT_LENGTH_MISMATCH seems like a pretty fundamental error. It means the HTTP headers in the response are indicating a file of one length, but then the response body contains data of a different length.
Are you going through any kind of proxy (either hardware or perhaps ad-blocking software) to get to the radio?
Can you show the headers of one of the failing HTTP responses (from the Network tab of the developer tools)?
If you run curl https://x.x.x.x/cambium.min.39c9a9df17.css from a command prompt, does it succeed? (You may need to add --insecure before the URL if you are using a self-signed HTTPS certificate)
And now, it works… So something on our end must be wonky… We don’t have any proxies that I’m aware of on our network. Only a Cambium QOE box. This was happening on my cell phone via cellular and over Inet access. So, I don’t think it’s our local network (this issue is on a remote network) I’ll keep digging. But, when it happens again I’ll try to run the command prompt and/or check the network tab to see what it sees. It’s a royal PITA, I know that much… I don’t “think” it’s effecting customer traffic though. Which is strange also. And I can ping the cpe the entire time I have issues…
If the ping has been running for a long time, do the times seem stable?
I assume you are accessing these over the radio link. Do you know if you have seen similar issues when using a wired connection?
Are you seeing this across all your subscribers, or only some? If the latter, can you think of any common factor in the radios that are having problems (for example, are they all connected to the same access point)?
The hash in the cambium.min.XXXX.css filenames differs in those two screenshots, so presumably the radios are running different software versions.
Common denominator is that these radio are on a new tower, with new routing segment. The two radio I provided are different. .18, and .13 as I was testing… I can’t downgrade them via cnmaestro due to the http and https setting. And I don’t know how to remove that via a template (a whole other “issue” I have with cnmaestro) I’m still looking at the new tower and paths to see any irregularities. This is MPLS over VPLS. I have another tower segment with the same firmware doing just fine that I can tell. So, this is got me digging harder in to our stuff. I just can’t seem to find it. Maybe an MTU issue I haven’t found yet…
It definitely feels like a lower-layer networking issue. I’d be tempted to set up a script that requests one of those problematic files in a loop and logs the results. Since the problem seems to be intermittent, perhaps it was just a coincidence that curl succeeded.
As far as you can tell, are the radios having any trouble staying connected to cnMaestro?
They seem to stay connected to cnmaestro.
So far. My only fix to this issue is to set the radios to HTTP(S) only… Instantly fixed my ability to login to these radios again… Not sure why though…
That’s very strange. It really feels like something (software or hardware) was interfering with the traffic, and is unable to now that you’ve switched to HTTPS. (Although HTTPS connections would also have different traffic patterns, so it doesn’t necessary rule out something like an MTU issue)
The screenshot in your original message also included something strange - it referred to an https URL (for the logo image) as insecure.
Did anyone else experience the problem, or did it only occur in a single browser on a single device?
Yeah, that didn’t seem to actually fix it. As soon as I changed that setting, it started to work properly. But, shortly there after went back to barely loading the gui.
The only device that should be looking at traffic and doing any manipulating (even though none of that is turned on) is the Cambium QOE box…