I’m on a Soho mk3. I think most of the other folks are too.
1 Like
I am convinced that something permanent or semi-permanent was done in this firmware update. Microcode update, separate radio firmware (vs main), or perhaps even some wlan library that is stored on a separate chip that doesn’t actually roll back during the flash. Something like that. Shouldn’t be terribly hard to find… just compare virgin 8.1.0 or 8.1.1 device to a device that was rolled back from 8.1.2 to 8.1.0/01 and see what didn’t properly rollback.
Also, there’s a way you can see the SSID macs - I think it’s under the AP page, STATUS/Access Point. At the bottom there is a list of APs, click the middle icon for the APs you want to see. I didn’t know this originally but while troubleshooting my issue i poked around every possible setting/spot in the GUI and discovered it.
I am doing WiFi WAN not LAN. I dont think I can see the MAC anywhere. It could be an issue with the WISP and coincidental with my 8.1.2 upgrade. I have to dig deeper.
Something is up for sure, I had two devices at least that fell off wifi , however it was not related to firmware 8.1.2
My device was a Pepwave AP One AC Mini Hardware Revision 2
I rolled back the AP from 3.7.3 build 1056 to 3.7.2 build 1029
Radio Thermostat device reconnected automatically
and Nest Protect I had to reboot manually
Nest Protect from Nest Labs is from 2018 , if that helps.
Radio thermostat shows Type 802.11g Rate 54M/54M
All the devices of mine that were not connected seem to be 802.11g
I’m not sure if it’s related to the device firmware or possible some new incontrol2 radio settings?
From what I can see they all disconnected about 7 days ago.
In my case I’m not using Incontrol, so it’s gotta be firmware related.
I think I might have narrowed down this issue to issues with Wireless G clients and possibly HT Mixed Mode or something along those lines.
In my working scenario (asus device), I see the AP sending RTS requests to the station and the station sending CTS responses back. This is around the probe request/response step and shortly before the authentication step.
In my non working scenario (pepwave soho), I see the AP sending RTS requests to the station but the station is not sending CTS responses back.
In the screenshot, you can see the devices in question (different MACs but same type of device). In the working scenario the CTS is sent back immediately. In the non-working scenario, the CTS is never sent and the Pepwave keeps retrying the RTS ad nauseum. The station never responds…
I am no Wifi expert here I might add… so I might be looking in the wrong place. But maybe someone else will understand what is going on and add some color.
Could it be because the RTS is sent at a data rate the client doesnt support that the client never receives it? Or something where the client is rejection the beacon + probe request / response because the SSID + AP seem unfavorable, so it neglects to respond with a CTS altogether? Or furthermore, perhaps the only reason the Pepwave is sending an RTS in the first place is because it never sees the Station try to move to the next step of authentication, so it assumes congestion and sends the RTS?
OR… is the Pepwave accidentally stifling the ability of G clients to connect because it keeps sending RTS’s out, preventing the clients from getting to the point where they will initiate Authentication requests… because they think they’re supposed to be quiet due to the RTS. Then, when the RTS expires, the clients have to restart from Probe stage all over again? That might make sense. I don’t understand why the AP needs to send RTS requests though… I thought it was only stations that initiate RTS and the AP’s respond with CTS.
Hard to tell what is the problem vs. symptom of the problem here.
I gotta admit this stuff is much harder than any other aspect of networking I have ever worked on because it incorporates radio technology, and also because of so many evolving standards over the years like a/b/g/n/ac/ax etc.
Also including another screenshot showing the beacon headers:
Really what is needed is an unadulterated Pepwave Soho to compare against…
Curious to know if your running WPA2, WPA3 or mixed? If WPA3 have you tried going back to WPA2?
I was running WPA2 before and am currently running WPA2. I played around with Mixed but it didn’t help, though it didn’t make things worse either.
The problem is it never even passes 802.11 authentication (which happens before WPA auth).
The clients actually never even request 802.11 auth. They just keep going in cycles of probe request and responses.
My WiFi networks that I am having issue with are Open. Issues on both 2.4 and 5ghz. Going to try to dive deeper this week.
I’m working on your ticket.
1 Like
If you see any issue, please open a ticket and ATTN to sitloongs and I will help to check on this.
1 Like
Ticket number 21050653
1 Like
I can confirm that 802.11g devices are dropping.
1 Like
Would you please open a ticket and allow us to check from the device that as well ? We would like to collect more info for the issue. Please ATTN the ticket to sitloongs
I already submitted it, this morning: 21050670
Hello @sitloongs,
I can confirm that we appear to have observed the issues documented by Michael Martin @mamc with the 8.1.2 GA firmware release affecting 2.4Ghz Wi-Fi.
Models upgraded and now experiencing this issue include:
- Pepwave MAX Transit LTEA (& the previous FW 8.1.1)
- Pepwave MAX BR1 Mk2 LTEA
We have upgraded some MBX/PDX devices and are waiting for an opportunity also to verify these.
On the MAX Transit, the issue also appears to be affecting Wi-Fi WAN connections on 2.4Ghz.
We are advising customers to stay on 8.1.0 GA if they use the 2.4Ghz Wi-Fi, except those using special release versions of firmware for other features.
If you need some additional details, do let us know, though the issue has been already well documented in reading the previous posts.
Happy to Help,
Marcus 
The co-operative debugging on this Wi-Fi issue has been quite impressive.
5 Likes
I too can confirm the “dropping” of 2.4GHz devices. Sadly, I didn’t catch this problem until after I had updated a Balance 20X at work and a SOHO MK3 at home. Now I have connection issues at both locations and as outlined here in detail, rolling back to old firmware or old config files does NOTHING. Hey Peplink Support, is this being escalated as a priority or is this going to be a months long fix?