Wifi issues, where to start diagnosing

[ludespeedny]

I have a 2 devices that are giving me headaches and not sure where to start diagnosing. I have a ax86u, running 3004.388.4, and diversion w/pixelserv (fresh install about a month ago). The 2 devices are a tv and a Raspberry Pi 4, both on 5ghz network (the 2.4 is separate ssid). The tv constantly is throwing a message wifi disconnected about every 5-10 min. The Raspberry Pi works fine till about overnight and then disconnects. The only way to get it reconnected is to reboot the router (rebooting the pi has no effect). It almost seems like the router is not accepting any connections. During this time if I disconnect my pc or phone on wifi I am unable to reconnect till the router is rebooted.
Any suggestions on where to start poking?

 

[ColinTaylor]

Disable Diversion and see if the TV's error messages stop. Some IoT devices don't like being blocked from accessing certain destinations and will perceive it as a connection failure and will repeatedly restart their network interface in an attempt to fix it.

 

[PunchCardBoss]

The 2 devices are a tv and a Raspberry Pi 4, both on 5ghz network (the 2.4 is separate ssid)

Are either of these devices assigned a static IP by your router or device?

 

[ludespeedny]

Disable Diversion and see if the TV's error messages stop. Some IoT devices don't like being blocked from accessing certain destinations and will perceive it as a connection failure and will repeatedly restart their network interface in an attempt to fix it.

I'll give that a shot today and see if it improves things.

Are either of these devices assigned a static IP by your router or device?

The Pi yes, TV no.

 

[PunchCardBoss]

The Pi yes, TV no.

That should be okay.

If @ColinTaylor advise doesn't work for you, you may want to try extending your router DHCP Lease time which is typically set to 1 day (per your comment)...

The Raspberry Pi works fine till about overnight and then disconnects

Then observe if your Pi disconnection time interval changes. If so, your Pi issue may be associated with a DHCP issue.

 

[ludespeedny]

Would the DHCP lease matter if assigned a static IP?

 

[PunchCardBoss]

Would the DHCP lease matter if assigned a static IP?

If the static IP is set on your Pi and not on your router - YES.
If the static IP is set on your Router and not on your Pi - Possibly (depending on your DHCP start and ending pool and Pi static assignment).

Your comment about your Pi loosing connection at night (once per day) made me think of a possible DHCP issue (since the std lease time is 24 hours). It is a long-shot, but since it is relatively easy to lengthen the DHCP lease time, it seems reasonable to try and eliminate DHCP as a possible issue.

 

[ludespeedny]

The Pi is set to static on the router side via dhcp list.

 

[PunchCardBoss]

The Pi is set to static on the router side via dhcp list.

As it should be.

So, if you double your DHCP lease time (from 24 ours to 48 hours), and your Pi still loses connection over night, you know that the issue is not DHCP related.

 

[ludespeedny]

Ok, I'll try both suggestions today and see what happens overnight.

 

[PunchCardBoss]

Ok, I'll try both suggestions today and see what happens overnight.

Diagnosing router issues are more typically difficult and time consuming. So don't give up if none of these suggestions work. There is more diagnosis that can be done.

There are many diagnosing strategies and styles. And there is no shortage of these styles from well-meaning contributors in this forum. It is not uncommon that contributor styles clash which makes for good entertainment.

Nevertheless, there are always two rules that will serve you well...
1. Change one setting at a time - then observe - and change back and observe again.
2. Keep a journal of your changes and observations. If you don't you will quickly lose track of what you have done and the observations of each change.

In your case, it is okay to change both suggestions for now. If you have success, however, you will not know which change was the solution. To find out, you will need to revert one of the changes and then observe.

If nether change solves your issues. Then revert both changes back to the way they were.

The next level of diagnostics will vary depending on the contributor's strategy and style. Personally, my next recommendations would focus on your 5Ghz settings by changing them to the most stable and conservative (which will compromise performance). If the most conservative settings don't show some improvements, then it gets very deep real fast.

 

[ludespeedny]

*Update
I was making the changes and rebooted the router. Then rebooted the devices with issues. I was unable to get the Pi to connect. I noticed the channel on wifi changed to 136. I changed it to 36 and it was able to connect. I wonder if the auto channel change was preventing it from connecting (maybe it was changing at night). Anyway, I got the devices connected and disabled Diversion and lengthened the lease to 48hrs and we will see if we can go without drops tonight.

 

[ludespeedny]

Got the wifi disconnected message only once last night on the TV and that was after powering on, so I assume it was from it coming out of standby (which I am ok with), at least it didn't keep popping. PI is still up this AM. I'll try re-enabling diversion today and see if anything changes (I think the Pi is set and has issues with channels over 100).

 

[PunchCardBoss]

I noticed the channel on wifi changed to 136. I changed it to 36 and it was able to connect.

That is a good catch and hint for what may be causing issues with your Pi. But the TV issue may be different.

There are three basic diagnostic approaches:
1. Shot in the dark
2. Clean baseline (Factory Reset)
3. Minimal configuration

Based on the minimal information in your Original Post (OP), both @ColinTaylor and I gave you our "Shot in the dark" guesses. Without more information, the next step is either a router Factory Reset to establish a clean baseline or a Minimal 5Ghz configuration. The choice between these two approaches depends on the contents of your next report.

If issues persist...
You can help the community by taking a screen shot of your System Log > WiFi Log. Scroll to the bottom and press the [Refresh] button. Then screen shot your 5Ghz "Station List" (the bottom table). Make sure you capture the "Connect Time" column all the way on the right side and the last few characters of the MAC address for each connected device. This screen shot will help others understand the performance of your 5Ghz band which will aid in the diagnostic strategy.

Another helpful screen shot is your System Log > General Log when your TV is having connection issues. You should be able to watch what your General Log is reporting during your TV connection issues. Just make sure the time stamp of your General Log matches during the time you are expensing TV issues.

 

[drinkingbird]

*Update
I was making the changes and rebooted the router. Then rebooted the devices with issues. I was unable to get the Pi to connect. I noticed the channel on wifi changed to 136. I changed it to 36 and it was able to connect. I wonder if the auto channel change was preventing it from connecting (maybe it was changing at night). Anyway, I got the devices connected and disabled Diversion and lengthened the lease to 48hrs and we will see if we can go without drops tonight.

Uncheck the "use DFS channels" and your issue will likely be solved.

 

[Morris]

Uncheck the "use DFS channels" and your issue will likely be solved.

I agree DFS cannels can cause a lot of issues. If this dose not correct your issue, set a fixed channel. This should not matter yet others have had similar issues to yours and this includes me. Changing to a fixed channel as Merlin suggested resolved the issue.

Good luck

 

[ludespeedny]

I have it disabled, but will stick to manual channel for now. What channels specifically are DFS?

 

[ColinTaylor]

What channels specifically are DFS?

52 to 144 if you're in the US.

 

[ludespeedny]

*update
All seems to be good. No issues with disconnects. I'll assume it was due to DFS channels. Thanks for the help!