mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Help setting up WiFi
w9mt
Posts: 23
Joined: Mon Jul 15, 2019 2:40 pm

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by w9mt »

Jason:

Your suggestions have been most helpful, but to proceed, I need to ask some questions.

1. You say try pi-star 4.1 to see if that will fix my issues. My mmdvm uses a pi zero w. I don't believe there is a release beyond 3.4.17 for my hardware configuration. (Am I correct on this?)

2. You also suggest to disable power management for my RPi. I don't see where there is a setting for this for my pi zero w inside of the pi-star load I am running. Does it have a name I don't recognize when I go through the settings, including Expert mmdvm host mode?

3. Lastly, I'm a bit confused why power management would be different between my less capable AC-1900 wifi router in IL versus the later generation AC-3100 I'm using in AZ.

Can you point me in the right direction?

Thank you.

Tony, W9MT
AF6VN
Posts: 821
Joined: Fri Jul 20, 2018 1:15 am

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by AF6VN »

The only known criteria for R-Pi is that the 4B requires Pi-Star 4.1.x (it needs the base Debian Buster release of Raspbian for boot support). It may be that 3B+ also needs 4.1.x (I don't recall if Jessie was viable on 3B+; Jessie being what Pi-Star 3.x is based upon).

The Pi-Zero should support any version of Pi-Star. Note that the 4.1.x downloads are on the BETA page https://www.pistar.uk/beta/

--
AF6VN
Dennis L Bieber
User avatar
KE0FHS
Posts: 1122
Joined: Wed Apr 11, 2018 8:40 pm
Location: Colorado, USA
Contact:

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by KE0FHS »

The 3B+ and 3A+ also can use 4.0.x, but that beta codeline has been deprecated and isn't available for download anymore, so practically speaking, a new install for the 3B+ or 3A+ requires 4.1.x.
73, Toshen, KE0FHS
Playing with Pi-Star (unofficial notes about setting up and using Pi-Star):
https://amateurradionotes.com/pi-star.htm
kc7ngc
Posts: 48
Joined: Fri Sep 21, 2018 2:47 am

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by kc7ngc »

The ASUS routers are wonderful things when everything is cooperating. But with all the bells, whistles, buttons and whirligigs they can be a pain in the ars to troubleshoot when their advanced features get too advanced for some devices to handle. They have been causing headache for folks who use raspberry pi's with 3d printers and they been having issues similar to this with their Octopi installs.

In almost all cases disabling the WMM-APSD seemed to fix the problem. From the description it sounded like same issue. Where the device can talk on the network to things, but you can't talk to the device. ASUS routers are known for WMM-APSD issues. And since the PI's seem to work on other routers I think its one of the ASUS "Advanced" features causing the problem. When you disabled WMM-APSD, make sure you do so on both bands (2.4ghz and 5ghz), just found a note in another forum saying it doesn't really turn off unless you make sure to disable it for both bands. Even if your devices are only 2.4ghz.

In the rare chance that doesn't fix it, the other culprit could be the SmartConnect Feature (Band Steering). Which basically tries to tell devices to use a different WIFI channel or band for communication. For example it will try to push devices that have 2.4 and 5ghz radios to the 5ghz channel on the AP to increase their speed. But that breaks devices that ONLY have 2.4ghz radios.
https://www.asus.com/us/support/FAQ/1012132/
So if SmartConnect is on, might want to try turning it off.

I do agree that that trying the new 4.1.x beta would be a good step. I am running it on my Pi zero's without a problem. It does include the new kernel which does have new WIFI drivers. Which might allow the pi Zero and the ASUS to coexist peacefully.
w9mt
Posts: 23
Joined: Mon Jul 15, 2019 2:40 pm

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by w9mt »

A hearty "thank you" to all who replied to my ongoing dilemma.

I just did the simple thing just now by disabling WMM APSD also on the 5 GHz band on my router in addition to the 2.4 GHz band earlier. I'm going to see if that does the trick by watching the responsiveness of the mmdvm's overnight. I rebooted the router just to make sure everything starts from a known state. The mmdvm's are currently working.

If that fails, I'll do the "get power_save" change via the command line interface to both mmdvm units.

Lastly, I'll download v4 of pi-star and flash it onto another sdhc chip and do a setup for either my YSF or DMR mmdvm's and see if it fixes the one I update.

So I'll be attempting this 1,2,3 plan a step at a time and report back.

Much appreciated, guys...
73, Tony (W9MT)
w9mt
Posts: 23
Joined: Mon Jul 15, 2019 2:40 pm

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by w9mt »

Around 0815 MST this morning, the dashboards stopped updating for the YSF and DMR mmdvm's. Trying a dashboard query on each led to a timeout message, with the two mmdvm's displays still showing on-channel (room/TG) activity.

At 1335 MST I power cycled the DMR mmdvm, but not the YSF one. Then I rebooted the router. After the leisurely reboot, both mmdvm's again respond like they should.

I'm going to watch them and see when/if they go mute again. I expect that to happen within 12 hours or so. If/when it does, the next step is aforementioned (one post ago) Step 2. I'll be doing a CLI edit for the power_save function and see if that does the trick.

Stay tuned...

73, Tony (W9MT)
w9mt
Posts: 23
Joined: Mon Jul 15, 2019 2:40 pm

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by w9mt »

Oh, yeah...one more thing...

I do have wifi Smart Connect disabled on my router.

tony w9mt
AF6VN
Posts: 821
Joined: Fri Jul 20, 2018 1:15 am

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by AF6VN »

w9mt wrote: Fri Dec 06, 2019 8:40 pm At 1335 MST I power cycled the DMR mmdvm, but not the YSF one. Then I rebooted the router. After the leisurely reboot, both mmdvm's again respond like they should.
Which behavior sure seems to point to a problem with the /router/, not the Pi-Star boxes.

If both boxes became "live" after a router reboot, it implies the boxes are operating properly. One would need to be running something like WireShark (is it available for R-Pis? since one really needs to find out what the Pi-Star<>router traffic contains; monitoring from another computer may not see all the packets if the router doesn't forward them) -- Probably looking for packets related to DHCP (I can easily visualize the Pi-Star sending DHCP requests and not getting responses from the router).

--
AF6VN
Dennis L Bieber
kc7ngc
Posts: 48
Joined: Fri Sep 21, 2018 2:47 am

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by kc7ngc »

w9mt wrote: Fri Dec 06, 2019 8:45 pm Oh, yeah...one more thing...

I do have wifi Smart Connect disabled on my router.

tony w9mt
Ok, this is just yet another shot in the dark. As opened an issue about this because of 5ghz issues and Andy has been working on fixing it the last few days but most people don't have the fix or even know about it yet. Apologize if this has been asked and answered earlier on in the thread.

What is the "country=" setting in the /etc/wpa_supplicant/wpa_supplicant.conf file on the raspberry pi? I am betting that its "COUNTRY=JP" which is what has been the default for many reasons (covered in another thread). Might want to try manually editing that and changing it to "COUNTRY=US" and reboot them and see if it makes a difference.
kc7ngc
Posts: 48
Joined: Fri Sep 21, 2018 2:47 am

Re: mmdvm's connect ok and after a period of days or hours ignore pi-star.local access

Post by kc7ngc »

KE7FNS wrote: Sat Dec 07, 2019 8:47 pm I don't think that setting is related or would make any difference. It also doesn't explain why everything worked fine on his older model ASUS router. Also the RPi Zero W doesn't have 5 Ghz support so the major 5 Ghz differences you mentioned in the other thread are never involved. If it was a channel or band issue he would be experiencing a complete loss of connection rather than the works fine for X amount of hours and then disappears issue.
For one COUNTRY=JP limits 2.4ghz band radio to 2/3 the EIRP than COUNTRY=US. It's also a known issue with ASUS-WRT with some broadcom chip firmwares's as if a router supports 802.11d then it will broadcast is country codes out to a device. When the radio in the broadcom chipsets get the conflicting information between the 802.11d broadcast and the internal config the kernel can fall back to a state where they are being safe. The state can hamper wifi throughput and connection state. You can see it occur when wpa_supplicant has logging enabled. Figured it would easier to try fixing country code instead of trying to find where ASUS-WRT buried the option for disabling 802.11d. Older ASUS routers don't support 802.11d and news ones due and usually have it on by default.

Actually to me it makes perfect sense that the can establish connections and move data when it initiates it but can't when the connection originates from outside the pi because how the communication is negotiated in WIFI. If ASUS router is making assumptions about the device that are different than what device is configured, then device can initiate communication and poll for packets but router might not be able to initiate a connection to the device and just be throwing bits into the void. Which would also explain why UDP (radio traffic) seems to flow but TCP traffic (dashboard) does not. Knowing what I know about the merlin firmware and asus routers been trying to go through the list of what those things have been in the past.

Power save is off by default on the 4.1 image as its set that way in wlan0 config. OP mentioned he was trying the 4.1 branch. So if using the 4.1 branch the power save is very unlikely the problem.
Post Reply