Problems with installation when using ssh or VNC

[lole-elol]

When i tried installing Hassio using an ssh terminal via PutTTy or VNC on Windows Hassio was not installed.
However when using a seperate monitor it worked fine.
The pi was conected via wifi the whole time.

[Paraphraser]

See if this might explain what you saw - https://gist.github.com/Paraphraser/55643bd660db46716f6c81266905cae8#hassio-support-optional (just that bit of the gist - the rest is out-of-date).

[lole-elol]

i now do sort of understand why it loses the ssh connection. But i dont understand how being connected via ssh affects the succesfull installation of hass, since it worked fine via wifi when the installation was done with an external monitor.

[Paraphraser]

When you are connected via an external monitor, that's the HDMI port. There is no "networking" (data communications) involved.

When you connect to a Raspberry Pi via SSH, that's a protocol that is riding on top of TCP/IP. SSH (a layer 7 protocol) uses TCP (a layer 4 connection-oriented protocol) which rides on IP (the layer 3 protocol). So far, so good.

But, then, you also need to know what happens at layers 2 and 1. When your SSH client (eg Mac or PC or another Unix box) opens its ssh connection, at layer 3 the IP stack uses the subnet mask against both the source (Mac, PC, etc) and destination (Raspberry Pi) IP addresses to split them into "network portion" (on the left) and "host portion" on the right. It then compares the two network portions and, if they are the same, it says "local network".

(To complete the picture, if they do not compare the same, then IP substitutes the so-called "default gateway" address (ie your router) and repeats the mask-and-compare process which, unless something is seriously mis-configured, will result in those comparing the same and being "local network").

What happens next depends on the media but we'll assume Ethernet and WiFi seeing as they are pretty much interchangeable for our purposes.

The source machine (Mac, PC, etc) issues an ARP (address resolution protocol). It is a broadcast frame (we talk about "frames" rather than "packets" at Layer 2) asking the question, "who has this destination IP address?" The Raspberry Pi responds with a unicast packet saying, "that's me" and part of that includes the MAC (media access control) address of the Raspberry Pi. The source machine only does this once (and this is a key point). It assumes the relationship between IP address and MAC address will not change and it adds the relationship to its "ARP cache".

The Raspberry Pi makes the same assumption: it has learned both the IP and MAC address of the source machine (Mac, PC, etc) and has added that to its own cache.

In addition, every layer two switch (got one of those in your home?) has been snooping on this traffic and has learned, for each of its ports, which MAC address(es) are on those ports. When it saw the ARP broadcast, it replicated that out of all of its ports but when the "that's me" came back from the Raspberry Pi as a unicast response, it only went out on the switch port where the source machine (Mac, PC, etc) was attached.

After that, it's all caching. The Mac/PC has a packet to send to the Pi. It finds the hit in its ARP cache, wraps the packet in a frame and sends it out its Ethernet or WiFi interface. Any switches receive the frame, consult their own tables, and send the frame out the port on the next hop to the destination device. It doesn't matter whether you have one switch or several in a cascade, they have all learned the "next hop" to each destination device they have seen.

Ditto when the Pi sends back any reply packets. ARP. Switch. Mac/PC. All cached.

I'll add that the same basic principles apply, irrespective of whether the "switching function" is wired (Ethernet) or WiFi so it doesn't really matter if your home arrangement is as straightforward as Mac/PC and Pi, both WiFi, via a local WiFi "hub" which is either standalone or part of your router. If something is capable of learning where a MAC is, it does.

Still so far so good.

Now comes the problem. You have established an SSH session connected to the Pi over its WiFi interface. You install Network Manager. As part of its setup, Network Manager discards the fixed MAC address which is burned into the Pi's WiFi interface and substitutes a random MAC address. It doesn't ask. It doesn't warn. It Just Does.

When the WiFi interface comes up, it almost certainly "speaks" straight away via DHCP to ask for an IP address. The DHCP server looks in its own table of MAC-to-IP associations (fixed or dynamic, doesn't matter) and says "never seen that MAC before - here's a brand new lease".

DHCP is broadcast so all the switches will have learned the new MAC but they'll also still have the old MAC. The Mac/PC will receive the DHCP broadcast but will discard it (unless it's the DHCP server, I suppose) but it has no way of knowing that this new random MAC belongs to the Pi so it can't do anything sensible.

Meanwhile, SSH is trying to keep the session alive. It still thinks "old IP address" and the ARP cache still thinks old IP belongs to old MAC. It emits the packet. Switches know where it is meant to go but even if the frame does get somewhere near the Pi, the Pi's NIC (network interface card) ignores it because it's the wrong MAC. The upshot is that SSH looks like the session has frozen and it will eventually time-out with a broken pipe.

To summarise: Network Manager has changed the MAC without so much as a by-your-leave and, unless you have assigned static IP addresses in the Raspberry Pi it's quite likely that the Pi will have a different IP address as well. But even a static IP can't save you from the machinations of Network Manager!

The Pi is as happy as the proverbial Larry. It goes on, blissfully unaware that it has just confused the heck out of everything else. You can speed-up some of the activities that need to happen before everything gets going again. You can do things like clear the old entry from the ARP cache on the Mac/PC. You can try to force a multicast DNS daemon restart so that the "raspberrypi.local" address gets updated more quickly but mDNS is a distributed database so it can be hit and miss. Usually, the most effective thing you can do is pull power from the Pi, reboot your Mac/PC (easiest way to clear the ARP cache) and then apply power to the Pi so that it announces its mDNS address at the right time for the newly-booted Mac/PC to hear it.

That's why the link I gave you says words to the effect of, "whatever else you do, DON'T try to get all this going over WiFi. If ssh is how you're going to do it, you're in for a world of pain if you don't run an Ethernet cable for at least this part of the process."

And it does get worse, of course. Installing Network Manager turns on random WiFi MAC. You can turn it off and go back to the fixed MAC. But then, when you install IOTstack, it happens again. And those are just the two I know about. It may be that other packages come along and say, "hey, look, Network Manager is installed - let's take advantage of that" and it happens again when you least expect it.

I know it's easy to say but my honest opinion is that, if the answer to "how do I solve this problem?" involves "Network Manager" then it's the wrong question and you need a different problem. I really do not get the arrogance of the people behind that package thinking it is OK to switch on random WiFi MAC as a default. It'd be perfectly OK if it was an option users could choose to turn on if they were persuaded by the "security" argument and decided that the benefits of activating the feature outweighed the hassle. That would be "informed consent". But forcing it? No way José.

Anyway, I hope you see why HDMI wasn't affected by any of this, and why any open session connected to the Pi via its Ethernet port also would not have been affected. The Pi itself was still changing its WiFi MAC. Anything that had initiated a connection to the Pi via WiFi before Network Manager fired up would have been as confused as the SSH session we are talking about. Any connection that the Pi had initiated over WiFi would likely have suffered a similar fate because the TCP ACK packets would not be able to find their way back. But, if the Pi was "quiescent" in terms of other data-comms traffic during that time, you probably wouldn't have noticed. SSH is just a bit too in-ya-face for problems to pass unnoticed.

[lole-elol]

Wow i am really impressed by how detailed this answer is.
Thnaks a lot for taking the time explaing this.
Best answer i received on a question so far !!

Maybe we could link this issue in the documentation for people who want to get more details, since you expalined it so nicely
what do you @Paraphraser think ?

[Paraphraser]

I was thinking of amalgamating the bit from the gist about hass.io setup with the existing doco. That's mainly because it's time for the rest of the gist to be retired. I could link to this issue when I do that.

[dylanpoll]

I just want to mention here that I was able to easily bypass this issue by using the nohup command prior and editing the linked raw .sh file on IOTstack/blob/master/.native/hassio_supervisor.sh
https://raw.githubusercontent.com/Kanga-Who/home-assistant/master/supervised-installer.sh

I just manually keyed in the details while removing the if conditional wrappers
MACHINE=
HASSIO_DOCKER=

and removed the read answer for the overwriting the /etc/network/interfaces file along with the if condition...

that way, as pointed out above, the process wouldn't be interrupted from the remote session dropping midway as nohup disowns the command as the start of it running. I then just pulled up my pi by ssh by getting the new ip from my router and did the tweak on the site.

I ended up getting it working without using ethernet or directly plugging in, this may not work for all, you can also try screens where it will work and detach before the process starts. I did manually install network manager prior using nohup as well.

this ends up looking like the above raw .sh link but with the following changed.
at around line 97

info "Creating NetworkManager configuration"
curl -sL "${URL_NM_CONF}" > "${FILE_NM_CONF}"
if [ ! -f "$FILE_NM_CONNECTION" ]; then
    curl -sL "${URL_NM_CONNECTION}" > "${FILE_NM_CONNECTION}"
fi

warn "Changes are needed to the /etc/network/interfaces file"
info "If you have modified the network on the host manualy, those can now be overwritten"
info "If you do no the /etc/network/interfacest overwrite this now you need to manually adjust it later"
info "Do you want to proceed with overwriting file? [N/y] "
#i changed the next line
ANSWER="y"
if [[ "$ANSWER" =~ "y" ]] || [[ "$ANSWER" =~ "Y" ]]; then
    info "Replacing /etc/network/interfaces"
    curl -sL "${URL_INTERFACES}" > "${FILE_INTERFACES}";
fi

info "Restarting NetworkManager"
systemctl restart "${SERVICE_NM}"

starting at around line 150

# Generate hardware options
#case $ARCH in
#    "i386" | "i686")
#        MACHINE=${MACHINE:=qemux86}
#        HASSIO_DOCKER="$DOCKER_REPO/i386-hassio-supervisor"
#    ;;
#    "x86_64")
#        MACHINE=${MACHINE:=qemux86-64}
#        HASSIO_DOCKER="$DOCKER_REPO/amd64-hassio-supervisor"
#    ;;
#    "arm" |"armv6l")
#        if [ -z $MACHINE ]; then
#            error "Please set machine for $ARCH"
#        fi
#        HASSIO_DOCKER="$DOCKER_REPO/armhf-hassio-supervisor"
#    ;;
#    "armv7l")
#        if [ -z $MACHINE ]; then
#            error "Please set machine for $ARCH"
#        fi
#        HASSIO_DOCKER="$DOCKER_REPO/armv7-hassio-supervisor"
#    ;;
#    "aarch64")
#        if [ -z $MACHINE ]; then
#            error "Please set machine for $ARCH"
#        fi
        HASSIO_DOCKER="$DOCKER_REPO/aarch64-hassio-supervisor"
#    ;;
#    *)
#        error "$ARCH unknown!"
#    ;;
#esac

#adding in this next line
MACHINE="raspberrypi4-64"

if [[ ! "${MACHINE}" =~ ^(intel-nuc|odroid-c2|odroid-n2|odroid-xu|qemuarm|qemuarm-64|qemux86|qemux86-64|raspberrypi|raspberrypi2|raspberrypi3|raspberrypi4|raspberrypi3-64|raspberrypi4-64|tinker)$ ]]; then
    error "Unknown machine type ${MACHINE}!"
fi

I know you can easily just change the ARCH= value to aarch64 but I didn't want to leave the conditional in there and this worked...

[Paraphraser]

Hass.io now out of the picture. Should probably be considered stale.