The rekey interval is probably set to 3600 seconds, something dumb breaks after the 10th rekey (36000 seconds), and so when the 11th rekey interval comes around at the 11th hour (39600 seconds) and it hasn't re-key'd, the authentication ends up no longer valid and it disconnects.
Easy way to test this theory:
Set the re-key interval on the AP to like 10 seconds, see if it disconnects after 110 seconds.
() I've only seen misbehaving clients since the EAP fixes to this functionality in hostapd years ago, where btw there's a whole pile of discussion on this issue through the last decade or so.
Hard to say though since no obvious counter comes out to 11 hours. That being said, a counter of some kind going wrong would be the most obvious reason to experience an issue. Maybe there’s a WiFi frame counter that participates in ratcheting the key used to encrypt each frame or something.
A 32-bit unsigned integer would roll over after ~42949 seconds used as a 10 µs counter. That's just shy of 12 hours at 11:55 and change, not just over 11.
then again, thinking about code with timestamps in float makes me scared
Basically every possible edge case came up: floats can be infinity, negative infinity, negative zero, NaN, and even subnormal. The bulk of the problems occurred because we deserialized the float timestamp and proceeded to do unchecked math on it, then expected it to be a normal value.
Of course when I search on DDG I only get "wow the fast inverse square root"
john carmack time double