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