I am trying to configure some hardware using the ip address: 192.168.1.251. For some insane reason Firefox keeps forcing it to https://192.168.1.251.
The fact is (a) the address is never on the internet; (b) in this case it is the only other machine; and (c) I have no control over how the hardware does its job any way. So what genius decided that they know better and I can’t connect using plain old http?
The question is how can I tell Firefox to just shut up and do as it’s told? I have already tried browser.urlbar.autoFill and network.stricttransportsecurity.preloadlist and neither of them works.
This might be because at some point a server at this address responded with an HSTS header.
Click on the icon to the left of the URL in the address bar, then in the dialog click clear cookies and site data. Then confirm in the dialog that appears.
Related
Sorry for asking such a mundane question, but I'm suddenly curious. If I open the network connections dialog on my Windows machine, it shows me a cute little picture of my computer connecting to a router and then to a globe (labeled Internet). What is Windows trying to connect to in order for it to decide that the computer has Internet connectivity? I assume there is no IP4 address for 'The Internet', so where is it going? Is it just sending a ping to an address back at the Microsoft home office? If that address were to disappear, would my window's machine suddenly decide that it no longer has a route to the Internet? Would Windows boxes that were 'close' to that address incorrectly report that they could get to the Internet when they couldn't.
I'll stop now before this gets too silly. But seriously, what criteria does a Windows box use to determine that it has Internet connectivity? I'm assuming that Linux and iOS systems have an equivalent feature. Do they use the same criteria?
The general IP address that is used for 'the internet' is 8.8.8.8 - or Google.com.
If you can ping it, and get a web page from it, then there's a pretty good chance you can get to at least some of the internet.
But for specifically Windows - Network Connectivity Status Indicator - it uses a different domain: dns.msftncsi.com
It will (unless disabled by GPO):
resolve the name, and verify it has the 'right' IP (131.107.255.255
fd3e:4f5a:5b81::1 )
Perform a HTTP get to this address and check it gets a result. NCSI
Presumably if different responses are retrieved, then it can tell if it has a wi-fi login or similar.
Your intuitions seem correct. I am not on a Windows machine but you could find out by firing netstat and then connecting.
If I was programming this I'd make Ping, TCP and HTTP requests. Some devices are connected through proxies such as firewalls, captive portals and others. the only way to be sure is to send something and receive a reply.
My Android device for example can detect captive portals. It probably does that by trying to HTTP connect somewhere.
Can I write a Windows Task or some kind of configuration script that will choose between two Local Area Connections according to the website I am visiting?
It may not be the best answer to my problem, but if it is possible, at least I know it will work.
The issue in full:
My main ISP currently has an issue routing me to my own websites (all hosted on the same server). It also has a 'sticky IP address' (note, not static) - it will only change your IP address once a fortnight, and they can't (won't) even force a change. Their second line support are working on the issue, but so far, no good, and I cannot access my own websites via their internet connection.
So, currently, I am switching from my main network to my mobile 3G network (tethered) any time I want to work on or view my own websites.
I would like to write a script that will make Windows automatically choose my mobile network for FTP, email and browsing my own websites, but use my main ISP for all other online activity.
Haven't a clue where to start - any help appreciated! Thanks,
Sarah
Well, that was simple, no scripting required. If you're using IPv4 (you can check here https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&ved=0CDoQFjAB&url=http%3A%2F%2Fwww.amiusingipv6.com%2F&ei=Bq4_UpakM4vv0gXboIDwCQ&usg=AFQjCNHiUnyKvVcUe8Z966YwoycLI28urw&bvm=bv.52434380,d.d2k)
Turn Windows features on or off.
Turn on RIP Listener.
Disable your internet connection that cannot connect to the website you are trying to access, and 'tracert' to the website: make a note of the IP address of the website, and the first IP address in the hop list ([FIRST IP]).
Type in 'route print' and make a note of the Interface number of your secondary internet connection.
Type in 'route add -p [WEBSITE IP ADDRESS] mask 255.255.0.0 [FIRST IP] IF [INTERFACE NUMBER] metric 1'
Reboot.
All traffic to the website IP address (be it mail, FTP, whatever) will go through the secondary connection, all other traffic goes through the main connection.
IPv6 instructions here:
http://windows.microsoft.com/en-gb/windows7/configuring-multiple-gateways-on-a-network
My setup is just an iPhone connected via USB as secondary connection and a Home Hub connected via ethernet as primary.
Hope this is useful to someone else - but of course, no one should ever think of using this to get around IP blocks on message boards...
Sarah
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.
I am trying to make sense of the Chrome Developer Tools when I run performence tests on my websites. If you select Network on the tools meny it will look like this:
Then if I select the performance file I will have this information:
My question is this:
What is the meaning of DNS Lookup, Connecting, Sending, Waiting and Receving? What is happening between the server, network and browser at each stage?
On the first image, the red line reads "Load event fired" and the blue one reads "DOMContent event fired". What is the meaning of this and why is it the DOMContent event is fired after all the content has been loaded?
Answering part II:
The Blue line (DOM content loaded event): It happens when the browser finished parsing the main document.
The Red line (Load event): It happens when the browser finished retrieving all the resources required by the main document.
After the red line: Here you will see loading of asynchronous and cached resources required by the main document and by other resources.
I'm not sure if this is a good fit for SO as this is a network question more than a programming question but I'll answer the parts I can...
DNS Lookup
When you connect to a website, it has to look up the IP from the DNS. For example, your computer will contact a DNS asking if it knows where "google.com" is. If it does, it'll give you an IP. If it doesn't, it'll either give you the IP of another DNS or it will contact that DNS itself (I'm not sure which implementation applies where) until eventually you end up with the IP of the host you're looking for.
Connecting
Time it takes to connect with that IP. I'm not sure of the details here.
Sending
After connecting, you send the request to the server. It can be a request to view a page or submit data or anything.
Waiting
After sending your request, you wait for the server to respond to it. It can be busy or might take a while to process whatever you requested.
Receiving
Once the server has processed your request, it'll send data back to you.
Here is a description by Google:
https://developers.google.com/web/tools/chrome-devtools/network/reference
I recently started using the updated beta tools for Windows Phone 7 and ran into an interesting problem. It seems that with Fiddler running, any Http requests run through the emulator start returning a null result and create a "not found" web exception. This is easy to reproduce with WebClient.DownloadStringAsync(). The old versions of the emulator did work with Fiddler if I remember correctly. Has anyone had luck getting the two to work together? If it's not possible I'd be open to any other tool that could help debug web requests from the WP7 emulator.
It looks like there is a blog post that describes getting fiddler working with Win Phone 7 through some customized rules for setting up Fiddler as a Reverse Proxy.
Here is a little bit of the instructions from the fiddler website, but the blog post seems a little clearer (sorry for wacky format, the block quote is not cooperating):
Option #1: Configure Fiddler as a
Reverse-Proxy Fiddler can be
configured so that any traffic sent to
http://127.0.0.1:8888 is automatically
sent to a different port on the same
machine. To set this configuration:
Start REGEDIT Create a new DWORD named
ReverseProxyForPort inside
HKCU\SOFTWARE\Microsoft\Fiddler
Set the DWORD to the local port you'd like
to re-route inbound traffic to
(generally port 80 for a standard HTTP
server) Restart Fiddler Navigate your
browser to http://127.0.0.1:8888
Option #2: Write a FiddlerScript rule
Alternatively, you can write a rule
that does the same thing.
Say you're running a website on port
80 of a machine named WEBSERVER.
You're connecting to the website using
Internet Explorer Mobile Edition on a
Windows SmartPhone device for which
you cannot configure the web proxy.
You want to capture the traffic from
the phone and the server's response.
Start Fiddler on the WEBSERVER
machine, running on the default port
of 8888. Click Tools | Fiddler
Options, and ensure the "Allow remote
clients to connect" checkbox is
checked. Restart if needed. Choose
Rules | Customize Rules. Inside the
OnBeforeRequest handler, add a new
line of code: if
(oSession.host.toLowerCase() ==
"webserver:8888") oSession.host =
"webserver:80"; On the SmartPhone,
navigate to http://webserver:8888
Requests from the SmartPhone will
appear in Fiddler. The requests are
forwarded from port 8888 to port 80
where the webserver is running. The
responses are sent back through
Fiddler to the SmartPhone, which has
no idea that the content originally
came from port 80.
I'm not able to get Fiddler to monitor the traffic, so I use WireShark, which works fine.