I am not able to launch the Nokia RDA, Getting this error message:
Unable to initiate server communication. Please verify that you do not have firewall software preventing the Remote Device Access process (javaw.exe) from accessing apu.ndhub.net, TCP port 1,200.
I am afraid how to do this...
In order to use that, Check these requirements
JavaScript must be enabled.
Browser must be Firefox v2+, Internet Explorer v7+, Opera v9.6+ or Safari v3.
Java Web Start must be installed.
If the problem persist, please check your Java installed version is up to date and also your browser belongs to the version required. Hope it helps you.
Related
I am using the webusb API in Google Chrome to try to connect a device to the browser. It worked with webserial API, but I am having trouble getting it to work with webusb API.
I am using HTTPS (Github pages)
I enabled #new-usb-backend for my browser
I can open the device and select configuration, but device.claimInterface(0) is not working (and I can confirm that 0 is an interface number).
None of the two interfaces this device has seems to be claimed
The error I get looking at chrome://device-log is
Failed to claim interface: Access denied (insufficient permissions)
I'm not sure where to go from here. I would appreciate some help.
Thank you.
device.claimInterface(1) worked. I heard somewhere mac automatically claims interfaces. Perhaps the first interface was claimed, although the api indicated otherwise. Anyhow, something about the second interface worked that didn't work in the first.
That error message indicates that there is either an existing driver that has claimed the interface or (Windows only) the WinUSB driver hasn't attached to the interface in order to enable applications like your browser to claim it. On Windows you can use the Zadig tool to force Windows to change the drivers being used for a USB device.
If the device can be opened using the Web Serial API then that indicates that the operating system has already loaded a serial driver for the device and so it has claimed at least some of the device's interfaces.
Why, if the Web Serial API works to connect to your device, are you trying to connect to it with the WebUSB API instead? Are you now on a different operating system which doesn't provide a USB serial driver compatible with the device?
I have several devices that have invalid SSL certificates, mostly old routers,iDRAC,iLO etc.
It now appears to be impossible to access these devices via Chrome and Firefox.
In the past I have been able to add exceptions to access these devices, but I no longer seem to get the options.
Now I understand fully that these devices should be upgraded and I know there are very big risks when ignoring certificate errors, so please do not put a ton of replies telling me to upgrade, as this is not always possible, some of these devices do not any any upgrades available! also how do you upgrade a device that can be upgraded if you cant access it in the first place?
So the question is, is it possible to tell Chrome or Firefox to ignore all SSL/Certificate errors (like invalid certificate or incorrect SSL version), or is there an alternative browser that will work in there place that still allows things like javascript etc to run. I have tried a few browsers in the falcon/surf/hv3 but none of these work.
I cant find any method for the latest versions of chrome and the only thing I could find for firefox was 'security.ssl.enable_ocsp_stapling' and that didn't seem to make any difference :(
I would prefer to use my current install rather than creating a VM and running a totally outdated OS, which also creates problems with SSH and VPN access.
As request, example of error accessing old draytek router via firefox, no option given to bypass:
Secure Connection Failed
An error occurred during a connection to IP-ADDR.
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the web site owners to inform them of this problem.
Chrome error when trying to access HP iLO, get option to ignore, but then get :
This site can’t be reached
The web page at https://IP-ADDR/login.htm might be temporarily down or it may have moved permanently to a new web address.
ERR_SSL_BAD_RECORD_MAC_ALERT
But in general looking to be able to access sites that chrome & firefox have decided in the last year or so that I am incapable of deciding if I trust the site (emphases on the 'I').
Both of these errors do not seem to be related to the certificate at all and can therefore not be solved by ignoring certificate problems. These are not trust problems but these are protocol incompatibility problems.
The problem with HP iLO is likely because the device supports only SSL 3.0 which is insecure for years and thus is not usable in any modern browser and OS. The problem with the Draytek router is not fully clear (there should be more information available in the browser) but it is likely similar, i.e. only SSL 3.0 or some unsupported because insecure cipher like RC4.
One option to deal with these devices is to install some older OS (like Ubuntu 12.04 or even older) in a virtual machine and use the browser from this machine to access the device. And of course note that these devices are long out of support and continued use might cause security risks.
I am developing a webpage that uses camera. When I test in Chrome in my local network, camera doesn't work and I get warning in the console:
getUserMedia() no longer works on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS. See link for more details.
In the link provided there is an instruction to set some flags in Chrome. So I tried. My command looks like this:
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --unsafely-treat-insecure-origin-as-secure="192.168.0.15" --user-data-dir=c:\chrome-dev-profile
But when I run Chrome I get this message:
You are using an unsupported command-line flag: --unsafely-treat-insecure-origin-as-secure. Stability and security will suffer.
What am I doing wrong?
Is there another way I can test in local network without setting up https server? I need this just for development.
Luka,
I've run into this bug just yesterday. I have not found out how to get Chrome to honor that flag on the command line yet. But I did find a workaround that works for my case.
I'm running my web services on a Linux machine that is running an ssh server. I'm testing on windows with chrome, and used putty to connect to the linux box from windows and then created a "local port forward" to make my remote linux box's ipaddress:port appear on localhost:port on windows. Depending on your platform this workaround may work for you. This approach isn't too cumbersome if you only have a few ports to forward.
In my particular case my setting for putty looked like
L8080 localhost:8080
To see more about port forwarding and ssh see: https://help.ubuntu.com/community/SSH/OpenSSH/PortForwarding
When I try to deploy a windows 10 app using remote debugger, I get this error "DEP0100 - deployment failed due to a developer licensing issue windows 10 while trying to remote a windows store app."
From what I understand, there is no concept of windows developer licensing in windows 10, all I have to do is to enable developer mode from settings.
I have still tried to renew developer license using powershell.
Is there any solution for this issue?
PS. Remote debugging was working earlier, it suddenly started giving this error.
Edit: This is happening only when remote debugger is running as a service.
This may seem like a really dumb solution, but I had the same issue and couldn't find what's wrong, until I enabled developer mode and it all worked.
To enable developer mode on Windows 10:
Click Start
Type "For Developers Settings"
Switch to "Developer Mode"
Not sure about this, but make sure the account you're using to run the service is allowed to do developer stuff on your machine.
Here's what I would do:
Generate an account on the machine with admin rights (e.g.
"myadminuser")
Log in as "myadminuser" and enable developer mode for
that account on the machine. (You might have to provide a Microsoft
account here) This will allow the account to install apps.
Configure the service to run with user "myadminuser".
I didn't try this, but this should work.
I've got a web site that uses SSL Client certificate authorization.
All client certificates are generated using OpenSSL and are self-signed. Everything worked with all web-browsers, but the recommended one was Google Chrome, because it uses same SSL warehouse as IE, so certificate installation was pretty easy (click-click-password-done!).
After last update of Google "Chrome 29.0.1547.57 m", noone can access my web-server, even me.
Google chrome error only! IE and FF working fine.
Error is: ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED.
Same in server error log.
Do you have any suggestions?
The problem is that most part of clients are non familiar with PC's and they got very frightened about that situation. So phone support guys are under the wave of calls.
We are experiencing the same problem. As Sean has reported, it seems that Chrome on Windows XP
negotiates TLSv1.2 even though the operating system does not support SHA-2 (say, SHA-256 or SHA-384)
hash function.
We found that Chrome fails when it receives "client certificate request" following SERVER HELLO.
SERVER HELLO itself negotiates RC4-SHA1 (in our environment) which should succeeds. The problematic
packet seems the "client certificate request" that includes SHA-2 (as well as SHA1) functions for hashes.
Invoking Chrome with "--enable-logging --log-level=0" outputs the following message:
ERROR:nss_ssl_util.cc(193)] ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED: NSS error -12222, OS error -2146893816
This is an Operating system error corresponding "NTE_BAD_ALGID" for CryptSignHash function:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380280(v=vs.85).aspx
Disabling TLSv1.2 on the server should fix the problem. But I think Chrome should prefer SHA1 on Windows XP.
I'm experiencing the same thing here with Windows7 client systems unable to authenticate with client certificates against some of our systems, but not others. The affected servers are running Apache Tomcat while the unaffected are running IIS7, though I'm hesitant to identify that difference as the culprit.
Anyone else seeing this?
EDIT:
I'm able to eliminate the problem by disabling TLSv1.2 on the server. Is anyone else able to replicate this experience?
I would also be interested to know whether anyone else is seeing this on anything but the Windows platform, as it's the only place it's happening here (same version OSX has no issues).
EDIT2:
Chrome Bug Report here: https://code.google.com/p/chromium/issues/detail?id=278370
EDIT3:
Should be working again in latest Chrome stable. Chrome 30 will have a more robust fix, but 29.x should also work now.
I recently had a similar issue in Chrome on Mac OS. It worked fine with Firefox, but started failing in Chrome and Safari after changing my corporate (AD) credentials -- I guess the issue was a mismatch between system creds and the keychain creds.
The solution for me was a reset of the private key(s) access permissions in the Keychain Access app.
To do the reset:
In Keychain Access app right-click each private key that fails and select "Get Info".
Go to "Access Control" tab and set "Allow all applications to access this item" -- click on that option even if it's already set. Then click Save Changes.
Refresh the website that fails and you should be prompted to enter keychain password -- enter it and select Allow Always.
It is combination of Win XP and Google Chrome 29.0.1547.57 m
On Win 7/8 this problem doesn't occur.
You could install older working version 28.0.1500.95
http://www.filehippo.com/download_google_chrome/15657/
But settings for disabling updating are not so easy.
http://dev.chromium.org/administrators/turning-off-auto-updates
The problem is caused by Chrome running TLSv1.2 on Windows XP.
This can be disabled on the server side but also on the client side.
To run Chrome with a lower version of TLS, start it with the command-line option --ssl-version-max=tls1.1
I had this problem Connecting Chrome with WebSockets to apache throw proxy_wstunnel_module.
My solution was configuring httpd.conf
ProxyPass /wss2/ ws://127.0.0.1:8080/ retry=0 keepalive=On
ProxyPassReverse /wss2/ ws://127.0.0.1:8080/ retry=0
<Location /wss2/>
SSLRequireSSL On
SSLVerifyClient none
SSLVerifyDepth 1
SSLOptions +StdEnvVars +StrictRequire
SSLRenegBufferSize 10486000
</Location>
Chrome WebSockets does not like the parameter SSLVerifyClient optional
I hope this helps.