Good morning Alta team! One of my two AP6-Pros rebooted this morning. No idea why. They were both already on 1.1b firmware. Are there any particular logs I can get for you that might help? I can watch for it to happen again and grab said logs if you instruct me on which ones you need.
@rutman286 It won’t help in this particular case, but if you want to enable persistent logs on the device(s), you can ssh to them and run “touch /cfg/.persistent.log”. Then reboot the device(s). If anything interesting happens, you can then scp the /var/log/messages* files and send them to us. Thank you for your feedback.
I might need some help on this one @Alta-Jeff. I have two AP6-Pros. The one that is not rebooting on its own, I was able to SSH in and run “touch /cfg/.persistent.log” with no issues. The one that IS rebooting (it did it again tonight, which is why I wanted to send you the log), once I SSH in and type touch, the SSH session hard locks up and I can’t type any more. I have to quick the session and SSH in again. I have not been able to successfully type in “touch /cfg/.persistent.log”.
If I let the broken session sit for about 30 seconds, I get this “touch / pclient_loop: send disconnect: Broken pipe”
Update… I did an experiment and found out that I cannot SSH properly with whatever AP I am connected to. For example, I have to SSH into the bedroom AP when I am in the kitchen. Then, I have to move to the bedroom, and SSH into the AP in the kitchen. It is repeatable by typing the “touch /cfg/.persistent.log”. I will never make it through typing that command if I am SSHd into the AP I am also wirelessly connected to. I have logs I captured right after a manual reboot during this experimenting. How do you want me to get them to you?
I had the same issue of being able to SSH into my AP and then it locks up after a few characters. My issue was my firewall rules blocking most traffic between my admin network and the management VLAN. I fixed it by temporarily putting my computer on the management VLAN which allowed me to SSH into the device without any issues. I now have a firewall rule that I can turn on and off when I need SSH access to the APs.
Good morning and thank you. The rebooting issue is important to me as well. I don’t want to lose sight of that. I’m not sure I am the only one having reboot issues either. I know it has come up in the thread more than once.
@rutman286 Based on the metrics I’m seeing, your situation does seem unique, and I’m at a loss for how you can possibly configure your network to block ssh in the way that you are describing…
I can ssh to any/all devices from anywhere no problem, but I generally use Alta Network Types to protect my network from IOT devices instead of using VLANs and firewall rules.
If you want to DM and invite me to your site, I’m happy to ensure that persistent logs are enabled, and then you can tell me the next time it looks like there’s a reboot.
I’m trying to figure out how to help more with the SSH weirdness. I tried wireshark locally on my laptop, but it didn’t help much. The AP just stops answering. I will set up a mirrored port on my switch and try again. Maybe it starts answering in a different vlan or something.
To be clear, I can SSH I to the AP just fine. But once I start typing commands the connection freezes
@rutman286 Are you ssh’ing on the same VLAN or through a router?
The SSH lockup only happens when I am trying to connect to the access point I am currently wirelessly connected through. Meaning, if I am on my laptop in my kitchen, I cannot SSH into the kitchen AP without the SSH session quickly locking up. However, if I stay in the kitchen and SSH into the AP in the bedroom, it works totally fine with no lock up. For reference, my APs are getting their DHCP from VLAN 1 (management VLAN), and my main SSID is VLAN 10.
I am at work right now, and through my wireguard VPN I can SSH into both APs and do whatever I need to do with no problem at all.
I really don’t know how it could be related… but after the 1.1d firmware update, the SSH problem is resolved for me. Absolutely nothing on my end has changed.
@rutman286 The ssh problem was actually directly related to the VLAN bridging issues that were addressed, so that makes perfect sense and is great to hear.