I am trying to open a node.js application on my Nokia Lumia 820 (WP8). When I enter the address in the browser (mydomain.net:8088) I get an error:
"Internet Explorer Mobile doesn't support this type of address and can't display this page".
Is there a workaround or something to get WP8 opening that URL?! I don't really want to use a reverse proxy since I'm trying to test a websocket application running on that port.
(As suggested by Luke Puplett, here is my answer)
My assumption is that you simply forgot to specify the protocol. So instead of typing
mydomain.net:8088
I would recommend to try using
http://mydomain.net:8088
So that the browser knows how to interpret the : before the "8088" (i.e. as a port separator, not as a protocol separator).
Related
I have a Raspberry Pi (Model 3B I believe) which I have equipped with a simple Spring REST service. The service supports a GET method which is mapped to [HOST]:[PORT]/test/get/. All this method does is return GET call successful! immediately after being invoked.
I used ifconfig on my Raspberry Pi to get its ip address, and it seems to function fine for the desktop (works in the URL and in Postman). My problem comes in when I try to access the same exact method using my phone. Attached below are images of the two calls. The URL is exactly the same in both calls.
Also, all three devices are connected to the same wifi network.
Please try to answer why it doesn't function on my phone as opposed to finding a work around. The purpose of me using this very basic GET method is because I have more complex methods that are running into the same issue and they boil down to this obstacle.
Device Details:
Raspberry Pi 3 Model B (Uses wifi)
Desktop with Windows 10
iPhone 6 Plus
I coincidentally found the answer through another person's phone. I'm using the Google Chrome app, but that doesn't come standard on all iPhones, so this person's phone only had Safari. When I tried to access the service using Safari it said:
Which is way clearer. Upon a google search of what this means, I discovered that port 6000 is one of a number of restricted ports that are reserved for other things. So I changed the REST service to use port 6001 (which I then verified is not a restricted port) and then the service worked in both safari and chrome.
So it was just bad luck that I picked 6000 as my port. I wish Google Chrome would give a more detailed message, would have saved me a lot of time.
NOTE: This answer lists all restricted ports:
https://superuser.com/a/188070/690813
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.
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 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.
I want to connect my mobile internet to pc using bluetooth device. I installed blue soleil software in my pc.
Steps:
I can able to pair my cellphone with pc bluetooth device.
I selected my device and select bluetooth dialup networking service.
It asks an alert "DUN connection with device?" in my mobile.
After Clicked "YES", connect bluetooth DUN connection window opens.
In that window there was a fields "User Name", "PassWord" which i leave empty and then in "Dial = *99***1#" and click Dial button.
After that it say "Registering your computer on the netwok.." and become fails.
The Error is as "error 734 the ppp link control protocal was terminated"
The same procedure should be followed for Nokia 3110c it works fine.But in my samsung mobile c3053 it not connected also i am tryig with samsung corby pro BT3510 mobile .
Is there any settings changes needed for samsung mobiles ?
When I've seen this error in the past, it generally indicates that the username and password for the connection is not correct. (Many GPRS configurations do not require a username and password, but some do.)
Or, the GPRS APN is not configured correctly.
If you are trying to use the device as a general purpose modem, it can be difficult to set the GPRS APN without extra dialer software. The easiest way is to add an "AT+CGDCONT" command to the "extra initialisation commands" that can be configured for the modem in the Windows control panel.
A specific example of what would be configured for this "extra initialisation command" is:
AT+CGDCONT=1,"IP","internet"
You would replace internet in this example with the name of the GPRS APN to which you want to connect.
Also, you can refer the following link for checking the connection:
http://support.microsoft.com/kb/318718
I almost got mad as a result of this problem few days back. I tried all the solutions suggested in different forums but to no avail.
My issue was not of insufficient airtime as suggested by some folks, nor the ppp link settings but because i had a space before the username input in my username and password field input in my dial up box.
So folks, if you are getting a PPP link termination error, check user name and password fields carefully for a single SPACE in this field will automatically call up this error when you dial. eg
My user name is: 7032564825#bluebroadband.com
Password: 1234
A space before the first number (that is 7 as in the example above) will trigger this error message. So guys give it a check before you search for other options like airtime and dial up settings.
If you get "734 the ppp link control protocal was terminated" with a SAMSUNG mobile phone, the problem is in the phone. On Phone Settings -> PC Connections select that your phone will always be in "PC Studio" mode. If you select other modes or "Ask each time" you will get 743 when trying to use the phone as a modem.
the solution is very simple. you just need to put extra initialization command.
Please don't read too much tech about ppp and its meaning.
i had same problem in 2006 what you have to do is in modem( the active e.g. bluetooth DUN modem or hardware modem or mobile as a modem) just go to propertise of : my computer>device manager> modem
then modem propertises> advance> Extra Initialization command
here you just have to put command
e.g i use bsnl net so command will be:
at+cgdcont=1,"ip","bsnlnet"
bsnlnet is APN, if you use airtel, anp is "airtelgprs.com"
I too faced the same problem, I even searched on line for a solution, but I figured my self based on the instructions that were given from the customer service centre. I have been using a bsnl network, to avoid ppp link control termination problem
Activate GPRS by sending START sms to BSNL service initiated number
Wait for some time at-least 2 hours to get activated after activation you will receive a activation message.
Since bsnl network, we have to create a APN - Access Point Network
i) create an APN as - bsnlnet
ii) password as 1111
Now change your access point network as bsnlnet switch on your mobile data.
Enjoy Internet.....