I just setup a custom domain for an AWS API Gateway and set up CNAME entries in Google Domains to redirect to my API Gateway. After maybe 30 minutes of waiting I was able to use Chrome to do a simple GET request to my custom domain that properly forwarded to my API Gateway. I tested in Firefox and it worked fine too.
About 3-4 hours later I came back and tried making the same call using Python requests and it worked the first 3 times then failed.
SSLError: HTTPSConnectionPool(host='ids.references.app', port=443): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError("hostname '<my_custom_domain>' doesn't match '*.execute-api.us-east-2.amazonaws.com'")))
At first I thought this was a requests problem, but then I opened up Firefox and it didn't work as well. I tried Edge and the call worked. Then I went back to Python and it worked for a bit, then stopped working. I went back to Firefox and it no longer worked. Then I tried Edge and it no longer worked. Sprinkled in there I've tried Chrome and it has worked every time since it started working. (this order of events is from memory and may be slightly off).
Is this a known issue with updating DNS entries that you get some randomness when things first start until the DNS changes have fully propagated. How would I go about even tracking where the error is occurring? I think that's the most frustrating thing about this, it all seems like magic and there's no obvious point where you get something like server 1.2.3.4 says that cert_1 doesn't go with cert_2 and then later you see something like server 4.5.6.7 says cert_2 is all good (so it works). Would I need to install curl for Windows (Is is possible to make a cURL request and get the route that is taken (similar to traceroute)). Would this even matter though? What if curl was like Chrome, it always worked? Does requests have this functionality (bonus points if someone can show a requests solution)? What about Firefox or Chrome? Or could I use something like wireshark (yikes) that could somehow observe the whole system?
I'm using requests 2.25.1 and Python 3.8.5 on Windows 10 and I believe the latest versions of Edge and Firefox.
Related
I'm trying to get my head around SNMP for a project I'm working on. After I failed miserably getting it to work in my company's network, I set up a simple 3-device network to test things on, consisting of two Windows 10 PCs and a manageable switch between them.
I installed the optional feature "SNMP" on both PCs, made sure the service is running correctly and configured both services to accept SNMP queries from each other. I made sure to open up UDP port 161 in both PCs firewalls. Then I got the Net-SNMP binaries in order to use SNMPGET and SNMPWALK. As an alternative, I set up the SNMP extension for PHP through xampp (since I want to use PHP in my project once I get SNMP to work). Finally, I installed wireshark to monitor what exactly is going on and this is what I found:
When I try SNMPGET or SNMPWALK either through cmd or as a PHP command, I always get a timeout message. Wireshark is showing the get-next-request leaving one PC and arriving correctly on the other, so the network connection itself is working fine. But the receiving PC never sends a response. As I said, I'm pretty new to SNMP and I'm at a loss as to why this is happening. As I understand it, the optional feature for Windows 10 comes with its own SNMP agent, correct? If so, what could cause it to simply ignore an incoming request from a valid source IP?
The funny thing is that this even happens when I try to send an SNMP query to 127.0.0.1. I have no idea what I'm doing wrong...
Thanks to the comment of Lex Li, I was able to finally figure out which step I made a mistake with:
When setting up the SNMP service, under the security tab, I had to add 'public' as an accepted community name (with READ-ONLY rights). I figured since 'public' is sort of the standard read-only community, it would be accepted by default, which apparently it is not.
Alternatively, I guess I could have added my own communtiy name, but I didn't try that since I only want to read some values through SNMP anyways and read-only access is all I need for that.
Thank you very much Lex Li, I'm off to continue my project now!
I want to log everything firefox send to a server, down to every exact byte so I can reproduce it in a python client. So my idea was to make a quick and dirty hack :
run a openssl s_server,
make firefox connect to localhost by adding a line in my /etc/hosts.
This shouldn't have taken more than 5 seconds to setup, run, remove.
My issue is on the firefox side. First, it doesn't allow me to add a security exception. Second, even when I add one in about:preferences#advanced > Certificates > View certificates > Servers, it changes nothing and show me the error SEC_ERROR_UNKNOWN_ISSUER anyway.
How do I make firefox ignore the certificate error?
Is there another quick and easy way to log SSL traffic?
The easiest way I found was to use firefox's SSLKEYLOGFILE environment variable and configure wireshark to use this file to decrypt the HTTP requests.
This is all explained here:
https://jimshaver.net/2015/02/11/decrypting-tls-browser-traffic-with-wireshark-the-easy-way/
However, care must be taken to clear the cache for the website so that firefox actually send the requests and don't use the cached result.
My app was rejected today due to 'not supporting IPv6'. I've attached screenshots of the error they received which comes from a Parse.com API call.
I could really use some help on this, as I have no clue where to start with this.
Does anyone know if Parse.com supports IPv6? Or do I need to add something to my code? Do I need to migrate to Parse Server?
Please help =\
---- EDIT ---- 9/22/16
OK so, after my first rejection due to "IPv6" issues, I re-submitted and the app was approved. I'd still like to understand if Parse.com and Parse Server are officially IPv6 compatible but as for now, I'm just happy my app was approved. I'll keep this thread open and will edit it when I find the answer.
I have a parse server hosted on Heroku which doesn't support IPv6 yet (see here). But your server is not the reason why the app is rejected. It is your app which should support IPv6.
A possible solution is to download the latest Parse framework from https://github.com/ParsePlatform/Parse-SDK-iOS-OSX/releases/tag/1.14.2 and replace the old ones. I think it should work.
Below is my comparison with the logs in the console for my app with the two different versions of Parse framework.
I have used Parse.framework and Bolts.framework from Feb 2016 in my Apple TV app and also just got rejected also for not supporting IPv6. I checked the log and found that
nw_resolver_start_crazy_eyeballs_timer Received IPv4 result first, performing crazy eyeballs: waiting 50ms on IPv6 for myapp.herokuapp.com:0.
__nw_resolver_start_crazy_eyeballs_timer_block_invoke Crazy eyeballs timer fired: did not receive IPv6 in time, reporting only IPv4 result for myapp.herokuapp.com:0
nw_resolver_cancel_crazy_eyeballs_timer Cancelling crazy eyeballs timer for myapp.herokuapp.com".
It seems the performance issue comes from the 50ms when the app loads.
I use the latest Parse framework and no "crazy_eyeballs_timer" shows up. The log seems more promising because I can see a IPv6 address in the log now.
nw_resolver_create_dns_service_on_queue Starting host resolution myapp.herokuapp.com:0, flags 0x4000d000
nw_resolver_host_resolve_callback flags=0x3 ifindex=0 error=NoSuchRecord(-65554) hostname=myapp.herokuapp.com. addr=0.0.0.0:0 ttl=60
nw_resolver_host_resolve_callback flags=0x2 ifindex=0 error=NoError(0) hostname=us-east-1-a.route.herokuapp.com. addr=88:ffff::bbbb:afb9.0 ttl=74
Here I changed the addr of my server in the log for security reason.
I will send a new update of my app to review and I believe that it should work. I will leave a comment when it gets accepted :)
I have completed Google's form to enable my device to be whitelisted and have been provided with an AppID.
I have followed the procedures outlined here to try and debug the device with no success:
https://developers.google.com/cast/developing_your_receiver#debugging
I am able to ping my device by the IP, but connecting to port 9222 results in failure. Telnet to that port is also unsuccessful.
Does anyone know why this might not be working? I must be missing something simple.
The problem was that my Chromecast device was not sending the serial number to Google.
I was able to get it to work by enabling the sending of the devices serial number in the Windows settings utility (changing this setting in the android app didn't seem to work). After changing the setting I rebooted the device, and now I can connect on port 9222. I am not sure why this isn't in the developer walk through... or maybe I missed it?
I only got this option when I opened "Options" in the Google Cast Extension inside Chrome and then clicked on the blue icon about a dozen times very quickly. Suddenly a new option appeared at the bottom where I could enter the hostname of my whitelisted URL:
I also made sure that "send serial number" was enabled in the Chromecast.app (and make sure to reboot!)
Now, I am able to hit port 9222 in a browser and can see my app at http://{my-chromcast-ip}:9222/. I can use dev tools in Chrome to debug, refresh the page, inspect on-screen elements, etc.
Something else that I haven't seen others mention yet. If you're going to the right IP and getting the link to remote debugging, but you don't see your source, elements, etc. It could be blocked by security settings. This stumped me for a while until I noticed a small shield icon in my url bar. Click on this and allow it to load sources. Once I did that everything populated as expected.
I struggled a bit with this one. I think some things might have changed with the last firmware update on the Chromecast. I could connect to port 9222 after I did the following:
Registered the custom receiver and host it on the outside of my network (on Google Drive:
https://support.google.com/drive/answer/2881970?hl=en)
Launch the receiver. I used the Chromecast example https://github.com/googlecast/CastHelloText-chrome
Make sure the app ID in chromehellotext.html is the one registered on your account.
When After this, I could connect to the debugging port.
The port is only open when your custom receiver is running on the Chromecast.
I also might be useful to enable debugging on the chrome extension. This will show what's going on between the Chromecast and sender:
https://developers.google.com/cast/docs/chrome_sender
I realize that this is an ancient question, however my answer might help people searching in the future.
Simply rebooting the Chromecast after having set up my details in the Cast console helped for me.
You must cast to a custom receiver first (at least once) before trying to access the IP with debug port. Otherwise debugging won't be enabled.
We are attempting to connect to a WebDAV server using net use over SSL. On some servers we're seeing an issue in which this connection only succeeds if we specify port 443 in the URL.
Does Map
net use * "https://example.com:443/folder"
net use * "\\example.com#SSL#443\folder"
and, bizarrely, so does this:
net use * "\\example.com#SSLasdf\folder"
Does Not Map
net use * "https://example.com/folder"
net use * "\\example.com#SSL\folder"
In the non-working cases we consistently receive the following error:
System error 67 has occured.
The network name cannot be found.
We have noticed some things that might be useful information:
We have a test server that's configured the same way as the prod server and it works as expected.
In the non-working cases, no incoming requests are ever seen at the prod server from the failing host.
All clients are based on the same image.
The problem does not manifest uniformly on all clients -- some work, some don't.
There is an existing, valid entry for example.com in the client DNS cache.
Flushing the client DNS cache of the affected servers does not resolve the problem.
Once the problem appears, it seems to stick. That is, if I execute one of the working mappings, delete it, and then immediately execute one of the non-working mappings, the problem persists.
We are utterly stumped. Any theories?
You are seeing different behaviors because you are connecting using different names. Once a name has been attempted and failed, the WebClient (this is the service that enables WebDAV) will cache the response for a period. To clear the cache, locate the WebClient service in the Services console and restart it. Or from an administrative command prompt execute the following command:
net.exe stop webclient && net.exe start webclient
We ultimately determined that we were mis-interpreting the System Error 67 that net use was returning. We discovered two interesting things:
In the event that the WebDAV returns a 404 or a 50x on the initial, root folder PROPFIND, net use will (rightly) interpret this as the root folder being unavailable. The fact that it says the network name could not be found let us to believe that the problem was with the name resolution, but it was really just saying, 'hey, I couldn't find anything at this path.'
If 'net use' fails due to a 404/50x, it appears that for a brief period of time it will automatically fail any additional mappings for that same host without issuing a request. For example, if net use http://me.com/foo returns a 404, then net use http://me.com/bar will instantly fail if made in rapid succession to that first call, and no request record will be seen in the WebDAV server logs.
My best guess is that appending the #443 port didn't make any real difference. What it perhaps did do was to trick net use into thinking it was talking to a different host, at least for the purposes of its 'auto-fail' feature. But that's just a guess.