Find below logs from about webrtc while checking with trickle ICE.
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/
ICE(PC:{f8be271e-a104-46d0-9666-1f5c4804b8e3} 1673540416421000 (id=6442450948 url=https://webrtc.github.io/samples/src/content/peercon): failed to resolve candidate relay(IP4:192.168.14.18:58951/UDP|IP4:0.0.0.0:3478/UDP).
Tried with other browsers on the same machine but did not face any issues. Cannot generate relay candidates in firefox browser alone. Even tried after reinstalling the browser.
In wireshark packet trace, I can see that there is not STUN request from the browser to the TURN server.
Related
Using https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ on Firefox 102.6.0 ESR and gathering the wireshark traces shows that for each STUN server configured, there are 2 outgoing requests per network interface. The same behavior is observed in my app using WebRTC.
Is there a specific point to why Firefox does it twice everytime?
I have a setup which involves devices connecting to a server via web sockets. I'm experiencing a strange problem where they can connect to one test server without issues, but cannot connect to a different server (hosted on Azure).
I've installed Wireshark on both of them, and can watch both the successful connection and the unsuccessful connection. It appears that the unsuccessful one attempts to initiate an SSL handshake.
Here is the successful connection:
Here is the unsuccessful connection:
It seems like the client in the successful connection is simply setting up an HTTP web socket, but in the unsuccessful setup it's try to set up a secure connection.
Why would the client be setting up different connections depending upon the server address?
The client code to create the websocket is just javascript, invoking new Websocket(address), and in both cases the address begins with the 'ws' prefix.
I have done some further investigation and found another weird behavior. As it happens, there are two domain names pointing to the same server.
If I used the domain name with the top level domain "com" (XXXX.australiaeast.cloudapp.azure.com), then the connection works.
If I used the domain name with the top level domain "dev" (comutername.mydomainname.dev) then the connection fails, with the weird TLSV1 packet.
Both works fine if I run the same client code on the Microsoft Edge browser.
This appears to be a defect in Chrome's implementation of The WebScoket API
I have posted a defect here, let's see how it goes. https://bugs.chromium.org/p/chromium/issues/detail?id=1067076
The issue in play here is HTTP Strict Transport Security (HSTS)
A browser can be configured so that certain domains have an HSTS policy attached, meaning any insecure link will automatically be converted to a secure link.
This policy will be applied if a request returns a Strict-Transport-Security header. But, and here's the significant bit, the Chrome and Firefox browsers automatically apply the policy to all dev domains.
It appears that up until recently, the Chrome browser and Chrome OS was not observing the policy with regard to WebSocket connections. This has changed, and now WebSockets will observe the HSTS policy.
The upshot is, if you have a websocket using the ws protocol and not the wss protocol, and it's on a .dev domain, your Chrome and Firefox browser will not be able to connect to it.
I've had a problem with Fiddler ever since my machine was upgraded from Windows 7 to Windows 10. If I configure Fiddler to decrypt HTTPS traffic, any traffic it captures is, for lack of a better word, killed.
For example, if I visit the (HTTPS) page that documents configuring HTTPS decryption, without Fiddler, I see it as normal:
However, once I begin capturing traffic, and reload the page, I get this:
All of the responses feature this same exception message:
I only use Fiddler occasionally, when I need to see what's going into and out of my apps. I could've sworn I was able to do this with HTTPS before migrating to Windows 10. I'm not sure what changed, but Fiddler has become fairly useless to me now that all the traffic it captures fails. Any help would be appreciated.
I have Wireshark 2.4.6 installed on macOS High Sierra. For some reason, Wireshark is not capturing any HTTP traffic across my machine. I have explicitly opened multiple webpages on a browser and filtered for HTTP traffic, but I am not able to see any HTTP packets.
I have an Ubunbtu virtual machine on my computer. When I booted that and opened webpages on it, I was able to see the corresponding HTTP traffic on Wireshark (which runs on my host macOS itself).
Why can I not see HTTP traffic for websites I open on macOS browsers? Does macOS treat HTTP differently somehow (if that is even possible)?
Make sure that you are accessing websites bound with http but not https
The reason behind this is https is 'http secure' which ensures secure communication over a network and hence it undergoes encryption and decryption end-to-end, so wireshark won't be able to capture them. Instead you can search for TLS/SSL in the search bar and voila!, you would be able to see them since https is secured with either SSL or TLS.
And yes, the next question that might confuse you is why is wireshark able to capture packets when I run an 'HTTPS' site on a virtual machine?
It's because of OCSP(Online Certificate Status Protocol)(I'm very much sure that when you were able to capture HTTPS packets when browsing on a virtual machine, you would have observed OCSP too). So, over here, OCSP tells you that X.509 certificates(used in both SSL and TLS) have been revoked since they were compromised, so putting it in simple terms, data has been decrypted and the certificates have been compromised.
P.S: I tried the above in Kali Virtual Machine, but I do think it's the same for Ubuntu.
I am developing a windows phone app.I am sending parameters[POST] to a server.There is no response from server.I found that the error is "error getting http web response".Why is this problem occuring?
There is a response from server , when I send parameters and check response with the help of "Postman" plugin for chrome .
I use following 2 approaches how to troubleshoot such problems.
Set up the debugger so it will break on .NET exceptions. Most likely, you'll stop on a WebException. In the debugger you'll see a lot of exception's properties, containing more information on what has failed and why.
Install Wireshark, capture your Internet-facing NIC, run your app in the simulator, observe your app’s network traffic (type HTTP in filter, press Enter, then right-click on packets and select “Follow TCP stream”). Most likely, you'll see some HTTP error code in the response from your server.
P.S. Postman plugin for chrome / opera's built-in dragonfly / IE's built-in developer tools are rarely useful in such cases. There're too many differences between desktop and mobile browsers. Even worse, many web servers usually send different things to mobile clients.