I apologize, I am not familiar with that router specifically. Does it support captive portal? Have you been able to confirm that? Routers typically only support captive portal configs for guest wifi networks.
Yep ok,
It may be a time as weather drives the schedule, farmer no just home owner in the NE of US.
1 Like
we need as much logging information as possible, as far as I can understand only the OpenWRT routers can provide the kernel dmesg and other debugging information,
probably also any router where you can log in through telnet or some other serial console utility and run BusyBox commands
reckoning that the problem is in EAP calculations done by the wpa-supplicant_8 service we are looking for debugging info of the type “Wrong/Invalid MIC”
concerning wpa-supplicant_8’s source I’ve found the following
according to the respective manifests for each version
iodéOs 5 uses Android 14 revision 67(android-14.0.0_r67)
iodéOS 6.3 uses Android 15 revision 14(android-15.0.0_r14)
iodéOS after 6.3 uses Android 15 revision 32(android-15.0.0_r32)
change the tags in the address bar accordingly to get the respective source code
wpa-supplicant_8 service communicates with the kernel through nl80211 as shown in the diagram of the attached PDF
codeflow.pdf (65.8 KB)
The problem is that all OpenWRT routers are not having issues. I would speculate that DD-WRT users that are a bit technical would be the best to give some help here as I am pretty sure ALL DD-WRT routers have connection issues. I also have ssh on my TP-Link device but that one also does not have issues.
It’s reasonable for open-source routers to not be so idiosyncratic with authentication, I don’t know whether logs and captured frames may show what typical parametre may be missing, maybe through flags in the frames.
The authentication problem appears unsolved for years in many fora for Cisco, Microsoft and Mikrotik devices.
I’m still suspecting a wpa-supplicant.conf that is not proper for all the devices.
I’m gradually having a look in the source differences of wpa-supplicant from A14-67 to A15-14 assuming that the problem is there.
I am very technical, my router is dd-wrt, and I can telnet into it. I have never analyzed wifi traffic though and I don’t want to invest much time in figuring that out. If someone has fairly specific steps which enable me to get the needed info fairly easily, I’d be happy to give it a try.
As I can see there is a repository called Entware from where you can install tcpdump in the router, the full packets can be analyzed with Wireshark or paste them here.
We’re looking for a small number of packets when the phone tries to connect, it could be just 2, 1 from the router and 1 from the phone, there will be more if the phone tries to reconnect, the router’s WiFi Access Point should be broadcasting its existence every 100ms.
Found where I can get it, installed it, but it throws “permission denied” even though perms are right. Searching reveals that this is because it doesn’t work with the build of dd-wrt I have installed. I’m not really interested in hunting for a version that will work with my ~3 year old build of dd-wrt, nor upgrading dd-wrt and then hoping I can get tcpdump working there. Bummer. Thanks for the suggestion though.
The fact that the devs aren’t setting up a known problematic router themselves to solve this is pretty discouraging. I do hope this gets figured out soon because if not, at some point I may have to just seek a refund, which I would hate to do. I wonder how long we’re allowed to request a refund. I don’t want to go past that point waiting in vain for a fix.
Not sure where you heard that the devs aren’t setting up known problem routers but I recently discovered an affected device that I’d imagine many of the devs either already have or can get easily and cheaply. I discovered that the Brax3 is unable to connect to the hotspot on a Pixel 4 with the latest iodéOS beta version on it.
Also, many of the devs are volunteers without unlimited funds to go buy a bunch of routers.
1 Like
on desktop it works only with sudo because it accesses the kernel buffers, is there a sudo or something similar that elevates the privilege on the router?
use some other router that works connected with the router that doesn’t work
Guardian, I heard that from Rik yesterday if you scroll up. As I understand it, Iode gets paid in order for the brax3 to use them, so therefore IMO it’s not unreasonable to think they would spend small amounts of money if necessary to investigate a severe bug.
George, no sudo or su on dd-wrt, and I’ve already tried another router with the intention of plugging it into my main one, but that too fails with the brax3, as did my moto g7 hotspot. Besides, those are merely temporary and poor workarounds.
Since side loading the last TOA the phone has a little more to say about not connecting to the router. No, it isn’t lack of emotional support. It says
BellAlliant1210
Saved/Check password and try again/[(1)
{10:9f:a9:d2:df:a9:=2462,-55,WiFi 4,0s};;;] (Network_Selection_Permanently_Disabled) Network_Selection_Disabled_By_Wrong_Password=1
Note: I have entered and checked the password many times.
1 Like
If that is what you are referring to, I take that as the devices devs owned at the time of beta testing were not affected, myself included. Every router I attempted to connect to (12+) during the beta worked. I don’t see where he says that since the beta, none of the devs have aquired known affected routers.
You could be right, although my follow up question was to ask exactly that, and I got no reply. If they already have one or more of the devices, you’d think he would say so since that would be very newsworthy in this thread or the other one. Furthermore, the beta update they put out a week ago seemed like it was a stab in the dark (I could be wrong but I got that impression). So I think it’s not unreasonable to assume they haven’t, until we hear that they have.
@guardian241 does have it right, basically at this point largely thanks to his finding that many old phones acting as “hotspots” also fail in authentication with the brax3, we have plenty of on-hand non-working examples. But 1. seeing the issue and 2. reliably reproducing the issue don’t mean that 3. a fix for the issue will come in a few days.
Now, if we had found that we could reliably reproduce the issue by using these old phones as hotspots in the pre-beta phase it would have helped, I was mainly referring to hindsight: during the alpha / beta phase none of the dev team could directly reproduce the issue on any of the devices they had at hand.
The issue certainly seems tertiary to an old Linux kernel on the router / hotspot, and I do see bugs from way back on the Linux user list about wifi authentication handoff issues with the 4.x kernels. But I am not into the code to the level to know if those relate to what our current brax3 issue is or not. Just noting that this is not the first device where wifi authentication has been a bear.
We are now waiting for an update from the lead dev, so I don’t have any more specific news to report since last week.
In the meantime, out of curiousity, @TheShanMan please report your Linux kernel version from your dd-wrt device (you can just run uname -a on it if you get connected by ssh), and from your moto G7. I will bet dollars to donuts (not sure where that phrase really came from) they are both = or older than 4.9. This won’t help us solve the problem better (again we can reproduce it), but will contribute to further documenting the issue.
We don’t want to recommend that affected people have to upgrade their routers (and yes some newer ones seem affected too, but I haven’t got confirmation of what kernel they are running… maybe they are newer sold devices still with an ancient kernel on them), but this comment holds a lot of water:
Anyway, we haven’t given up, but trust us this is an incredibly complicated issue, way deeper than what is typically dug into by regular de-google’d ROM builders :-). We will give an update as soon as there is something to report.
2 Likes
Knowing that the issue has been reproduced by the devs is very encouraging and it’s great to hear that! I get that fixing it once it’s reproduced isn’t a slam dunk.
Linux r6400-1 4.4.302 #5194 SMP Sat Feb 5 06:34:48 +07 2022 armv7l DD-WRT
Linux localhost 4.9.206-perf+ #1 SMP PREEMPT Wed Apr 6 12:19:15 UTC 2022 aarch64 Android
I would certainly consider installing an updated DD-WRT build if there was informed reason to believe it would work (meaning not just someone suggesting I try it because it sounds good), but so far I haven’t heard that any DD-WRT routers work. I always dread updating DD-WRT (I have 3 identical routers to get good coverage on my property, with a lot of configuration tweaks). But if the devs conclude that recent DD-WRT builds work, that would be enough of a motivation to me to update them.
Interesting, I also have kernel 4.9 (4.9.337) on my non working Pixel 3a XL used as a hotspot to the brax3. And the kernel list discussions were around an WPA2 authentication change / fix around the 4.9 era.
But before getting too excited, LunarOS on the brax3 (same kernel as when on iodeOS) does NOT have authentication issues (meaning working wifi when on LunarOS).
Again I’ll try to get feedback from the team, I do have some inquiries already submitted about the Linux 4.9.x issues that I haven’t yet gotten feedback on.
@TheShanMan you mind getting a kernel version from your Moto G7? If you have an adb connection you can just use adb shell then do the same, uname -a. Probably can just find it in settings too. Also a 4.9 kernel? 
That is the moto g7. I listed the output for my router, then for my phone. The dd-wrt version is 4.4.302.
1 Like
Firewalla Gold Pro (router mode) with Firewalla Access Point 7, no problems.
Also works using Novos Fiber provided Nokia ONT XS-2426X-A.
1 Like
Now we’ll have a look into the “WiFi Verbose Logging”
-
Settings > About Phone > Build Number(tap 6 times to enable “Developer Mode”) -
Settings > Developer Options > Enable WiFi Verbose Logging -
In the WiFi list you should be able to see more details about each Access Point in range, tap “See all” to view all the details about each Access Point
-
Note down any errors or suspicious values like too weak or too strong signal in specific frequencies.
e.g.
f: frequency in MHz
rssi: strength, since it’s negative the closest to0the better but not more than-30(i.e. not-29)
I also collected this from a Lenovo forum for a similar problem with a Motorola device, try to collect the report to see if there is anything interesting in there
- Go to
Settings -> About Phone -> Tap on Build number 7 timesto go into the developer options mode - Go to
Settings -> Developer options -> Enable USB debugging > Toggle On - Enable
Settings -> Developer options -> Enable Bug Report shortcut > Toggle On - Enable
Settings -> Developer options -> Enable Wi-Fi Verbose Logging > Toggle On - Once the issue is reproduced, Go to
Settings -> Developer options -> Click on take bug reportor Press Power button and then choose Bug Report from the Power down menu. - Wait for some time until the bug report is collected. It takes around 3 to 4 minutes to collect the Bug Report.
I tested it though my WiFi works but still the report is flooded with “errors”, you should be able to locate a “Bug Reports” folder in the menu of the File Explorer app, inside it there should be at least a TXT file and a ZIP one, the TXT should be enough, search for anything related to the WiFi.
1 Like