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

Help setting up WiFi
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: Sun Dec 08, 2019 4:36 amI 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.
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 »

Ok, I've got the old load 3.4.17 running in pi-star0 mmdvm (YSF) and the 4.1.0-RC4 new beta load running in the DMR mmdvm now entitled pi-star2a. (I kept the old sdhc chip containing name pi-star2 with its old 01/2019 3.4.17 load using the same DMR settings.)

My heart sank when the new DMR pi-star load went "ignorant" to dashboard queries and simple updates to the info on an open and active dashboard tab on my laptop. The YSF older load on the other mmdvm also froze to queries a few hours later.

I had a hamfest to go to that day and didn't bother rebooting or resetting anything. Then something weird happened...

When I got back from Mesa AZ (near PHX) and back to my AZ QTH in Vail AZ (near Tucson) about 12 hours later, both mmdvm's were again responding (sometimes albeit more slowly) to dashboard queries again. This is Sunday night, more than another day later and they STILL are behaving.

I really don't like things that "fix themselves", as they usually "unfix themselves" at some future point. I did NOT do the command line interface suggestion that another poster had recommended for the RPi "power_save" disabling function, either.

Anyone have any idea what is haunting my home network? (For now things seem to be running and I'm going to leave them alone and see what develops !!!)
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 »

Because it was the newer 4.0 load that failed and turned "ignorant" on Saturday morning prior to my drive to a distant hamfest.

When I got home, both of my mmdvm's with the new 4.0 load (DMR) and the old load 3.4.17 (Fusion) both started working. They have not failed since.

Nothing's currently broken, so right now there's nothing to fix. I'm gonna let the "sleeping dog lie".

Rest assured, if the problem returns, the recommended CLI function will be the first thing I will try in order to get more data, and then proceed from there.

For now, I'd be chasing something that's perfectly functional. I'll let if fail first, or just let it run forever...be it the mystery it is....

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 »

No, I understood you quite well.

I just have other fish to fry, and when I get to it, I will be happy to post the exact results. I am just as curious to examine the state of the setting as you are, but the holidays are coming. I've neglected stuff that needs to be done around the house, and this issue and getting a Hardrock 50 amp I bought for my FT-817, supposedly "like new" at a hamfest (it didn't work either) truly turned my 50 year ham radio hobby into an all-encompassing obsession for the past several weeks.

It's time to change direction and come back to this later. I'd also like to see how long this continues to work. So, that's MY choice. I will be stopping the pursuit for now at this point. But, I truly appreciated your recommendation and rest assured, it WILL happen, and I'll report it back here at that time for all to benefit from and see.

So, don't let this trouble you. I'm sure whatever the normal default for that setting should be is what it is, not only for me, but all pi-star users.

73, and best of the holiday season...and stay tuned...
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 »

No, I haven't changed anything further in today's current set up's from what I previously posted, but I'm seeing what looks like a suspicious correlation...

In AZ, I live in an area with Cox's high speed internet. I pay for 300Mbps service so throughput right now shouldn't be a concern...when things are working. Intermittent drops in the connection to the cable modem recently have been common. With my area exploding in population (hundreds of new houses going in, and plans for up to 6000 to be eventually built), the neighborhood blog has been complaining about wide spread outages lasting from many minutes to hours.

When I bought my first assembled mmdvm, and then built two more from kits, I was at my alternate QTH in IL, where I have Comcast's Xfinity service (250Mbps, max). There was not one single drop in service at that street address from the time I put the mmdvm's into service until I brought them to AZ in October.

That's when the trouble began. I'm beginning to think that the pi-star software may have been doing a data transaction over the wider Internet during one of the spotty drops which lead the software into some kind of indeterminant state, causing my originally described "ignorant to dashboard requests over local wifi" issue and drops in communications on DMR and YSF (especially) during QSO's whilst ignorant to wifi queries on the home network.

I've recently queried my D-LInk C500 DOCSYS 3.0 cable modem, and the "critical" events (including the "wifi ignorant response" ones seem to be correlating from a time and date stamp comparison.

I've also noticed that the service connection drops have seemed to have stopped this past week and I haven't had a single problem from the mmdvm's.

Coincidence? I don't think so, but I really cannot say with 100% certainty, and will continue to monitor the situation.
Post Reply