-
Notifications
You must be signed in to change notification settings - Fork 61
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.
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
initial connections and hostname problems #931
Comments
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.
|
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. |
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 3486799. This allows you to set, eg: 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. |
Keeping open with Documentation flag for 1.2 release. |
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. |
Just looking into the SSL: 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? |
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? |
hmmmm... setting running Also interesting is that post 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? |
Huh, that's not optimal. That needs to be fixed first, otherwise nothing will work. |
@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? |
That last patch seemed to do the trick. I’ll keep trying to break it in the meantime ;) |
sigh... Still having issues with the pi not being reachable via the hostname on my windows PC. It must just be the windows machine... |
Can you reach it reliably from non-windows? |
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. |
just fired up a ubuntu machine and that connected via hostname, no issues... |
The fact that the hostname is sometimes reachable via the windows machine is the biggest pain point. |
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. |
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. |
pi3b+
1.2-b image
The hostname is
maverick-raspberrylite.tendawifi.com
self-update
andmaverick 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?
The text was updated successfully, but these errors were encountered: