Public ip problem

Mandatory information

  • NetIP Version: 0.2.0
  • Operating System Version: Windows 10 21H2

Summary

Netip 0.2.0 doesn’t snow public IPs. Screenshot attached. Downgrading to previous version works fine.

Steps to reproduce

Launch NEtIP. Reproduced 100% of launches. Refresh doesn’t help.

Expected result

Current result

Relevant logs and/or screenshots

Additional context

Possible fixes

Hi!

Thanks for submitting this issue!

I’m unfortunately unable to reproduce the issue on my end, public IPv4 and IPv6 always show up even behind a VPN… :thinking:
I suspect this could be related to your previous issue, but I’m not sure. Does http://ipv4.icanhazip.com/ and http://ipv6.icanhazip.com/ still return your expected public IPs?

I plan on releasing a quick v0.2.1 patch early next week for other bugs I found this week while using the app. I’ll try to include a hotfix for this bug as well, and also add more internal logging to understand why none of your public IPs are showing up.


Bug validated.

Issue 8 on the repository tracker.

Strange thing downgrading to 0.1.0 works fine…

v0.2.0 checks if the Public IP values are not null and actually v6/v4 respectively before actually showing them in the popup. Otherwise, nothing is displayed in the popup field (which is not amazing UX-wise by the way. It should instead display something like “N/A” and/or an error message, but I digress).

v0.1.0 doesn’t check if the public IP values are actual IPv4 or v6. It only checks if the values are not null and displays them. I’ll have to investigate this further. :face_with_monocle:

Good news! I was able to reproduce your issue this morning. I’m not 100% sure on this, but I think it could be related to a timeout issue.

When connected to a slow connection and/or a VPN that just started, Windows can take a little while to resolve DNS, which means any HTTP request will fail or take longer than usual.
To avoid leaving hanging the network popup UI, NetIP times out the public IP request after 5 seconds, which is too short in this exact case. I could increase the timeout value and definitively must implement a user feedback for this error.

@bashik Could you confirm if navigating with a web browser to http://ipv4.icanhazip.com/ and http://ipv6.icanhazip.com/ takes a little while when reproducing the issue?

Hey!

Actually it shows result immediately.

Interesting… And not what I expected… :sweat_smile: If your browser can resolve icanhazip DNS immediately, there’s no reason NetIP should be any different.

Either way, I’ll improve the timeout and add more logging in v0.2.1 to better diagnose your issue. If the timeout doesn’t help, hopefully logging will help fixing it for patch v0.2.2! :muscle:

Quick update: I’ve made some progress this week, but this issue turned out to be way more challenging than I anticipated…
The patch v0.2.1 is therefore delayed, sorry about that! :face_with_diagonal_mouth:

1 Like

I am ok on version 0.1 )

What I am really looking for is the geo flag implementation, for me it is a killer feature. I am patient though)

1 Like

Potential fix merged into branch develop & scheduled for release v0.2.1.

I had to change a lot of things… Hopefully it will fix the issue. I’m not marking this thread as completed yet until you’ll confirm the bug is gone. I’ll let you know when it’s released! :wink:

@bashik The patch v0.2.1 is out, let me know if your issue is gone ! :wink:

Hey! Still having issues. It gives the HTTP request fail now. The links you gave above resolve well. I switched off the software firewall and no vpn is on, still the result is the same. Probably have something blocked somewhere, but I am now sure what to look at, as browser resolves well. Very strange. Rolling back to 0.1.0 still works fine.

Cheers!

Thanks for the feedback!

Here are a few things to look into:

  1. Does the error appear right away, or after a few seconds of fetching? What happens if you try the refresh button?
  2. What are your current DNS settings?
  3. Regarding a potential firewall that could block NetIP: you need to check your own firewall settings if NetIP is blocked from the internet somewhere. NetIP requires Internet access on port 80 (http) and 443 (httpps), both incoming and outgoing. If it is blocked, this would explain why you can’t fetch your public IP. If it’s just the default Windows Defender, you can check the Microsoft documentation here.
  4. Did you do a typical or portable installation of v0.2.1?
  5. NetIP v0.2.1 now saves logging information for debugging. You’ll find them in C:\Users\<your_username>\AppData\Roaming\NetIP\logs. Could you share the latest log file here? Just make sure to trigger the HTTP error before uploading the file.
  6. I’ve also added a manual timeout setting in Settings > Miscellaneous tab > Network Settings. The default value is 25 seconds, which should be more than enough in a typical scenario. Could you try to increase it a bit to 30/40, then retry to fetch your public IP? If that doesn’t help, make sure to roll back the value to 25 seconds.

Thanks!

Awaiting your reply, I’m marking this issue as need-investigation for the moment.

Hey! Was away from the windows machine for a while.

So, thanks to the log, which showed this I figured V2rayN is the problem. NetIP doesn’t work with it enabled. Without it works fine. Here’s the log:

2024-12-03 16:25:21.844 +03:00 [INF] Logging initialized.
2024-12-03 16:25:22.792 +03:00 [INF] NetIP is fully started and ready!
2024-12-03 16:25:28.497 +03:00 [ERR] [Public IPv4] An error occurred while making the HTTP request.
System.Net.Http.HttpRequestException: No connection could be made because the target machine actively refused it. (127.0.0.1:10809)
 ---> System.Net.Sockets.SocketException (10061): No connection could be made because the target machine actively refused it.
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.ThrowException(SocketError error, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.AwaitableSocketAsyncEventArgs.System.Threading.Tasks.Sources.IValueTaskSource.GetResult(Int16 token)
   at System.Net.Sockets.Socket.<ConnectAsync>g__WaitForConnectWithCancellation|277_0(AwaitableSocketAsyncEventArgs saea, ValueTask connectTask, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.<ConnectAsync>g__Core|281_0(IPAddress[] addresses, Int32 port, CancellationToken cancellationToken)
   at System.Net.Sockets.Socket.<ConnectAsync>g__Core|281_0(IPAddress[] addresses, Int32 port, CancellationToken cancellationToken)
   at NetIP.Services.NetworkInfoService.<>c__DisplayClass0_0.<<CreateHttpClient>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(String host, Int32 port, HttpRequestMessage initialRequest, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.AddHttp11ConnectionAsync(HttpRequestMessage request)
   at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.WaitWithCancellationAsync(CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.GetHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.GetStringAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at NetIP.Services.NetworkInfoService.GetExternalIPV4(HttpRequestResult Result)

Version 0.1.0 works fine with Vray on.

For me the sense of NetIP is to quickly check where are we now with VPN on/off/location change…

Another note… V2Ray sets system proxy and has the option to clear it instantly. However, NetIP won’t work properly even after the system proxy is cleared and the V2ray is unloaded from memory. It starts to function only after I restart it.

Thanks for the logs!

After reading them, it does seem like NetIP is blocked by a firewall rule, probably v2rayN indeed. I’m unfamiliar with v2rayN, it’s hard to reproduce the issue on my end… If v0.1.0 just plain works despite all of this, I’ll try to revert the specific bit of code that should cause this.

Does this bug affect only v0.2.x? Or also v0.1.0 ?

Alright, I’ve made a few modifications to the code today to revert a few things that changed between v0.1.0 and v0.2.0.

To avoid the whole release process shenanigans, I’ve made a quick test build so that you can give me feedback quicker. You can download it here.
Note that this is a test build only to verify if that fixes your issue. Please discard it once the test is done.

Let me know if that build works better, and if so I’ll publish the v0.2.2 asap! :wink:

1 Like

Thanks! Works alright now! For IP v4

Only thing is also started t show IPv6 which I think I have switched off everywhere.

Awesome! :smiley:

I’m not sure if I’m understanding you here… :thinking: Does it show your public IPv6 correctly?

Note that I’ve added a check since v0.2.0 that prevent NetIP from displaying a random IPv4 value instead of IPv6 (and vice versa). This was discussed in this issue:

Hmm… https://ipv6.icanhazip.com/ also started to show IPv6. I guess the vray provider assigns one. Yes, this is the case.

So, the behavior is like this. When I turn off the vray, NetIP_test_ver after hitting refresh stops showing IPv6 and but also gives wrong IPv4. I restart NP and it then shows the right ipV4 and no ipv6, just as it should. So, for me the only thing with this versions is the need to restart the app to get new and correct IP information.