Incognito, no popups either.
Let me try from a non-work laptop to see if nip.io works.
Bingo…nip.io URL embedded link works fine from my home laptop. So probably a DNS or restriction somewhere my company puts on the laptops. Now to see if it works with Fully.
@Jordan_Welker, by chance did you figure out how to get Fully to work again? I seem to be having the same issue that you are where even adding in nip.io into the address doesn’t work.
I suspect that Jordan’s issue was slightly different as they mentioned that nip.io didn’t work at all for them and they had mentioned that in the context of Chrome. Without more details, it’s unclear what their configuration was though.
I just tested on a Fire HD 8 Plus (10th gen) with the version details shown in my screenshot below and it worked for me.
Have you gone through these steps, noting the results of each, to help narrow things down?
Desktop / Laptop on Chrome (if available)
Test the camera URL directly in your browser:
http://192.168.1.15:8083/axis-cgi/mjpg/video.cgi?camera=6
Test the nip.io URL directly in your browser:
http://192.168.1.15.nip.io:8083/axis-cgi/mjpg/video.cgi?camera=6
Test the nip.io URL within a SharpTools Media Resource
(SharpTools User Page > Manage Resources > Media)
Fire Tablet (Silk Browser)
Test the camera URL directly in your Silk browser:
http://192.168.1.15:8083/axis-cgi/mjpg/video.cgi?camera=6
Test the nip.io URL directly in your Silk browser:
http://192.168.1.15.nip.io:8083/axis-cgi/mjpg/video.cgi?camera=6
Test the nip.io URL within a SharpTools Media Resource
(SharpTools User Page > Manage Resources > Media)
Fire Tablet (Fully Kiosk Browser)
Test the camera URL directly in your Fully Kiosk browser:
http://192.168.1.15:8083/axis-cgi/mjpg/video.cgi?camera=6
Test the nip.io URL directly in your Fully Kiosk browser:
http://192.168.1.15.nip.io:8083/axis-cgi/mjpg/video.cgi?camera=6
Test the nip.io URL within a SharpTools Media Resource
(SharpTools User Page > Manage Resources > Media)
Sorry just getting back to this.
Just tried it on my 2017 Fire HD8 tablet.
The nip.io link opens up fine in the Silk browser.
It won’t open in the Fully browser…
The standard camera URL works fine in the Fully browser.
Have to try it on a non work laptop as well.
Also, the nip.io link works fine on my iPhone in Safari, not in Chrome.
Tried it on a non-work laptop. Same issue, Chrome and Firefox give the “We can’t connect to the server at 192.168.1.15.nip.io.” error.
So it works on Safari and Silk, but not Fully, Chrome or Firefox. Could have sworn it worked on another one of my personal laptops but can’t recall which it was.
Unfortunately, I’m unable to help without the details.
It’s really important to include the results of each step along with the details of any error messages (screenshots preferred). And in general, it’s important to include details like version numbers, device make/model, and any other relevant details about the configuration or testing.
As a free user, we try to offer as much support as we can through our community and documentation. Providing these details will enable both us and the community to assist you more effectively.
–
I’ve tested each of these steps on a variety of new and old devices and I’m not able to reproduce the issue. The DNS_PROBE_FINISHED_NXDOMAIN
issue mentioned above is clearly a DNS / networking issue. It’s not clear exactly what error messages you were seeing when things weren’t working with some of your recent tests but “We can’t connect to the server at XXX” sounds like a networking error.
That’s part of the reason I asked for result of each of the steps above: it starts with a fundamental validation of network connectivity to your camera, then tests nip.io which should only be a difference in DNS resolution, then tests it as an embedded resource which is where most browsers get the most finicky.
Okay. First series of pictures is all on Silk Browser.
Top right on dashboard is driveway stream. Rest are all not on nip.io. In Silks case using the sharp tools dashboard it does not show either nip.io or direct URLs.
Next is Fully. Again, Top right on dashboard is driveway stream. Rest are all not on nip.io.
Versions of Tablet and OS.
Just curious, but if Silk works for nip.io but Fully won’t on the same tablet, doesn’t that rule out a DNS issue?
Unless each browser allows you to change DNS settings which I don’t believe is the case?
@josh Just getting back to this. Did I provide everything you needed above? I don’t think it’s a DNS issue since some browsers in the same device work while others don’t, which unless there are specific DNS resolution options within each browser (and I don’t think there is), implies it’s not DNS?
I didn’t see which WebView version is being used.
The error message ERR_NAME_NOT_RESOLVED
reads as a DNS resolution issue. That doesn’t necessarily mean it’s an issue with your internet, but it points to a DNS resolution issue in that screenshot.
Understanding what WebView version you are on and ideally updating it to as new of a version as you can would be ideal here.
I would also be curious about these results.
Hey @S_D - did you see my responses above?
I also put together a proof of concept with our own DNS resolver that effectively does the same thing as these services if you wanted to try it. It’s available at {local-ip}.st-ip.net
formatted like the others.
Example: http://192-168-1-15.st-ip.net:8083/axis-cgi/mjpg/video.cgi?camera=1
Finally got back to this. Screen shot of WebView is below. Tried the st-ip.net and receive the same error that the image can not load (using Fully).
How do I upgrade the Webview?
Okay, so updated Fully to 1.53 and used an apk to update the webview, now things are actually worse as Fully doesn’t show any streams (before it would show the regular IP addresses but not the ones with nip.io or st-ip.net).
Is there anything in my Asus router settings I should check as it relates to not resolving nip.io or similar?
Right now both my tablets are useless (as I also need to figure out how to get my Harmony integrations working again…saw some threads on that but tackling this first).
Lastly, I’m using Tinycam as the webserver as it was less intensive than using BlueIris. If there is an easier way to do this using BlueIris, I can try that as well?
Hm. That’s a good question around where the resolution is failing. I was trying to piece together some of what you described earlier, but it’s not clear to me. Unfortunately, it wasn’t always clear which device + browser + network you were testing with… and it wasn’t always clear if it was a test of the URL directly in the browser or within an embedded SharpTools Media Resource.
nip.io resolution results:
This is to be expected. As noted in my very first reply, the reason we were looking at the nip.io or st-ip.net workaround was for your one tablet that updated to a newer version as Chromium 111 and newer has a bug with mixed content and IP addresses.
Maybe. Can you tell us more about your DNS configuration?
It’s still not clear why it would work in Chrome on one of your home laptops, but not the other or what the differences between each test was.
It’s not clear to me what OS you are using on your non-work laptops, but if it’s Windows, you could try the following command in a terminal (command prompt):
nslookup -debug 192.168.1.31.st-ip.net
You should get something like the following (please share it):
C:\Users\josh>nslookup -debug 192.168.1.10.st-ip.net
------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NXDOMAIN
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
1.1.168.192.in-addr.arpa, type = PTR, class = IN
------------
Server: UnKnown
Address: 192.168.1.1
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
192.168.1.10.st-ip.net, type = A, class = IN
ANSWERS:
-> 192.168.1.10.st-ip.net
internet address = 192.168.1.10
ttl = 30 (30 secs)
------------
Non-authoritative answer:
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
192.168.1.10.st-ip.net, type = AAAA, class = IN
------------
Name: 192.168.1.10.st-ip.net
Address: 192.168.1.10
I think it should go without saying at this point, but I would need you to share those results. I can’t help without the details.
Weird. So last night I was heading up to bed, walked past my FireHD tablet, and suddenly one of the streams was coming through, the one with the st-ip.net link in it. When I woke up this morning, it no longer was working. WTH?
Here’s the results of that command on the laptop where http://192.168.1.15.st-ip.net:8083/axis-cgi/mjpg/video.cgi?camera=1 works.
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
1.1.168.192.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> 1.1.168.192.in-addr.arpa
name = RT-AX86U-0888
ttl = 0 (0 secs)
------------
Server: RT-AX86U-0888
Address: 192.168.1.1
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
192.168.1.31.st-ip.net, type = A, class = IN
ANSWERS:
-> 192.168.1.31.st-ip.net
internet address = 192.168.1.31
ttl = 30 (30 secs)
------------
Non-authoritative answer:
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = SERVFAIL
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
192.168.1.31.st-ip.net, type = AAAA, class = IN
------------
Name: 192.168.1.31.st-ip.net
Address: 192.168.1.31
Here is the same command on another home laptop where when I try the stip.net address I get:
># This site can’t be reached
>
>Check if there is a typo in 192.168.1.15.st-ip.net.
>
>* If spelling is correct, [try running Windows Network Diagnostics](javascript:diagnoseErrors()).
>
>DNS_PROBE_FINISHED_NXDOMAIN
Command result:
console
nslookup -debug 192.168.1.31.st-ip.net
------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NOERROR
header flags: response, auth. answer, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 0, additional = 0
QUESTIONS:
210.1.168.192.in-addr.arpa, type = PTR, class = IN
ANSWERS:
-> 210.1.168.192.in-addr.arpa
name = DD-WRT
ttl = 0 (0 secs)
------------
Server: DD-WRT
Address: 192.168.1.210
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
192.168.1.31.st-ip.net, type = A, class = IN
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 3, rcode = SERVFAIL
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
192.168.1.31.st-ip.net, type = AAAA, class = IN
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 4, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
192.168.1.31.st-ip.net, type = A, class = IN
------------
------------
Got answer:
HEADER:
opcode = QUERY, id = 5, rcode = SERVFAIL
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 0, additional = 0
QUESTIONS:
192.168.1.31.st-ip.net, type = AAAA, class = IN
------------
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for 192.168.1.31.st-ip.net
Thanks for the update. When posting long blocks of text / logs, please make sure to format things accordingly. Otherwise it makes it unnecessarily difficult to try to understand what was posted when the regular community formatting takes over.
Formatting Content for Community Posts - SharpTools Knowledge Base
It looks like you are running DD-WRT which is a custom router firmware with advanced features.
I would check how DNS resolution is setup on your router. The logs appear to indicate that the DNS resolution for the A record responded with NOERROR
and that it needed to recursively look up the DNS record (which is totally normal), but then the recursive lookup never occurred.