Update.sh depends on 1.1.1.1 which some routers errorneously block

[bplein]

Describe the bug, try to make it reproducible When running update.sh, it fails to detect an internet connection:

# ./update.sh
Checking internet connection... failed

This is due to the line which attempts to connect to 1.1.1.1. I have a widely used router supplied by AT&T here in the US that uses 1.1.1.1 internally, which is really dumb but they do that. I must use their router.

If I edit the file, it detects the changed file and wants to download another copy.

I can remove both checks to make it work as a workaround.

[christianbur]

I think at least one more IP should be checked in the script (e.g. 8.8.8.8 or 9.9.9.9), because only 1.1.1.1 is problematic. I also had the 1.1.1.1 problem with our Cisco WLCs.

https://github.com/mailcow/mailcow-dockerized/blob/97adcbe5f834cf6eb7e11f2678b4f73fc17e85a6/update.sh#L245

The following article is very interesting to read. https://blog.cloudflare.com/fixing-reachability-to-1-1-1-1-globally/

With the help from the folks at Sonic we were quickly able to identify that the Pace 5268 a common xDSL modem deployed primarily in the United States (including wide usage on AT&T) uses 1.1.1.0/29 for internal communication. ...

[bplein]

How about a configurable variable in .env that one can choose for their reachability test?

[roswitina]

I had the same problem with updates of Proxmox. 1.1.1.1 could resolve the URL differently than e.g. 8.8.8.8 or 9.9.9.9.

Here could be an explanation: https://community.cloudflare.com/t/1-1-1-1-supports-ecs/17424

[bplein]

This doesn't have anything to do with DNS. For this issue I have opened, there are some widely deployed routers (in my case, it's supplied by my ISP and is required, I cannot supply my own except behind it) and it hijacks 1.1.1.0 network for its own uses, despite AT&T not owning that IP address range.

Simply give us a way to configure this or bypass the check.

[christianbur]

That would be an approach.

echo -en "Checking internet connection... "
curl -o /dev/null 1.1.1.1 -sm3
INET_CHECK_1=$?

wget -q --tries=2 --timeout=10 --spider https://github.com
INET_CHECK_2=$?

if [ "$INET_CHECK_1" -eq "0" ] || [ "$INET_CHECK_2" -eq "0" ]; then
  echo -e "\e[32mOK\e[0m"
else  
  echo -e "\e[31mfailed\e[0m"
  exit 1
fi

[andryyy]

Or we just use 9.9.9.9 - what do you think? Should be unblocked everywhere. Or is it blocked in China?

[bplein]

Suggestion: Use 9.9.9.9 if something as $INTERNET_CHECK_ENDPOINT if not defined in .env

[mitchellurgero]

@andryyy why not do something like: if 1.1.1.1 fails, try 9.9.9.9 (or something) and then if both fail, exit the script? That way there is a fall back and you should always test twice not only can 1.1.1.1 be blocked, but what if that service is down for what ever reason?

[ntimo]

@mitchellurgero I think this would be the best solution.

[christianbur]

why do we check DNS servers for availability, when a connection to https://github.com has to be established? If we check and reach an IP, it doesn't mean that dns works. https://github.com/mailcow/mailcow-dockerized/blob/97adcbe5f834cf6eb7e11f2678b4f73fc17e85a6/update.sh#L282

i have therefore changed my code above to https://github.com

[andryyy]

In some cases we want to NOT check against a name. I prefer to always check against an IP over a name.

[mitchellurgero]

If we check and reach an IP, it doesn't mean that dns works.

That is how DNS works, what I think you meant to say was:

"If we check DNS and get an IP address returned, doesn't always mean we have internet access."

However 1.1.1.1 is an IP address, not a domain name so it does not require DNS to do this check out of the gate. If a host is up, it will ALWAYS be available via an IP address, DNS is not as reliable in some cases because if a local DNS server is down (like your firewall's built in DNS or modem's built in DNS is down for whatever reason), then the resolution wont work.

Edit: Verbiage, first draft might come off as rude.

[Adorfer]

i am not sure if this is related, but i am getting into errors now quite often while updating. or is cloudflare just "limiting" access from some networks?

normally it takes me 2-5 runs of the updater until mailcow is fully up again.

[andryyy]

That’s just a slow Docker hub. Happens from time to time. I think they are working on it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.