-
Yes, of course if You say so. But right now we have 2,4, 5 and 6 Ghz WiFi frequency. Stable version works great with both frequency. Some my device has problem with web encryption so I use in this case 2.4 ghz with medium security. I found some case on Internet with 5 Ghz connectivity with 802.11w Protected Management Frames option in router settings. Maybe this is issue with my case?
-
I try install RP 2024.03.92 [1528] beta version - still no good.
@spockfish I’m 100% shure that web encryption making this issue when I change encryption to
“WPA-PSK/WPA2-PSK mixed mode” works ok in 5 ghz wifi
When change to better (default) encryption “WPA2-PSK/WPA3-SAE mixed mode” can’t connect.
This is a difference.
Please show my log from router:
WPA2-PSK/WPA3-SAE - confuguration
Sun Apr 14 10:38:56 2024 daemon.info hostapd: phy1-ap0: STA *:*:* IEEE 802.11: authenticated
Sun Apr 14 10:42:30 2024 daemon.info hostapd: phy1-ap0: STA *:*:* IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
WPA-PSK/WPA2-PSK - confuguration
Sun Apr 14 11:47:24 2024 daemon.info hostapd: phy1-ap0: STA *:*:* IEEE 802.11: authenticated
Sun Apr 14 11:47:24 2024 daemon.info hostapd: phy1-ap0: STA *:*:* IEEE 802.11: associated (aid 4)
Sun Apr 14 11:47:24 2024 daemon.notice hostapd: phy1-ap0: AP-STA-CONNECTED *:*:* auth_alg=open
Sun Apr 14 11:47:24 2024 daemon.info hostapd: phy1-ap0: STA *:*:* WPA: pairwise key handshake completed (RSN)
Sun Apr 14 11:47:24 2024 daemon.notice hostapd: phy1-ap0: EAPOL-4WAY-HS-COMPLETED *:*:*
Sun Apr 14 11:47:29 2024 daemon.info dnsmasq-dhcp[1]: DHCPDISCOVER(br-lan) *:*:*
Sun Apr 14 11:47:29 2024 daemon.info dnsmasq-dhcp[1]: DHCPOFFER(br-lan) 192.168.0.200 *:*:*
Sun Apr 14 11:47:29 2024 daemon.info dnsmasq-dhcp[1]: DHCPREQUEST(br-lan) 192.168.0.200 *:*:*
Sun Apr 14 11:47:29 2024 daemon.info dnsmasq-dhcp[1]: DHCPACK(br-lan) 192.168.0.200 *:*:* RoPieee
Quick search revealed that mixed mode WPA3-SAE is a problem on the Pi, potentially related to the firmware of the ethernet chipset (broadcom). So I suggest you revert to WPA-PSK, at least for now.
Thanks
Ok I will do that until You found solution about this issue. Wifi 2,4 Ghz works terrible in my area because is to much user in my neighborhood. From here I have to use 5 GHz WiFi.
Thank You so much
Regards
Beta update has arrived and been installed. All seems to be working here, screen and touchscreen OK.
And in the previous build it wasn’t, right?
All three units here are working fine. I also tested the UPnP/DLNA “apply” and it seems to work (not that I use it, just that it accepted the apply button this time).
Both RPi4s are on RoPieee 2024.03.92 (1528) [beta]. Kernel version: 6.6.25-SPCKFSH-v8+
The RPi3B is on RoPieee 2024.03.92 (1527) [beta]. Kernel version: 6.6.25-SPCKFSH-v7+
Unit 1
- Hardware: Raspberry Pi 4 Model B Rev 1.5
- Network: ethernet
- Audio: USB Inmotion Air
- Display: No
- Remote: No
Unit 2
- Hardware: Raspberry Pi 4 Model B Rev 1.5
- Network: ethernet
- Audio: USB to Schiit Fulla/UE boom 2
- Display: No
- Remote: No
Unit 3
- Hardware: Raspberry Pi 3 Model B Rev 1.2
- Network: ethernet
- Audio: digi+ pro hat optical and coax to KEF LS50W and Schiit Yggdrasil
- Display: Yes
- Remote: OSMC
clicked install button to apply latest beta (2024.03.92 build 1528)
after reboot, it doesn’t look like the beta applied successfully … device still running prior beta (2024.03.91 build 1519) … and my audio device has disappeared (Allo DigiOne HAT … still shows as selected in RoPieee web interface, but it’s not enabled/available)
feedback 691b06a5dad44f27
device details …
Thanks for your feedback. I see what went wrong.
You can try again if you want to, I’ve got enough info.
thanks, will try again in a bit
(assume i need to wait a while for update to download again etc)
Well done Harry @spockfish my wife just commented “oh is ropieee dead?” And went to see if any update and there was and it’s all good again…happy wife happy life. Now she can see it’s time for bed
if headless Plexamp is idle (no active or paused queue), it should not hold onto the audio device
the flow that indefinitely holds the audio device goes like this …
- start playback on a remote device (Plexamp on phone, desktop, etc.)
- connect and transfer playback to headless
- pause playback on headless before completion of that first/transferred track
if left in this state, the audio device will be held … Plexamp saves and restores the queue after Pi reboot, so the issue will repeat/continue until you either stop/clear the queue (long press on Plexamp play/pause button) or advance playback to the next track … disabling the Plexamp service will stop the issue only temporarily … to avoid the issue entirely (until it is fixed), i usually connect to headless before starting playback
as i understand it, it’s not a new/recent issue, so reverting to an older version of Plexamp is not likely to help … if the description above doesn’t match what you’re observing, it might need further troubleshooting
hope this helps, i originally left out all this detail, didn’t want to distract too much from all the RoPieee beta testing discussion
Oh but the one that was working before when the other 2 didn’t has not played nice and has a backlight but no display showing anything.
Feedback is 0c7131540db33b76
Please reboot and it will work again.
Now it works again, thanks Harry
Everything is all good in the world again. Thanks Harry, have a great week mate!
On 2024.03.90 (I think) I had a blank screen and unresponsive to touch. I reflashed to Stable, all OK, then I re-enabled Beta and got 2024.03.92 which is also OK.
I think the PlexAmp issue might have been user error on my part.
The big disconnect button in PlexAmp doesnt actually cancel streaming, it still shows in Plex as active to that endpoint. When I reboot the endpoint Plex grabs it again.
The actual disconnect button requires clicking on the endpoint, and then clicking a double-down-arrow that isnt at all intuitive (but I hardly use Plex for music).
So, I think my repeat issues arent beta related, as @tgp-2 has also suggested.
@spockfish Harry another odd blank screen after the restart today on one of my displays at least😩
7cb0b0a8377091fa
I’ll power recycle it shorty to be sure it’s not just some odd thing but did the feedback first…it took a long while to give the code back😳
Well, not that odd… there’s in issue in the kernel. I had it twice.