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

Help setting up WiFi
w9mt
Posts: 19
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 » Fri Dec 06, 2019 3:33 am

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: 19
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 » Fri Dec 06, 2019 8:40 pm

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: 19
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 » Fri Dec 06, 2019 8:45 pm

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

I do have wifi Smart Connect disabled on my router.

tony w9mt

AF6VN
Posts: 466
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 » Sat Dec 07, 2019 4:58 pm

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 » Sat Dec 07, 2019 6:17 pm

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.

KE7FNS
Posts: 943
Joined: Wed Apr 17, 2019 11:11 pm

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

Post by KE7FNS » Sat Dec 07, 2019 8:47 pm

kc7ngc wrote:
Sat Dec 07, 2019 6:17 pm
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.
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.

I'm having a hard time accepting that the router is maintaining the incoming traffic from the master to the RPi, but at the same time the dashboard is inaccessible. I just don't see how that could be possible, if the router couldn't find it for one situation, it shouldn't be able to find it for the other unless maybe there are separate internal and external lookup tables. I'm beginning to wonder if having multiple RPi's all using the same port numbers (like 80 for the dashboard) and different IP's is complicating things somehow.

To the OP can you just post the result of the wifi power save query? Its driving me nuts you have taken this long for such a simple thing. I understand your step by step procedures you are following, but that command I posted doesn't change or set anything it just tells you what it is set to, so it can't affect any of your tests.
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol:

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 » Sat Dec 07, 2019 9:58 pm

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.

KE7FNS
Posts: 943
Joined: Wed Apr 17, 2019 11:11 pm

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

Post by KE7FNS » Sun Dec 08, 2019 4:36 am

kc7ngc wrote:
Sat Dec 07, 2019 9:58 pm
For one COUNTRY=JP limits 2.4ghz band radio to 2/3 the EIRP than COUNTRY=US.
I seriously doubt that anyone is using a wifi connection at that far of a distance away from their router where a lower power would come into play and again it doesn't explain his timeout issue.
kc7ngc wrote:
Sat Dec 07, 2019 9:58 pm
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.
Wait what??? That isn't what he is describing at all. He said that incoming traffic from outside the network IS still being passed through the router to the RPi, while local traffic to the dashboard is unavailable. Both of those wifi network transmissions would originate at the router and go to the RPi over wifi, its just that one started on the external network, while the other started on the internal network.

I'm having a difficult time following your posts, you seem to be leaving out a few words at random. I really noticed it in the other thread with your technical discussion about the multiple wpa_suppicant processes.
kc7ngc wrote:
Sat Dec 07, 2019 9:58 pm
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.
Yes, I am fully aware of that, but really what it is defaulted to in the most recent images available to download is irrelevant, because you don't know that the OP installed pi-star from that same image with those settings. He could of used an image from last year where it could of been defaulted to on, and ran the upgrades to bring it to the latest version, and yet the wifi power save is unchanged and still set to on.

If it was always defaulted to off in older versions of pi-star, then the posts about how to turn it off wouldn't of been needed.

So the question is, what is the OP's wifi power save setting currently set to on his devices using 3.4.17, and only he can provide that information, and for some reason its taking way too long.
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol:

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 » Sun Dec 08, 2019 7:41 am

KE7FNS wrote:
Sun Dec 08, 2019 4:36 am
I seriously doubt that anyone is using a wifi connection at that far of a distance away from their router where a lower power would come into play and again it doesn't explain his timeout issue.
I blame my math on my cold medicine. As looked at the dbm number and my brain must of died as not sure where I got 2/3. Well I can see it now but anyway correct math and numbers are.

Japan = 20dbm = 200mw
(2402.000 - 2482.000 @ 40.000), (20.00), (N/A)

US = 30dbm = 1000mw
(2402.000 - 2472.000 @ 40.000), (30.00), (N/A)

Japan mode limited to 200mw, while US mode can use a full watt. So JP is potentially 1/5 max power output.
Whether its the power output or not. It is a well documented problem that wrong country code causes dropouts on networks. Which is why I mentioned it.
KE7FNS wrote:
Sun Dec 08, 2019 4:36 am

Wait what??? That isn't what he is describing at all. He said that incoming traffic from outside the network IS still being passed through the router to the RPi, while local traffic to the dashboard is unavailable. Both of those wifi network transmissions would originate at the router and go to the RPi over wifi, its just that one started on the external network, while the other started on the internal network.
It can very much be what the OP is describing. All modern access point/routers have some type of queue and schedule mechanism to maximize throughput. When the pi-star comes up it creates a link out of the network through the ap/router and the firewall. While doing so the protocols are actively driven by the Pi-star as their link to master/reflectors/what have you are initiated by the pi-star. It sends out packets routinely to maintain the link and keeps the pipe through NAT firewall open allowing traffic to come back in. So it is all started by the Pi-star which also creates a mapping entry inside the WMM /QOS/NAT tables in the router. The access point uses these mappings to determine how outside traffic gets back to the device.

This gives you an interesting effect that traffic in conversation can buffer up a bit, then when AP hear's the client sending traffic in an established flow it will (keep alive, etc) it sends the buffered data to the PI and will do so at the frequency/channel width/etc that it heard from the pi.

With a tcp connection to the dashboard, you are creating the connection from outside the Pi. Which is new WMM/QOS mapping that doesn't go through the NAT table and so is a new flow. That new flow doesn't have a queue, so the SYN will be sent out the PI, potentially on wrong HT or even in wrong mode. It wouldn't be the first time I have seen that happen.

I have been just trying to help OP figure out why the ASUS-WRT router is confused with the PI and what temporal phenomenon could be involved. Since the PI works on a different ASUS router just fine, it would seem to indicate its one of the advanced features on the new unit causing an issue. Could be a wifi issue or even could be the stupid AI engine in the ASUS-WRT has designed the dashboard connect attempts are malicious and dropping them. (Netgear R8000 had that problem with port 8080 awhile back). But getting a proper wifi configuration is one of the first places to start.
KE7FNS wrote:
Sun Dec 08, 2019 4:36 am
I'm having a difficult time following your posts, you seem to be leaving out a few words at random. I really noticed it in the other thread with your technical discussion about the multiple wpa_supplicant processes.
I apologize been home most of week with the flu and have enough cold medicine in me to tranquilize an elephant. That combined with my lack of sleep and visits to pay tribute to the porcelain god. My train of though hasn't always been to cohesive.

KE7FNS wrote:
Sun Dec 08, 2019 4:36 am
Yes, I am fully aware of that, but really what it is defaulted to in the most recent images available to download is irrelevant, because you don't know that the OP installed pi-star from that same image with those settings. He could of used an image from last year where it could of been defaulted to on, and ran the upgrades to bring it to the latest version, and yet the wifi power save is unchanged and still set to on.
On the 5th the OP posted he was going to download V4 from the website and was now trying to test with that. On the 6th he posted it still wasn't working. I missed his comment that he was going to move on to step 2. I had falsely assumed he had already tried v4 and it had failed as well when he hadn't explicitly said that. So I will take the blame for that.

KE7FNS
Posts: 943
Joined: Wed Apr 17, 2019 11:11 pm

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

Post by KE7FNS » Sun Dec 08, 2019 9:07 pm

kc7ngc wrote:
Sun Dec 08, 2019 7:41 am
Japan mode limited to 200mw, while US mode can use a full watt. So JP is potentially 1/5 max power output.
Whether its the power output or not. It is a well documented problem that wrong country code causes dropouts on networks. Which is why I mentioned it.
Is it that well documented?? Pretty much every pi-star in operation outside of Japan has been running in the same sort of mismatched configuration for quite a while now. I would think the forum would be full of complaints.
kc7ngc wrote:
Sun Dec 08, 2019 7:41 am
I have been just trying to help OP figure out why the ASUS-WRT router is confused with the PI and what temporal phenomenon could be involved. Since the PI works on a different ASUS router just fine, it would seem to indicate its one of the advanced features on the new unit causing an issue. Could be a wifi issue or even could be the stupid AI engine in the ASUS-WRT has designed the dashboard connect attempts are malicious and dropping them. (Netgear R8000 had that problem with port 8080 awhile back). But getting a proper wifi configuration is one of the first places to start.
You have been helping, we are all trying to help. I agree on an advanced feature maybe being the cause of the issue.

I have another theory that the nightly updates are severing the connections when the services are stopped and for some reason they are not getting restored properly, but it is not really worth investigating at this moment, and made even more difficult without access to the specific hardware in question.
kc7ngc wrote:
Sun Dec 08, 2019 7:41 am
I apologize been home most of week with the flu and have enough cold medicine in me to tranquilize an elephant. That combined with my lack of sleep and visits to pay tribute to the porcelain god. My train of though hasn't always been to cohesive.
Sorry, hope you feel better soon.
kc7ngc wrote:
Sun Dec 08, 2019 7:41 am
On the 5th the OP posted he was going to download V4 from the website and was now trying to test with that. On the 6th he posted it still wasn't working. I missed his comment that he was going to move on to step 2. I had falsely assumed he had already tried v4 and it had failed as well when he hadn't explicitly said that. So I will take the blame for that.
No big deal, it is easy to skip over those sorts of details in the expanding thread.

I guess the silence from the OP means that he either hasn't tested anything or he hasn't experienced any more failures and his problem has been solved.
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol:

Post Reply