Local does not work on Mac OS X

#1

Subject of the issue

Connecting to local.autopi.io does not seem to work from a Mac. Stays stuck on:

“Please ensure connection to local hotspot.
No connection found. Retrying…”

Connecting via the IP (192.168.4.1) does open the local login page, but that one’s stuck on:
“Connected to a local device, but local API not yet ready. Please wait”

At the same time, connecting from a phone (iPhone X, Mobile Safari) works just fine.

Your environment

  • Chrome Canary 75.0.3758.0, Safari 12.1.1 (14607.2.2), Firefox 67.0b6

Steps to reproduce

  1. Open local.autopi.io in a browser on a Mac OS X machine
  2. Open 192.168.4.1 in a browser on a Mac OS X machine

Expected behaviour

Should open local autopi web UI.

Actual behaviour

Stuck on “No connection found.” / “local API not yet ready”.

#2

Hi.
Do you on the same wifi ? I talk about the wifi autopi sharing.
Then the Mac on the wifi autopi sharing.
(I have a Mac, all work fine)

#3

Yes, i’m on the same wifi, how else would i be able to open 192.168.4.1? :slight_smile:

If i had to guess, it seems like some kind of a name resolution issue.

#4

what the command you write ? and from ?
I use only terminal command from Mac
also same wifi, all is ok
like this:

#5

I can SSH just fine into it.
Again, using the IP address, as local.autopi.io does not resolve.

The web UI does not work locally from a mac (”local API not yet ready”).

#6

Issue resolved.

I had to assign 192.168.4.1 as a DNS manually.
This is pretty shoddy programming - not everyone has DHCP-assigned on their macs. I have a manually configured list of DNS’ that i need for various reasons (VMs, work VPN, etc.).

Note that i don’t mind the fact that local.autopi.io does not resolve - rather it’s that the local web UI does not work at all in this case. I assume because it doesn’t have an IP address as a fallback, and relies exclusively on the domain-name.

1 Like
#7

Ok. Great you had find why it was not working.
Because on my Mac all was ok and didn’t know why your’s was not

#8

It’s because of the clumsy way Autopi has it set up.

local.autopi.io will get resolved by any DNS out there, and it will resolve to Autopi’s server (172.104.147.185). That means that if you’ve got ANY DNS of a higher priority than the dongle itself, local.autopi.io will point to their servers, instead of the dongle.

The code on the local web UI page also uses local.autopi.io instead of the IP address, so using 192.168.4.1 as the URL doesn’t work either, unless the dongle is set up as either the ONLY DNS or the primary DNS.

Which is a bad assumption to make.

The local web UI should’ve had a more sensible name (e.g. autopi.local) and it would’ve worked fine on any machine, regardless of the network settings.

1 Like
#9

Hi Ante

Yes, if you change the default dns servers on your machine, it will not work.
The reason it is made the way it’s made is because that by sharing the same name, it will fall back to the remote version if the device is not connected, and when the device is then connected, the remote version will refresh and the local will take over.

As you explain, our implementation is not perfect, but there was some consideration done when it was implemented, and in this case, we’ve had to pick an implementation that we believe would benefit the most users by means of usability and ease of use, but unfortunately it also means that it does not work for some of our power users.

If you have any alternative implementation ideas, we are very interested in hearing about it.
And I agree that it should work for both the domain AND the ip, as that would allow you to access and use it via the IP, now that the domain does not resolve.

Best regards
/Malte

2 Likes
#10

Would this work:

  1. make local use autopi.local
  2. leave local.autopi.io up, as is, on remote
  3. make local.autopi.io redirect to autopi.local if autopi.local is up
  4. fix local so it uses autopi.local in place of local.autopi.io in client code

That way, there’s no disruption / changes to documentation. People can still go to local.autopi.io as instructed. If local is not up/available, they still get remote. If local is up, they get redirected to autopi.local and no harm, no foul. The URL in the browser URL bar is different, but i doubt anyone will bi bothered by that.

#11

Not much help, but I’ve always used a mac to connect to the local wifi and logged in okay (both ssh and web ).

#12

Hi

That could work yes, I have added it to our backlog :slight_smile:

Best regards
/Malte

1 Like