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 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.
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.
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.
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.
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.