Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

WAN IP no longer displaying upon boot - Raspberry Pi #4797

Closed
bransond5225 opened this issue Oct 3, 2021 · 36 comments · Fixed by #4798
Closed

WAN IP no longer displaying upon boot - Raspberry Pi #4797

bransond5225 opened this issue Oct 3, 2021 · 36 comments · Fixed by #4798
Labels
Enhancement 💨 Solution available 🥂 Definite solution has been done
Milestone
v7.7

Comments

@bransond5225
Copy link

bransond5225 commented Oct 3, 2021 •
edited by MichaIng
Loading

Creating a bug report/issue

Required Information

  • DietPi version: v7.6.2
  • Distro version: bullseye 1
  • Kernel version: Linux DietPi 5.10.60-v7+ #1449 SMP Wed Aug 25 15:00:01 BST 2021 armv7l GNU/Linux
  • SBC model: RPi 3 Model B (armv7l)
  • Power supply used: Canakit 5V 2.5A
  • SDcard used: Samsung 32 EVO Plus

Steps to reproduce

SSH into DietPi OS and an error message appears in the WAN IP field

Expected behaviour

WAN IP address should display

Actual behaviour

The following error message: curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

Many thanks for your report. curl throws an error. Can you try:

curl -I https://dietpi.com/

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

Okay that works. How about:

curl -sSfL https://freegeoip.app/csv/

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

Do you use Pi-hole or another way of DNS filtering?

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021 •
edited
Loading

Can you try to add freegeoip.app to the whitelist? Probably a blocklist update now contains it. Sadly such public APIs are often found on blocklists as also tracking scripts by times make use of them. It is however executed client side, so your browser sees its own remote IP and location and not the ads provider (which has your IP anyway and can pipe it through the API themselves, when wanted), so the reason for blocking those APIs is questionable.

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

Okay than this is not the issue. Can you show the verbose output:

curl -v https://freegeoip.app/csv/

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

Strange, here it works well:

# curl -v https://freegeoip.app/csv/
*   Trying 104.21.19.200:443...
* Connected to freegeoip.app (104.21.19.200) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
*  subject: C=US; ST=California; L=San Francisco; O=Cloudflare, Inc.; CN=sni.cloudflaressl.com
*  start date: Aug 11 00:00:00 2021 GMT
*  expire date: Aug 10 23:59:59 2022 GMT
*  subjectAltName: host "freegeoip.app" matched cert's "freegeoip.app"
*  issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
*  SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x5574d10e5f80)
> GET /csv/ HTTP/2
> Host: freegeoip.app
> user-agent: curl/7.74.0
> accept: */*

The server sits behind Cloudflare and your 172.67.188.154 is a Cloudflare IP as well, so that looks all correct. Are there package (libSSL/OpenSSL) available?

apt update
apt upgrade

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

Probably that Cloudflare node is faulty. Does it work if you try to connect via IPv6 (if enabled on your system and network):

curl -v6 https://freegeoip.app/csv/

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

There seems to be no IPv6 route (probably the router does not provide it):

ip -6 r

This command needs to show a route starting with default via followed by the IPv6 LLA address of the router.

You're allowed up to 50,000 queries per hour for one IP address.

I wonder if this applies to the Cloudflare server IPs or respects the CF headers to apply to the actual client. However, the curl error does not indicate that it's this issue. And of course I doubt that any actual client is doing 50,000 requests in one hour 😄.

Not sure how to solve this issue at the moment, I guess it is a temporary one. If you don't rely on it, let's wait for one day and see if it is still present. I may report this to Cloudflare if it persists.

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021 •
edited
Loading

So you don't have an IPv6 default route/gateway as expected.

I looked at the PiHole query log and confirmed it is indeed replying with an IP address.

Yes we see that in the outputs above already, also you get an IPv6 address which is independent of IPv6 being functional: You can ask a DNS server for an AAAA record (IPv6) via IPv4 and independent of the fact whether IPv6 is functional at all or not.

I am also able to get a WAN IP from sites such as whatsmyip.org and freegeoip.live.

Try to solve this by adding them to the whitelist, respectively check whether Pi-hole is blocking those. Also, which upstream DNS are you using? Some have an internal DNS blocking.

So it appears to me, it is the curl command format that is in question.

It is a completely regular curl command, nothing special, also as you could see above even a simply curl https://freegeoip.app/csv/ fails the same way, so the flags have nothing to do with the issue,

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

Which upstream DNS do you use in Pi-hole? Ah, sorry you said already that you use Unbound. You use Unbound as recursive DNS server or did you enabled DoT or similar?
... ah actually the resolved IPv4 seems correct (a Cloudflare address), so DNS blocking isn't the issue for freegeoip.app and probably neither for the other two API hosts. No idea whether some firewall elsewhere may be the issue then, something that blocks on IP level, not on DNS level 🤔.

My question is why don't I have IPv6 response? I don't recall ever disabling that anywhere.

It seems it is disabled in your router. Probably you don't even have a public IPv6 address? Or do you manage DHCP via Pi-hole? Your router needs to send router advertisements (RA) which contain the public IPv6 prefix, so clients can attach themselves a global unicast address (GUA) and the routers IPv6 address as gateway. You can check the IPv6 addresses of your system via:

ip -6 a

I guess there is only one starting with fe80::, which is a local link address (LLA) which can only be used to connect to the router itself but not to a remove IPv6 host.

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@Joulinar
Copy link
Collaborator

Joulinar commented Oct 3, 2021

as stated above by @bransond5225 issue is with freegeoip.app. The new name freegeoip.live is working fine.

root@DietPi3:~# curl -sSfLm 100 https://freegeoip.app/csv/ 2>&1 | mawk -F, '($5){r=$5" "}{print $1" "r$3}'
curl: (7) Failed to connect to freegeoip.app port 443: Connection refused
root@DietPi3:~# curl -sSfLm 100 https://freegeoip.live/csv/ 2>&1 | mawk -F, '($5){r=$5" "}{print $1" "r$3}'
93.x.x.x xxx Germany
root@DietPi3:~#

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

My router is running DD-WRT

Probably you can browse the DD-WRT settings to check whether you got a public IPv6 address by your ISP and whether the router is providing IPv6 addresses to the local network accordingly.

@bransond5225
Copy link
Author

bransond5225 commented Oct 3, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021 •
edited
Loading

issue is with freegeoip.app. The new name freegeoip.live is working fine.

On all my systemd freegeoip.app works fine (including browsers). Any hint which says that freegeoip.live is "new" or superseding the first? To me it looks like a different provider. Also your error is a different one.

EDIT:

I was just reading where fregeoip.app is deprecated and now uses this: https://freegeoip.live

Ah I've overseen this one. Where is this written?

@Joulinar
Copy link
Collaborator

Joulinar commented Oct 3, 2021

sorry need to revert my statement. I had some human error. Old one is working fine. Just located me wrongly in another state. But in general it's working fine.

root@DietPi3:~# curl -sSfLm 100 https://freegeoip.app/csv/ 2>&1 | mawk -F, '($5){r=$5" "}{print $1" "r$3}'
93.x.x.x. xxx Germany
root@DietPi3:~#

@MichaIng
Copy link
Owner

MichaIng commented Oct 3, 2021

Nice would be to allow choosing a different provider, but all have different response formats when the location is included 🤔. So only possible way would be if users enter the mawk as well, which makes is pretty unusable for 95% of our users or so 😄.

@MichaIng MichaIng linked a pull request Oct 4, 2021 that will close this issue
DietPi-Banner | Use Cloudflare worker on own domain for GeoIP #4798
Merged
@MichaIng MichaIng added the Solution available 🥂 Definite solution has been done label Oct 4, 2021
@MichaIng MichaIng added this to the v7.7 milestone Oct 4, 2021
@MichaIng
Copy link
Owner

MichaIng commented Oct 4, 2021 •
edited
Loading

Since we are behind Cloudflare, I found a simple way to provide GeoIP info via our own domain via Cloudflare worker: #4798
If this get's used by too many clients outside of our scripts, we may add a custom request header or user agent and block all requests which do not match it. But our old myip.php script wasn't overloaded with unintended requests either, so for now it should be fine without any filter.

Another point is that we have an overall request limit for our workers, so we need to observe also whether DietPi clients are doing too many requests. In case we need to cache the WAN IP on DietPi, e.g. for one hour, cleared via hourly cron job or manually e.g. when DietPi-VPN connects or disconnects from a VPN.

@MichaIng MichaIng linked a pull request Oct 4, 2021 that will close this issue
DietPi-Banner/VPN | Move to more reliable WAN IP + location API service #4398
Merged
@MichaIng MichaIng removed a link to a pull request Oct 4, 2021
DietPi-Banner/VPN | Move to more reliable WAN IP + location API service #4398
Merged
@MichaIng
Copy link
Owner

MichaIng commented Oct 4, 2021 •
edited
Loading

But @bransond5225 let's see if this really solves your issue:

curl -sSf https://dietpi.com/geoip

@bransond5225
Copy link
Author

bransond5225 commented Oct 4, 2021 via email

@MichaIng
Copy link
Owner

MichaIng commented Oct 4, 2021

Okay, then our guess that it was a temporary issue, probably with the Cloudflare node, or something on ISP side, turned out to be true 🙂. However, the step to not rely on 3rd party providers/APIs but provide own ones for our uses is reasonable anyway. And it was a constant issue that those public APIs often land on blocklists.

@Joulinar
Copy link
Collaborator

Joulinar commented Oct 4, 2021

@MichaIng
for me it looks like this using our service now.

root@DietPiProd:~# curl -sSf https://dietpi.com/geoip
93.x.x.x xx DE

@MichaIng
Copy link
Owner

MichaIng commented Oct 4, 2021 •
edited
Loading

Jep, same from our server, so a region was not found by the service which Cloudflare internally uses (or is it the xx?). From my home it shows:

xxxx:yyyy:... Land Berlin DE

which is not accurate but it matches the result of the old API, aside of DE instead of Germany.

@Joulinar
Copy link
Collaborator

Joulinar commented Oct 4, 2021

myself are located in S-A which is as well wrong for my state. But yeah same as the old API.

@MichaIng
Copy link
Owner

MichaIng commented Oct 4, 2021

Okay 😄. I remember we used the city in the past, which was wrong even more often. I think the region is accurate in larger countries like the US, where it matches the state, but in Germany IPs seem to be not reliably attached to specific federal states.

@ravenclaw900
Copy link
Collaborator

Yeah, it gets my state correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Enhancement 💨 Solution available 🥂 Definite solution has been done
Projects
None yet
Milestone
v7.7
Development

Successfully merging a pull request may close this issue.

DietPi-Banner | Use Cloudflare worker on own domain for GeoIP MichaIng/DietPi
4 participants
@MichaIng @Joulinar @ravenclaw900 @bransond5225