initial connections and hostname problems

[SamuelDudley]

pi3b+ 1.2-b image The hostname is maverick-raspberrylite.tendawifi.com self-update and maverick configure maverick.dev.2020-03-23-01-57.log

maverick configure maverick.dev.2020-03-23-02-54.log

The hostname is still maverick-raspberrylite.tendawifi.com sudo hostnamectl set-hostname maverick-raspberrylite.local sudo reboot maverick configure maverick.dev.2020-03-23-04-43.log hostname is now maverick-raspberrylite.local maverick configure (note no changes) maverick.dev.2020-03-23-04-47.log

Note that after all of the above I cant connect to the pi from any of my other hardware using the hostname, its just not visible to my other computers. I'm not suggesting there is anything wrong with the hostname of the pi after the above changes are made, but the connection docs lean quite heavily on the existence of the hostname. Perhaps we can devise a more 'fool proof' initial connection method?

[fnoop]

You won't be able to connect to the tendawifi.com hostname as that won't resolve for you - it resolves for me because my local mesh network provides a dynamic unicast dns server that acts for the domain. In order for zeroconf to respond it should be a .local hostname - your (client) computer's dns stack should always look for a .local response over multicast dns, aka zeroconf which should be responded to by avahi on the maverick computer.

maverick configure should rewrite /etc/hosts with the actual fqdn set. Actually, it's probably better to set /etc/hosts with the hostname suffixed with .local. A separate localconf parameter could optionally override this with a specific fqdn set by the user.

[SamuelDudley]

Sorry, I understand the tendawifi won't resolve. I was raising the issue as the hostname didnt update with maverick configure as I thought it would. The issue I face is that no hostname will resolve for the pi. Once it was set to maverick-raspberrylite.local it still would not resolve. Im sure that if I'm experiencing this there will be others. Just trying to come up with ways to make that initial connection easier and more reliable.

[fnoop]

• The hostname/fqdn for the system is really set in /etc/hosts, by the reverse of the primary IP.
• Avahi uses this fqdn to broadcast.
• Puppet uses this fqdn, because it gets it from facter, which gets it from system host resolution which gets it from /etc/hosts as top priority

So the only way really to address this is to allow the user to override the fqdn in localconf, which i've just pushed in https://github.com/goodrobots/maverick/commit/3486799fcfb691729e6b8831d971219f85486321. This allows you to set, eg: "fqdn": "maverick-nano.local",

This will override the system resolution.

Additionally, I've turned off dhcp/mdns in my meshed network and fallen back to my home router which uses .local, so future maverick images won't have this problem.

[fnoop]

Keeping open with Documentation flag for 1.2 release.

[SamuelDudley]

digging into this a bit further... The setup im running is a windows laptop, raspberrypi (running maverick) and an Android phone to act as a wifi access point (and www connection).

With this setup the pi is not reachable via the hostname from the windows PC or the android phone. The IP address works fine, but as maverick is serving the pages over https and the certificate is linked to the hostname https is rejected by the browser and then none of the websocket connections work :S ...

Granted that my current example is a little odd, but I can imagine a user in the field with a similar setup, unable to access the web interface. I'm not sure how to best approach this problem. Happy to help debug if you have any thoughts.

[fnoop]

Just looking into the SSL: https://github.com/goodrobots/maverick-web/issues/170

We could set unencrypted by default, or else add ws unencrypted ports to -api as well as wss, but webrtc requires encryption anyhoo, as does a lot of the newer browser/web technologies. I think we should just set everything encrypted by default except for discovery, and guide the user through the process of adding the CA certs to the browser/OS in as easy a manner as possible. It's actually not too bad

Windows doesn't have zeroconf, unless you've specifically installed apple's software, so nothing we can really do about that unfortunately. I believe it should work on android though.

So have you configured maverick-raspberry to use the phone as an access point? It's connecting OK?

[SamuelDudley]

Yep, connects to the phone 100% reliably every time the AP comes up. I was assuming that in the case of using the android phone as an access point the raspberry pi hostname would be resolved for me when attempting to access it via the windows machine?

In the case of the pi being the access point I assume it becomes the DNS server?

[SamuelDudley]

hmmmm... setting "fqdn": "maverick-raspberrylite.local", and running configure causes the hostname to be removed from /etc/hosts.

running maverick configure afterwards causes the ssl key and cert to bounce between xxxx.local-webssl and xxxx-webssl.

Also interesting is that post maverick-configure I could access the pi via the hostname from the windows machine, but that access stopped working after another maverick configure run. It's almost the case that when the pi itself cannot resolve maverick-raspberrylite, the windows pc can... really odd. Now I cant get it to resolve again...Perhaps its just my setup?

As it stands the the whole web stack is built around being able to resolve the hostname of the pi from another system, if that cant occur then -web becomes useless (no SSL, discovery fails to work, etc...) . If the issues I'm experiencing is related to my hardware setup and the issue is unresolvable from the maverick side (e.g. software and configuration that we can control), perhaps we need to document known working hardware solutions so we can point at something we know will work out of the box?

[fnoop]

hmmmm... setting "fqdn": "maverick-raspberrylite.local", and running configure causes the hostname to be removed from /etc/hosts.

Huh, that's not optimal. That needs to be fixed first, otherwise nothing will work.

[fnoop]

@SamuelDudley - OK so there was a flip-flop condition in the underlying puppet module which I've fixed. Can you try running configure again now? Edit: You might need to run configure twice to settle both the hostname and ssl cert names.

[SamuelDudley]

That last patch seemed to do the trick. I’ll keep trying to break it in the meantime ;)

[SamuelDudley]

sigh... Still having issues with the pi not being reachable via the hostname on my windows PC. It must just be the windows machine...

[fnoop]

Can you reach it reliably from non-windows? dumb question but do you have zeroconf installed on windows?

[SamuelDudley]

Yeah, installed the bonjour print services from here: https://support.apple.com/kb/DL999?locale=en_US

Its not accessible from my android device but it is from my ipad.

[SamuelDudley]

just fired up a ubuntu machine and that connected via hostname, no issues...

[SamuelDudley]

The fact that the hostname is sometimes reachable via the windows machine is the biggest pain point. I expect quite a few people will run into this issue, so having a online interface that they can access and experiment with will be important to 'sell' the effort required. Ideally we can also support SSL against the IP address, but I don't think it's possible?

[fnoop]

We can test as much as possible, and refine the zeroconf. It's quite a complicated system so there may be a bit of tweaking to get it reliable across different platforms. It works great for me from macos/linux but I haven't tested it yet with windows, android or ios. Also, the majority of the outstanding issues for Maverick 1.2 release are related to a networking refactor. The idea of the refactor is to have either a wifi hotspot or a hybrid managed/hotspot/p2p interface. In this case if the user connects directly through wifi then we will control the dhcp and dns, and we can serve hostnames over dns which is much more reliable across any platform. Let's keep this open and test/refine the process.

[TonyStark2007]

The fact that the hostname is sometimes reachable via the windows machine is the biggest pain point. I expect quite a few people will run into this issue, so having a online interface that they can access and experiment with will be important to 'sell' the effort required. Ideally we can also support SSL against the IP address, but I don't think it's possible?

I am facing the same issue and unable to access main page. How did you fix this problem? On ubuntu I can ssh using mav@maverick-raspberrylite.local but I can't access it through the browser. It just refuses the connection. Even connection through IP is refused.