home bbs files messages ]

Just a sample of the Echomail archive

Cooperative anarchy at its finest, still active today. Darkrealms is the Zone 1 Hub.

   BINKD      Support for the Internet BinKD mailer      8,958 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 6,373 of 8,958   
   Oli to Andrew Leary   
   Unixtime in M_GOT frames   
   09 Nov 19 14:32:23   
   
   REPLY: 1:320/219@fidonet 5dc6bc2a   
   MSGID: 2:280/464.47@fidonet 5dc6c668   
   CHRS: UTF-8 4   
   TZUTC: 0100   
   TID: CrashMail II/Linux 1.7   
    AL>>> I have recently noticed that some versions of BinkD are listing   
    AL>>> a 64-bit value for the Unixtime sent in M_GOT frames   
    AL>>> acknowledging received files.   
      
    Ol>> Which versions do this and what bit width is used with the M_FILE   
    Ol>> command?   
      
    AL> Here is the log from an example session:   
      
    AL> === Cut ===   
    AL>   09-Nov-2019 05:40:20 mbcico[11948] MBCICO v1.0.7.13   
    AL>   09-Nov-2019 05:40:20 mbcico[11948] Cmd: mbcico f126.n1.z21.fsxnet   
    [...]   
    AL> Binkp: M_GOT "SIOREG.ZIP 21096 18446744073453975120" + 09-Nov-2019   
    AL> 05:40:22 mbcico[11948] Binkp: unexpected M_GOT "SIOREG.ZIP"   
    AL> === Cut ===   
      
   That is an interesting unix timestamp, which doesn't fit into a 64-bit signed   
   integer.   
      
   18446744073453975120 / 2 -> November 16, 219250464   
      
   Even if this were in nanoseconds it would be a date far in the future:   
   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 the   
    AL> remote (binkd 1.1a-99/Linux) is sending a 64-bit value for the   
    AL> Unixtime in the M_GOT frame.   
      
   Looks like a bug to me that needs fixing. Are you sure that binkd sends this   
   number?   
      
    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 the   
    AL> 64-bit value and ends up trying to send the file again in the next   
    AL> session.  I suspect that ifcico (which mbcico was based on) will do   
    AL> the same, although I haven't tested it yet.   
      
   Every mailer should reject that M_GOT, the value doesn't make any sense.   
      
   --- GoldED+/LNX 1.1.5-b20180707   
    * Origin: * nigirO (2:280/464.47)   
   SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 227/114 229/101 200   
   SEEN-BY: 229/354 426 1014 240/5832 249/307 317 280/464 5003 5555 292/854   
   SEEN-BY: 310/31 342/200 396/45 423/120 712/848 770/1 2452/250   
   PATH: 280/464 229/426   
      

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca