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.
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.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.
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.
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.
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 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.