Subj : Unixtime in M_GOT frames To : Oli From : Andrew Leary Date : Sat Nov 09 2019 05:04 pm Hello Oli! 09 Nov 19 14:32, you wrote to me: AL>> Binkp: M_GOT "SIOREG.ZIP 21096 18446744073453975120" + Ol> That is an interesting unix timestamp, which doesn't fit into a 64-bit Ol> signed integer. I noticed that too. It definitely looks like someone is treating it as unsigned instead of signed. Ol> 18446744073453975120 / 2 -> November 16, 219250464 Ol> Even if this were in nanoseconds it would be a date far in the future: Ol> July 21, 2554 AL>> I need to add logging of the sent M_FILE messages to confirm that AL>> mbcico is sending a 32-bit value in the M_FILE. You can see that AL>> the remote (binkd 1.1a-99/Linux) is sending a 64-bit value for AL>> the Unixtime in the M_GOT frame. I'll have to tcpdump the incoming packets to be sure, but I've never seen that happen with any other node. Ol> Looks like a bug to me that needs fixing. Are you sure that binkd Ol> sends this number? Definitely a bug somewhere; I just need to establish for sure whether it's in mbcico or binkd. Ol>>> Does it break compatibility with any mailer? You didn't mention Ol>>> any specific example. AL>> mbcico (the mailer included with MBSE BBS) rejects the M_GOT with AL>> the 64-bit value and ends up trying to send the file again in the AL>> next session. I suspect that ifcico (which mbcico was based on) AL>> will do the same, although I haven't tested it yet. Ol> Every mailer should reject that M_GOT, the value doesn't make any Ol> sense. Incidentally, I discovered that the timestamp of that file on disk was showing as November 25, 1961, so it should be a negative value. Converting the decimal to hex yields FFFF FFFF F0C4 3650, which in 2's complement notation is -255576496. A quick Unix time conversion results in Sat 25 Nov 1961 10:31:44 PM UTC. Therefore, it appears that the value is a correct 64-bit Unixtime for the file timestamp as it was on disk. Andrew --- GoldED+/LNX 1.1.5-b20180707 * Origin: Phoenix BBS * phoenix.bnbbbs.net (1:320/219) .