Al-hello fails internet connection check


al-hello fails to run. it fails checking for internet connection despite my internet actually working. does not seem to respond to ping request, thus this fails. replacing in al-hello script with something “ping-able” works just to confirm this issue.


archLabs, Hello

For a work around, you may try commenting out the call out for the network check in this file:


This is just a bandaid, so to say, until we can figure out how to fix this. I had to do this in order to move forward myself.


I wonder if this is a wireless related issue? I too experienced this while putting the testing release through it’s paces on one of my laptops. Never have had an issue on the desktop.


for the record, im connected wired, and so is my internet (uses classic telephone+dsl)


Well i have a card for my wifi/bluetooth hookup. And when hardwired I still had an issue even though I have a standard Intel board with its usual ethernet hookup. and yet both wouldn’t work in ping but yet I can still download and install packages.


Are you using a modem? DSL is usually standard with most internet hook-ups.


yes, modem


I don’t believe this is an issue of the address being reachable VIA an ICMP ECHO, as this has not been an issue before with the script. It is clear that something did prevent this from returning a successful response.
As seen here, the user is actually being redirected to an amazonaws system, which may or may not be apart of github’s infrastructure. Therefore the amazonaws address is not pingable. However, the actual Github IP is pingable.

And, being that we are attempting to ping the URL directly verses a known IP Address, could result in a failed DNS lookup prior to the ICMP ECHO Request being sent. Which is likely what happened, and we are looking at the screen capture that shows us the ISP DNS server cache is either out of date or poisoned.

So, before we get much further, @retrowertz, have you changed or modified your DNS settings on the modem you are using?


thanks for the reply. both dns from my ISP and google’s DNS acts the same.

my ISP is putting us in CGNAT if that matters.


From what I have read about the CGNATs, it should not have an effect on the DNS. Providing the ISP deployed it properly, and we all know that there are growing pains with new technology deployments.

I can’t imagine Google’s DNS servers being outdated, but I have experienced an ISP having outdated cache before. For my testing purposes and regular use, I direct my traffic through the OpenDNS resovlers, So, I can not verify the output for Google’s DNS servers, using the nmap tool.

That said, it might be safe to assume the cache is simple outdate. One last question then. @retrowertz, are you changing the DNS configuration on the modem or locally on your machine?


im changing in local and modem.


Since you have changed them in both areas, would you check at the link below, to make sure your DNS is not being hijack.



here what it shows, when im using and ( i use this always as compared to what ISP gives me )

for security, i may not post the result from my ISP, but i guarantee that the dns returned is indeed from my isp and both dns server and reverse dns returned the same value.


Awesome. This is helpful, because it let’s us know that you were not being hijacked. So, it is likely just a caching issue. And, this can fixed a couple of different ways. One of which would be to replace the URL with an IPV4/IPV6 address, to eliminate the DNS translation. Another option, would be to replace the address with a search engine address like, However, using the URL still opens up the issue of DNS redirection. So, defaulting to the IPV4/IPV6 address is the better of the two options in my opinion.


Well, I have tried and had the same situation. I’m thinking that it may be a hardware issue, but let’s make sure that all other software issues are looked at. :thinking:


I use systemd-resolved, it provides a local, authenticated nameserver that avoids the problems of man-in-the-middle attacks and cache poisoning:

Unbound is another alternative and can also be used as an add-blocker :slight_smile:


Hardware, as in the NIC card, you might be right. But, in this case, it would point back something outside ArchLabs, and more germane to the network interface card driver itself. @sevenday4 this is why I think defaulting to the standard IPV4/IPV6 address is the better solution currently, than simply just changing from one URL to another URL.


You do make a good point, and resolved is not fully enabled by default, as it remains inactive. Making this part of the initial install configuration could help mitigate issues later the road.


@AvnSgt I’m in agreement in using a IPV4/IPV6 address may be the way to go. But another consideration that @Head_on_a_Stick brought up as well as @retrowertz is security. I’m going to look at what @Head_on_a_Stick posted with Systemd-resolved and Unbound as alternatives. Also, another issue is when someone like myself uses a VPN service in which I change my “location” every few times. I know, that seems extreme but considering how complex the websites as well as those who want to gather your info…