Check the system date and time. If it is not current, then go to settings > Details > Date and Time. And adjust it.
I about this in the other thread. Do you have a clue why the date influences the wifi? I didnât expect this. What has the date to do with wifi? The only idea I have is that datetime might be a parameter in PRNG and random numbers go into wifi crypto, but still doesnât explain it.
Iâm curious.
Hello @prolog
I am by no means experienced with cells. Was never convicted , but I have had date issues on desk and laptops. I think the date has to do with your ISP lease time, and the router/modem needing to be date synced for, well, syncing devices. Too, some web sites croak if I have a bad date on d/ltops that the server likes to have corrected.
~s~
Ah. Leasetimes could be possible. I wonder how they are modeled, as durations or with dates. Also I donât remember if a date or index attribute is part of IP datagrams alias packages. Receiving stations might need such to process packages in order they were send which might be different from the order they are received.
Edit: IP packets have an âidentificationâ attribute for sequencing packets which is not a date.
No good. Even after I disable automatic date/time setting and manually correct the timezone and time, it still doesnât connect.
Spoke too soon. The incorrect date/time was indeed the problem, but I only thought to fix the time. I didnât notice the date was also wrong.
And there also appears to be a problem with the hardware clock. After I set the time manually, and then waited 30 minutes to set the date, the clock became 2 minutes behind, so it still didnât work right away until I again had to fix the time.
Glad you got the wifi working.
When you say âhardware clockâ, are you talking about the Clocks app? My time runs perfectly.
Maybe download all the waiting updates and see if it corrects itself. You can check for updates in the PureOS store, or do a sudo apt update
in the terminal.
P.S. Do you have a SIM card inserted? (for time syncing to the network)
May not matter, though.
Does ntpq -p
show that youâre connecting to NTP servers successfully?
I think itâs not the wifi as such, the wifi is actually working locally on the âlink layerâ but IP is not working. The problem is with DHCP, see this issue:
Same thing could happen with a wired connection, if you had that, I think.
Is a workaround, for the user, to choose to use a static IP address? (particularly if you only ever use the WiFi at home)
In any case, that might get past the DHCP issue and then you can use NTP to get the correct time.
But easier just to set the date/time manually.
I think that should work, but then again that would require making changes on both the wifi access point (router) side and on the phone itself, so setting the date manually is probably easier. Once the date is set, you never need to worry about it again, as I understood it, then everything will work. Itâs not like the problem comes back after reboot or anything, itâs just a one-time fix. Could be avoided if Purism had set the date before shipping the phone, @dos wrote something about trying to make that happen for shipments later on. Seems like a good idea to improve the first impression people get of their new phone.
Pop off the back and take a picute for me after taking out the battery. I had the same issue weeks ago and have a hunch about how I fixed it. So letâs see if you might have the same issue.
I didnât necessarily get that impression. The reference to âbattery is dead enough for the RTC to resetâ suggests that it could happen again and, while power consumption remains high, could happen frequently if you are not careful to charge up before itâs too late - unless the time keeping has some kind of fallback.
One concern would be that for phones going overseas, it takes so long for the phone to reach the customer that the battery is flat before the customer gets it, particularly at this time of year.
Not really. Provided that there is a portion of the IP address space (in the subnet) that is not used by DHCP, you can just set an IP address in the non-DHCP range and away you go.
A different approach would be to reject any saved time coming from the RTC that will cause the error âUnable to set up timer: out of range
â. To know that however would require knowing what interface is being used to set the timer and what its limitations are - and changing the code in the future if those limitations are removed. (Is this an early manifestation of the 2038 problem or of the 2106 problem?)
For reference, I had periods over the past couple months where the L5 stayed unconnected for months, and it wasnât enough to trigger the RTC reset. in fact I donât remember the last time this happened, and Iâm not very careful about the battery.
Is that because the battery reaches a level of flatness such that the phone dies but there is still plenty enough juice to run the RTC for perhaps months?
RTC consumes absurdly small amount of juice, about 350 nanoamps, and is hooked directly to battery, bypassing any voltage regulation chips, so yeah. Also, I suspect there is a super cap providing a few hours of juice in case there is no battery. But I canât be sure - the published schematics do not say what the value and model of C4051 are. Might as well be yet another voltage noise sink.
Does the RTC reset when you remove battery for like several seconds and then replace it again?
RTC can run with voltage as low as 1.0V. Flat battery provides more than 3V. Given the absurdly small current appetite of the RTC, comparable to leakage currents of diodes and capacitors, Iâd say the battery can supply enough juice until it ceases to be a battery at all. This can take indefinitely long. More than few hundred years at the very least.
Correct, I personally asked Eric to make sure the battery can be removed for a short while, and I can confirm that this is how it works in practice.
Anyway, yâall have convinced me. I withdraw the suggestion that it would be easy for the RTC to reset subsequently.