Recently I am facing an issue with google meet in firefox as well as chrome. In the google meet call the other person cannot hear me and after a few seconds the call disconnects saying network issues.
1] Console shows the above error message.
2] There are no 400 or 500 responses in the Network tab.
3] Happens across both my systems. Pfsense is a firewall I have which I cannot turn off.
Has anybody faced this issue or let me know what can be causing it.
This issue was resolved after purging cloudflare-warp, removing system wide certificates from /usr/local/share/ca-certificates/extra and reinstalling the latest version (at this point 2022.7.x)
Few days ago I had same issue with windows/linux clients behind an enterprise network, using http proxy.
Workaround applied was forcing default mic/cam chrome permissions to "ask(default)", not "allow". Haven't found root cause yet. let me know if it was effective. regards.
Related
When I connect to "script.google.com" (via Chrome) to access my projects, I am getting the following error;
"Something Went Wrong - Please reload the page to try again".
I do the reload but keep getting the same error.
I have tried logging out of Google and back in, shutting down Chrome and starting again but the error still remains. This was working for me less than 24 hours ago and none of my projects are currently listed which concerns me.
What can I do/try to resolve this?
This appears to be a bug!
This was affecting me for a while, though it seems to have rectified itself now. This seemed to go on for maybe a week or two.
That being said, I have taken the liberty of reporting this on Google's Issue Tracker for you, detailing the behaviour:
G Suite Developer Hub Displaying "Something went wrong"
You can hit the ☆ next to the issue number in the top left on the page which lets Google know more people are encountering this and so it is more likely to be seen to faster.
Since yesterday afternoon, I have not succeeded in using Folium to generate maps, even the most basic display function can not be completed, the network connection is normal, it is likely that there is a problem with the call of js.
I tried switching the network environment and trying to change computers, but it didn't work.
Failed to load resource: net::ERR_CERT_DATE_INVALID
leaflet.awesome-markers.js:17 Uncaught ReferenceError: L is not defined
at leaflet.awesome-markers.js:17
at leaflet.awesome-markers.js:122
leaflet.css:1 Failed to load resource: net::ERR_CERT_DATE_INVALID
map.html:39 Uncaught ReferenceError: L is not defined
at map.html:39
#This is the code for the most basic function I've tried.
import folium
m = folium.Map(location=[29.488869,106.571034],
zoom_start=16,
control_scale=True,
width='50%')
m.save('map.html')
I hope to generate map pages
I dont think there is any problem in your jupyter notebook/Python IDLE. Check with your browser. If you’ve determined that the ERR_CERT_DATE_INVALID is caused by an issue on your computer, try these steps to resolve it:
First things first, check the Date and Time set on your computer, if
these are wrong it probably explains how you got the
ERR_CERT_DATE_INVALID error.
Sometimes fixing this error is as simple as shutting down your
browser and then restarting it. Other times a system reboot may work.
However, there are a couple of instances where you’ll need to do a
little more work to set things straight.
Check your connection, if you’re connected to public WiFi or some
other public network there’s a chance that your browser is right and
you don’t actually have a secure connection. If that’s the case, stop
browsing and resume when you’re on a more secure setup.
Scan your computer with a trusted antivirus software, you may have
malware of some sort that is causing the issue. Unfortunately we
can’t provide you with info on how to fix every last piece of
malware, but if your antivirus can’t, someone on the internet
probably knows.
Disable any third-party plugins you have running on Chrome. Sometimes
these can cause unwanted problems.
Clear your browser cache on Chrome. Click the menu icon, open History
and select “clear browsing data.”
Delete and then re-install Chrome. Sometimes this helps.
There are a few other crazy fixes like bringing down your firewall or
modifying network settings. However I would not suggest this one since your PC then become susceptible to virus.
Saw this error a few times today in Chrome's developer tools, and trying to figure out what it means / what we can do to avoid it.
"Failed to load resource: net:: ERR_CERT_DATABASE_CHANGED"
This was causing some image urls to fail to load in our testing. Fwiw I just checked the cert for the site in question, and it was issued over a year ago and is valid until the end of 2016, so it doesn't look like any changed serverside.
Google search turns up pretty much nothing for this error message, so hoping Stack Overflow will have more answers.
So the best I've been able to discover is this: https://chromium.googlesource.com/chromium/src/net/+/master/spdy/spdy_session_pool.cc and a few related tickets in Chromium about this code. It would appear that when the system cert database changes - in my case, potentially just a crappy puppet policy double checking that only trusted certs are in our store - Chrome reacts by closing down all existing connections and returning network errors to any outstanding request.
I had the same problem.
You may have Kaspersky Antivirus installed.
The Kaspersky software is manipulating the system keychain frequently (sometimes many times a second), which is causing Chrome to flush connections, because the system trust store has changed.
You can try it:
Remove Kaspersky;
disable Kaspersky web traffic interception
I also found a page with a description of the bug https://bugs.chromium.org/p/chromium/issues/detail?id=925779#c29.
I am making a Windows Phone 8.1(winrt flavor) application and stuck in problem about PushNotification.
await PushNotificationChannelManager.CreatePushNotificationChannelForApplicationAsync();
This function returns PushNotificationChannel and it usually works well. But in some our devices, this function throws 0x880403E9 error.
MSDN says,
0x880403E9 The notification platform is in the process of reconnecting back to the WNS cloud due to a earlier network connectivity change. Apps should retry the channel request later using an exponential back-off strategy.
I think retrying the request can never solve this problem. The function always throws the exception. During a month. We even implemented exponential retrying strategy.
The worse fact is, the our broken devices worked well with the function before. But once it has been broken(?) by mysterious reason, it is never fixed itself. -First time we've got this problem, we did factory-reset the device and the problem fixed. But in other devices, reset was not a solution.
Somebody says updating lastest version might solve this problem, but it is not. Even in Windows Phone 8.1 Update 1(8.10.14157.200), the problem still occurs.
Is there anyone know about this problem?
Microsoft answered this question via email.
The problem happened when,
you don't have USIM card or
exhausted your data or
3G/LTE network does'nt work by some problems
Even if you are connected to network with wifi, the problem still occurs. I think Windows Phone 8.1 is always trying to process the push notification by 3G/LTE network if you turn 3G/LTE data network on.
If you can't use 3G/LTE network by given reasons, try to turn off data connection at system settings. Then push notification will be proceed via wifi network.
And they said, this is not going to be fixed even in Windows Phone 8.1 GDR2. Could be with Windows 10.
I had this problem as well and the answer above fixed it.
Just want to add that there might be a problem with roaming as well. I´m working in another country then my own and I got this problem. So if the three points above is ok, check that you are not using data roaming.
I'm having some issues with Chrome canceling some HTTP requests and I'm suspecting cached authentication data to be the cause. Let me first write down some important factors about the application I'm writing.
I was using Basic Authentication scheme for some time to guard several services and resources in my web app.
In the meantime I was using/testing the app heavily using Chrome with my main Google Account fully synced. Most frequently I was using my name - "lukasz" - as the username in Basic Auth.
Recently I have switched my application to use Digest Authentication.
Now, some of the HTTP requests I'm making are failing with status=failed with no apparent reason. It only happens when I'm using user "lukasz", if I enter some other unique username - there is no problem.
I looked everywhere in the backend and frontend and I couldn't locate the issue to be in our code. I can easily reproduce this with user "lukasz" each time. So I reverted my code to Basic Auth (while not touching the rest of app) and the problem was gone.
That led me to think that there is something wrong with cached passwords. So I cleared the cache in Chrome, but that didn't help. After several hours of analyzing the issue I decided to make sure that I'm running fresh instance of Chrome, so I reinstalled it (deleting the disk data along the way). TADAAA! The problem was gone and I couldn't reproduce this anymore.
Then I synchronized my Google Account with this newly installed Chrome and after a short while the requests to my app started failing again!! So I took a deeper look at this (cleaning profile data from disk and redoing all the steps) and indeed it looks like the problem starts as soon as my account is synced with cloud!
Yes, I know it sounds dodgy. It sounds ridiculous. It sounds stupid. But I am almost sure that those two problems are somehow related (failing requests and account sync).
My idea is this: Chrome somehow remembered that I was using "lukasz/my-pass" with Basic Auth for certain services. After I switched to Digest Auth the same combination of credentials (lukasz/my-pass) is now acting funny. Perhaps under the hood Chrome still thinks that this is Basic Auth and cancels requests when it learns otherwise?
UPDATE:
I've did some low level debugging with chrome://net-internals/ and it appears that the problem is while reading cache entry. This seems to prove my initial assumption.
I did some investigation and found this article. Apparently always adding "Last-Modified" header to my http response has solved the issue in Chrome (I'm still having some problems in FF, but that's off topic).
However, it still doesn't solve my issue entirely. Why the requests were failing in the first place?
You could try using incognito mode and see what happens. It may give you some hints without having to clear the cache or re-installing Chrome.
Also take a look at How to clear basic authentication details in chrome