So Actiontec T2200H does NOT work (mine) but Actiontec T3200M DOES work (my client’s)
First Actiontec reported as working! Time to do a bit of router swap with your client? 
1 Like
This sagecomm works just fine:
Sagemcom / F@st 5670
WPA-2 Personal
1 Like
I wish! But no can do…
1 Like
I can verify DD-WRT is working when using a captive portal on a guest network with WPA2-PSK. This is with a router that is not working normally.
1 Like
That’s interesting, because mine doesn’t and we have the exact same router. It would good to know what settings you have compared to mine.
@dwilson You probably have different Firmware versions but there is also the case of routers with different chipsets that are marketed under the same model name, you can verify this by checking the full model number and the serial numbers under the router.
Run the diagnostics I have posted above on your phone for both cases to check for errors.
Nighthawk 7300
Iode version: 6.6-20250803-brax3
Could not connect to wifi network whether 2.4 or 5g with known password. WPA/WPA2. Can connect to other hotspot or wifi so far without a problem. Hope this can be resolved as your reputation will take a big hit.
2 Likes
Is there a location for these logs? All I can see is that it is saying that it is the wrong password… but its not.
Similar to the following:
Network_Selection_Permanently_Disabled) Network_Selection_Disabled_By_Wrong_Password=1
The 2nd diagnostic (bug report) will appear as a folder in the 3-bar menu of the Files app, inside there you’ll find a TXT file, copy it somewhere and open it with a text viewer app and search for “WiFi”, “WPA” etc
Note that the folder disappears if you exit the developer’s mode but the contents remain there when you enable it again.
I had your model as a Sagemcom F@st 5366s whereas @brinerustle reported success with a Sagemcom F@st 5670, is that right?
My apologies, you are correct, my model number is 5366s. I actually have access to the console now, what information do you desire there?
With all due respect to everyone involved here, the tracking chart is missing some key information, namely the Wi-Fi chipset for the specific router being reported on (yeah, mfgrs have been known to change these midstream on the same router model name), the Wi-Fi driver name and version, etc. I would hope that whomever this info is being handed off to on iode’s side is somehow collecting that info as well?
Also, has anyone on iode’s side actually purchased a cheap router that currently isn’t working? As was apparently mentioned many times during the beta testing, even a cheap old second-hand WRT54GL running DD-WRT (or Tomato) would probably suffice for a working example of a Broadcom chipset & driver combo that can’t negotiate WPA correctly with the BraX3…
In my case I’ve given up waiting as I just don’t see the urgency necessary from Brax or iode to get this issue resolved. My current daily driver is a Xiaomi model that basically is not supported with any currently-maintained ROM, and I really need to migrate to newer phone hardware sooner rather than later. So yesterday I reluctantly went to the hardware dark side (again) and ordered a Pixel 9a on discount from my ISP. I plan to wipe the stock Google spy/firmware and install a more privacy oriented ROM. Heck, I might even install iodeOS on it! I’m sure that Wi-Fi compatibility won’t be an issue on that hardware. Wish I could say the same for the BraX3. 
The problem started after the migration from Android 14 r67 to Android 15, the range of chipsets is huge, we guess it’s something on a higher level like the wpa-supplicant_8 which does the handshake.
Get a bug report as I describe on my earlier post and tell us if you can see something.
Make sure that your ISP’s phone isn’t locked.
“Make sure that your ISP’s phone isn’t locked.”
Sorry, not clear on that… these BraX3 phones are clearly not carrier locked, and I haven’t even installed a SIM into mine yet, so there are no PUK issues at play here…
The Pixel from your ISP may have a locked bootloader.
Ah, you’re talking about my newly ordered Pixel 9a, not the BraX3 
Yeah it’s definitely not carrier locked, just a standard unlocked Google phone. Nothing except the usual Google spyware included. But I’ll refrain from further advertising here. 
As noted above, thanks to @guardian241 we now have many examples of non-working devices by simply using old phones as hotspots (my Pixel 3a XL for example). During the beta phase it was hard to find hardware to re-create the issue. I am not sure of the ease of access to common hardware that had the issue for the devs in France, but again, that is now moot as we all can see the issue easier with old phones acting as hotspots.
So the point remains that seeing the problem and reliably reproducing the problem doesn’t mean an immediate fix for the problem. I didn’t get a direct update on the work on the issue the past few days, but do know it actively being worked on.
I don’t fault you for buying hardware to “address the problem”, but just curious why buy another phone when $60 (or less) to get a different wifi AP would suffice?
1 Like